Mailman-users search results for query "user unknown in local recipient table"
mailman-users@mailman3.org- 36 messages
Re: Issues with Mail delivery after Mailman 3 installation
by Stephen J. Turnbull
Here's the promised followup, starting where I left off earlier.
>> Here's the Postfix doc:
>>
>> permit_auth_destination
>> Permit the request when one of the following is true:
>>
>> - Postfix is a mail forwarder: the resolved RCPT TO domain
>> matches $relay_domains or a subdomain thereof, and the address
>> contains no sender-specified routing (user@elsewhere@domain),
>> - Postfix is the final destination: the resolved RCPT TO domain
>> matches $mydestination, $inet_interfaces, $proxy_interfaces,
>> $virtual_alias_domains, or $virtual_mailbox_domains, and the
>> address contains no sender-specified routing
>> (user@elsewhere@domain).
> I did read the documentation before adding it, I definitely
> misunderstood what it meant, and after looking at the old
> documentation, it makes sense not to add it.
>
> Could you help me understand what the above means?
The name "permit_auth_destination" means that when the domain part of
the recipient is *authorized*, Postfix should proceed to route the
mail to final delivery. It can still be rejected (for example, if the
"user" part doesn't exist at "domain"), but checking that the final
destination host is authorized is an easy and cheap first screen.
The two bullet points *define* "authorized". Both contain the phrase
"and the address contains no sender-specified routing". This
condition is imposed because
(1) you can't be sure that the MTA at "domain" will relay to
"elsewhere" rather than "spyagency, so stripping off
"user@elsewhere" and checking if "elsewhere" is authorized isn't
reliable, and
(2) on the modern Internet there's no need for sender-specified
routing anyway.
Both bullet points start with "Postfix is ...", but more fully this
should be "Postfix is acting to ... this message".
The first bullet point then is saying "when the domain matches
$relay_domains or a subdomain, go ahead and relay." In other words,
this Postfix is acting as the MX for the domains in $relay_domains.
The second bullet point is more complex, but it basically amounts to
various ways of saying "the final destination is local", or more
formally, under administrative control of the Postfix administrator
(and that's the difference with relay_domains, which are cooperative
agreements with those domains, but not controlled by this Postfix's
administrator). To understand why each of those variables means
"local", I'll ask you to look first at the Postfix docs because I'm
getting tired ;-): https://www.postfix.org/postconf.5.html.
> Yes, this host is dedicated to Mailman.
See comments above each restriction:
> These are listed in smtpd_relay_restrictions;
> /* local IP addresses */
> permit_mynetworks
> /* explicitly authenticated *sender* by SASL */
> permit_sasl_authenticated
> /* reject destinations not authorized by
> permit_auth_destinations */
> reject_unauth_destination
> /* I think these two are redundant, messages rejected
> by them can't get past reject_unauth_destination */
> reject_unknown_recipient_domain
> reject_non_fqdn_recipient
> /* This is complicated, but the main point is that the
> above criteria can be bypassed by aliases */
> reject_unlisted_recipient
> I'll remove permit_sasl_authenticated, as my assumption no longer
> holds. That's why I disabled it earlier because I remembered it
> was never used for delivery, but then I remembered there was a
> conversation about the marketing alias so I assumed it was used for
> sending out emails.
That sounds right to me based on our conversations, but if you change
your mind and decide you want to add more conditions, feel free to
consult then.
> I did set one for the mailman user, seems I'll have to remove it and
> disable saslauthd too.
Yes, I think it's best to require that access to 'su mailman' be
restricted to root and/or sudo.
> Yes, this is where I'm headed as that's what I need.
Good luck!
From your second message:
> After making the above changes I talked about, mail transfer seems
> to work as expected,
Hurray!
> although I noticed users signing up don't get their confirmation
> emails delivered for some reason, saw this in the logs;
>
> (1632818) <177024281405.1632816.13618430493699791595(a)localhost.localdomain>
> delivery to ibiam(a)sugarlabs.org failed with code 550, b'5.1.1
> <ibiam(a)sugarlabs.org>: Recipient address rejected: User unknown in local
> recipient table'
>
> What would be the best way to ensure that these get delivered?
I don't understand why this would not be delivered. My best guess
would be that you have "sugarlabs.org" in $mydomain (this is actually
Postfix's default), so that Postfix thinks lists.sugarlabs.org is a
mail gateway for the parent domain. What "mail gateway" means is that
this host has direct write access to mailboxes "at" that domain. This
could be because it's a local or network file system mounted on this
host, or it could be a network transport to an IMAP server, that kind
of thing. But "lists" isn't a gateway in that sense.
> I think I went into this rabbit hole because of this particular
> issue above, and I thought something was wrong, mail was always
> sent to the mailman user and I thought that was odd, but now I know
> that's expected as that's the user that Mailman runs on.
Yes, I think that what's happening is that "something went wrong" and
some error message was mailed back to <mailman(a)lists.sugarlabs.org>.
Sincere regards,
Steve
--
GNU Mailman consultant (installation, migration, customization)
Sirius Open Source https://www.siriusopensource.com/
Software systems consulting in Europe, North America, and Japan
5 months, 3 weeks
Re: Issues with Mail delivery after Mailman 3 installation
by Chihurumnaya Ibiam
On Thu, Feb 5, 2026 at 2:21 PM Stephen J. Turnbull <steve(a)turnbull.jp>
wrote:
> Here's the promised followup, starting where I left off earlier.
>
> >> Here's the Postfix doc:
> >>
> >> permit_auth_destination
> >> Permit the request when one of the following is true:
> >>
> >> - Postfix is a mail forwarder: the resolved RCPT TO domain
> >> matches $relay_domains or a subdomain thereof, and the address
> >> contains no sender-specified routing (user@elsewhere@domain),
> >> - Postfix is the final destination: the resolved RCPT TO domain
> >> matches $mydestination, $inet_interfaces, $proxy_interfaces,
> >> $virtual_alias_domains, or $virtual_mailbox_domains, and the
> >> address contains no sender-specified routing
> >> (user@elsewhere@domain).
>
> > I did read the documentation before adding it, I definitely
> > misunderstood what it meant, and after looking at the old
> > documentation, it makes sense not to add it.
> >
> > Could you help me understand what the above means?
>
> The name "permit_auth_destination" means that when the domain part of
> the recipient is *authorized*, Postfix should proceed to route the
> mail to final delivery. It can still be rejected (for example, if the
> "user" part doesn't exist at "domain"), but checking that the final
> destination host is authorized is an easy and cheap first screen.
>
> The two bullet points *define* "authorized". Both contain the phrase
> "and the address contains no sender-specified routing". This
> condition is imposed because
> (1) you can't be sure that the MTA at "domain" will relay to
> "elsewhere" rather than "spyagency, so stripping off
> "user@elsewhere" and checking if "elsewhere" is authorized isn't
> reliable, and
> (2) on the modern Internet there's no need for sender-specified
> routing anyway.
> Both bullet points start with "Postfix is ...", but more fully this
> should be "Postfix is acting to ... this message".
>
> The first bullet point then is saying "when the domain matches
> $relay_domains or a subdomain, go ahead and relay." In other words,
> this Postfix is acting as the MX for the domains in $relay_domains.
>
> The second bullet point is more complex, but it basically amounts to
> various ways of saying "the final destination is local", or more
> formally, under administrative control of the Postfix administrator
> (and that's the difference with relay_domains, which are cooperative
> agreements with those domains, but not controlled by this Postfix's
> administrator). To understand why each of those variables means
> "local", I'll ask you to look first at the Postfix docs because I'm
> getting tired ;-): https://www.postfix.org/postconf.5.html.
>
Thank you, this was helpful.
>
> > Yes, this host is dedicated to Mailman.
>
> See comments above each restriction:
>
> > These are listed in smtpd_relay_restrictions;
> > /* local IP addresses */
> > permit_mynetworks
> > /* explicitly authenticated *sender* by SASL */
> > permit_sasl_authenticated
> > /* reject destinations not authorized by
> > permit_auth_destinations */
> > reject_unauth_destination
> > /* I think these two are redundant, messages rejected
> > by them can't get past reject_unauth_destination */
> > reject_unknown_recipient_domain
> > reject_non_fqdn_recipient
> > /* This is complicated, but the main point is that the
> > above criteria can be bypassed by aliases */
> > reject_unlisted_recipient
>
>
Very helpful, thank you!
> > I'll remove permit_sasl_authenticated, as my assumption no longer
> > holds. That's why I disabled it earlier because I remembered it
> > was never used for delivery, but then I remembered there was a
> > conversation about the marketing alias so I assumed it was used for
> > sending out emails.
>
> That sounds right to me based on our conversations, but if you change
> your mind and decide you want to add more conditions, feel free to
> consult then.
>
Thank you, I hope that doesn't happen.
>
> > I did set one for the mailman user, seems I'll have to remove it and
> > disable saslauthd too.
>
> Yes, I think it's best to require that access to 'su mailman' be
> restricted to root and/or sudo.
>
Yes, this is the case at the moment.
I've deleted the user password for mailman.
>
> > Yes, this is where I'm headed as that's what I need.
>
> Good luck!
>
Thank you!
I'll have to look at why the confirmation email gets bounced later, this is
all I have time for.
> From your second message:
>
> > After making the above changes I talked about, mail transfer seems
> > to work as expected,
>
> Hurray!
>
> > although I noticed users signing up don't get their confirmation
> > emails delivered for some reason, saw this in the logs;
> >
> > (1632818)
> <177024281405.1632816.13618430493699791595(a)localhost.localdomain>
> > delivery to ibiam(a)sugarlabs.org failed with code 550, b'5.1.1
> > <ibiam(a)sugarlabs.org>: Recipient address rejected: User unknown in
> local
> > recipient table'
> >
> > What would be the best way to ensure that these get delivered?
>
> I don't understand why this would not be delivered. My best guess
> would be that you have "sugarlabs.org" in $mydomain (this is actually
> Postfix's default), so that Postfix thinks lists.sugarlabs.org is a
> mail gateway for the parent domain. What "mail gateway" means is that
> this host has direct write access to mailboxes "at" that domain. This
> could be because it's a local or network file system mounted on this
> host, or it could be a network transport to an IMAP server, that kind
> of thing. But "lists" isn't a gateway in that sense.
>
I've changed mydomain to lists.sugarlabs.org, and tried again, let's see if
that works.
>
> > I think I went into this rabbit hole because of this particular
> > issue above, and I thought something was wrong, mail was always
> > sent to the mailman user and I thought that was odd, but now I know
> > that's expected as that's the user that Mailman runs on.
>
> Yes, I think that what's happening is that "something went wrong" and
> some error message was mailed back to <mailman(a)lists.sugarlabs.org>.
>
Thank you for all your help, I really appreciate it.
>
> Sincere regards,
>
> Steve
>
> --
> GNU Mailman consultant (installation, migration, customization)
> Sirius Open Source https://www.siriusopensource.com/
> Software systems consulting in Europe, North America, and Japan
>
--
Ibiam Chihurumnaya
ibiamchihurumnaya(a)gmail.comT
5 months, 3 weeks
Re: integrating mm3 with postfix / lmtp
by Fabian A. Santiago
On October 25, 2017 9:17:33 PM EDT, "Fabian A. Santiago" <fsantiago(a)garbage-juice.com> wrote:
>On October 25, 2017 9:13:20 PM EDT, Mark Sapiro <mark(a)msapiro.net>
>wrote:
>>On 10/25/2017 05:41 PM, Fabian A. Santiago wrote:
>>>
>>> No to the domains part and I think virtual alias maps is needed:
>>>
>>> mail postfix/trivial-rewrite[19445]: warning: do not list domain xxx
>>in BOTH virtual_mailbox_domains and relay_domains
>>> Oct 25 20:39:19 mail postfix/trivial-rewrite[19445]: warning: do not
>>list domain xxx in BOTH virtual_mailbox_domains and relay_domains
>>> Oct 25 20:39:19 mail postfix/submission/smtpd[19441]: NOQUEUE:
>>reject: RCPT from
>>pool-108-53-239-102.nwrknj.fios.verizon.net[108.53.239.102]: 550 5.1.1
>><test123@xxx>: Recipient address rejected: User unknown in virtual
>>mailbox table; from=<fsantiago@xxx> to=<test123@xxx> proto=ESMTP
>>helo=<[10.0.0.29]>
>>
>>(above slightly sanitized for return to the list)
>>
>>The issue here is your list domain cannot be a virtual_mailbox_domain
>>or
>>a virtual_alias_domain.
>>
>>I have the same issue on mail.python.org where we have both Mailman 2
>>and Mailman 3 lists @python.org. and python.org is a
>>virtual_alias_domain.
>>
>>I have a group of MRs for a branch that implements "alias_domains" to
>>deal with this.
>>
>>Basically it works by creating another (virtual_alias_maps)
>>postfix_vmap
>>mapping to map list addresses @python.org to addresses @x.python.org.
>>Then the postfix_domains and postfix_lmtp maps have the x.python.org
>>domain and there is a patch to mailman/runners/lmtp.py to map the
>>x.python.org domain back to python.org.
>>
>>The various MRs are
>><https://gitlab.com/mailman/mailman/merge_requests/202> for the core,
>><https://gitlab.com/mailman/mailmanclient/merge_requests/18> for the
>>REST bindings used by Postorius and
>><https://gitlab.com/mailman/postorius/merge_requests/186> to be able
>to
>>set an alias_domain via Postorius.
>>
>>That's not all implemented at mail.python.org. What's there is the
>>basic
>>Postfix config, a bash script the generate the new mappings from the
>>old
>>and a simple patch to mailman/runners/lmtp.py.
>>
>>So, the bottom line is it can be done and it's in process, but it
>won't
>>really be supported until Mailman 3.2. In the mean time, you just need
>>to have a separate domain for your lists that isn't a
>virtual_*_domain.
>
>Ok thanks. At least I have a clear answer now. Any ETA on 3.2 in mind
>yet?
>--
>
>Thanks,
>
>Fabian S.
>
>OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
>_______________________________________________
>Mailman-users mailing list
>mailman-users(a)mailman3.org
>https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Mark,
Ok I have it almost perfectly working now having taken your direction and configuring a unique domain not in my email system already.
But in my testing, I replied to a subscription confirmation message and received back an undeliverable looping email error message from postfix. Any clues there you can offer? I can post to the list from any email added via the admin console. The test subscriber address was local to my server. From an outside address, same error.
Once I registered the new email domain, I reverted my postfix config back to the default suggested by maxking's docker instructions.
https://github.com/maxking/docker-mailman
Thanks.
--
Thanks,
Fabian S.
OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
8 years, 9 months
I have issue where it does not send emails on to people in the list I create.
by john_warland＠hotmail.com
Hello,
I am quite new to Mailman3 and have been trying to get a working local test setup on a single VM (Centos07)
I have issue where if I send an email to the list. it does not send emails on to the people subscribed to that list.
Note the steps below were put together from memory after a few days of repeatably trying different things so there will be some inaccuracies
I have mailman running on same local box as postfix, postorius and hyperkitty.
I have root as the superuser in Postorius and have tried the following:
In unix shell created new user 'developer'
In unix shell created new user 'tester'
In shell send an email from developer user to tester:
echo 'Hello' | mailx -s 'Hello Subject line' tester(a)sandbox.mytest.com
Confirmed user tester received email in cat /home/tester/Maildir/new/ folder:
Return-Path: <developer(a)cloud7.sandbox.mytest.com>
X-Original-To: tester(a)cloud7.sandbox.mytest.com
Delivered-To: tester(a)cloud7.sandbox.mytest.com
Received: by cloud7.sandbox.mytest.com (Postfix, from userid 1000)
In Postorius web frontend:
Signed up as root
Received confirmation email in /root/Maildir/new/ folder so cut and pasted the Url in the email to activate account.
Created new list called testlist(a)sandbox.mytest.com
Logged out
Signed up as tester
Received confirmation email in /home/tester/Maildir/new/ folder so cut and pasted the Url to activate account.
Subscribed tester to the testlist.
Next in unix shell su as developer and send an email to testlist(a)sandbox.mytest.com
The root user gets the following email
Content-Transfer-Encoding: 7bit
Subject: Your message to testlist(a)cloud7.sandbox.mytest.com awaits moderator approval
From: testlist-bounces(a)cloud7.sandbox.mytest.com
To: developer(a)cloud7.sandbox.mytest.com
Message-ID: <158824480291.3035.17408340520496115243(a)localhost.localdomain>
Date: Thu, 30 Apr 2020 11:06:42 +0000
Precedence: bulk
X-Mailman-Version: 3.3.0
Your mail to 'testlist(a)cloud7.sandbox.mytest.com' with the subject
hello there 2
Is being held until the list moderator can review it for approval.
The message is being held because:
The message is not from a list member
Either the message will get posted to the list, or you will receive notification of the moderator's decision.
Once I have gone back into Postorius as root and approved the message, root user gets a second email:
Return-Path: <testlist-bounces(a)cloud7.sandbox.mytest.com>
X-Original-To: root(a)cloud7.sandbox.mytest.com
Delivered-To: root(a)cloud7.sandbox.mytest.com
Received: from localhost.localdomain (localhost [IPv6:::1])
by cloud7.sandbox.mytest.com (Postfix) with ESMTP id E056A84CE4
for <root(a)cloud7.sandbox.mytest.com>; Thu, 30 Apr 2020 11:09:10 +0000 (UTC)
Received: by cloud7.sandbox.mytest.com (Postfix, from userid 1000)
id 8F1B684CE4; Thu, 30 Apr 2020 11:06:41 +0000 (UTC)
Date: Thu, 30 Apr 2020 11:06:41 +0000
To: testlist(a)cloud7.sandbox.mytest.com
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Message-Id: <20200430110641.8F1B684CE4(a)sandbox.mytest.com>
From: developer(a)cloud7.sandbox.mytest.com
X-MailFrom: developer(a)cloud7.sandbox.mytest.com
X-Mailman-Rule-Hits: nonmember-moderation
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation
Message-ID-Hash: FAPTJKJRZG2ELSOSBRBIDOBWXP3Y5QAY
X-Message-ID-Hash: FAPTJKJRZG2ELSOSBRBIDOBWXP3Y5QAY
X-Mailman-Approved-At: Thu, 30 Apr 2020 11:09:10 +0000
X-Mailman-Version: 3.3.0
Precedence: list
Subject: [Testlist] hello there 2
List-Id: A test list <testlist.sandbox.mytest.com>
List-Help: <mailto:testlist-request@sandbox.mytest.com?subject=help>
List-Post: <mailto:testlist@sandbox.mytest.com>
List-Subscribe: <mailto:testlist-join@sandbox.mytest.com>
List-Unsubscribe: <mailto:testlist-leave@sandbox.mytest.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
A test email 2
_______________________________________________
Testlist mailing list -- testlist(a)sandbox.mytest.com
To unsubscribe send an email to testlist-leave(a)sandbox.mytest.com
At no point does the email appear in the tester(a)sandbox.mytest.com Maildir
Configs as follows..
==================================================================================================
/etc/postfix/main.cf:
==================================================================================================
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
myhostname = cloud7.sandbox.mytest.com
mydomain = sandbox.mytest.com
myorigin = $mydomain
inet_interfaces = all
inet_protocols = all
mydestination = $myhostname, localhost.$mydomain, localhost,
mail.$mydomain, www.$mydomain, ftp.$mydomain, sandbox.mytest.com
unknown_local_recipient_reject_code = 550
# Next line Obfuscated
mynetworks = 192.***.***.0/24, 127.0.0.0/8
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
recipient_delimiter = +
home_mailbox = Maildir/
debug_peer_level = 2
debug_peer_list = sandbox.mytest.com
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.10.1/samples
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
disable_dns_lookups = yes
owner_request_special = no
transport_maps = hash:/var/lib/mailman/data/postfix_lmtp
# Setting to nothing fixes 'Recepient address rejected: User unknown in local recipient table
local_recipient_maps =
relay_domains = hash:/var/lib/mailman/data/postfix_domains
==================================================================================================
/etc/mailman.cfg
==================================================================================================
[devmode]
enabled: yes
recipient: root(a)sandbox.mytest.com
[mailman]
# local = Recommended as installing mailman from source. Folder structure in /var/tmp/mailman
# fhs = /var/bin, /var/log, etc..
layout: fhs
[logging.database]
level: info
[mta]
# This config is for when mailman and the MTA (Postfix) are on the same host
incoming: mailman.mta.postfix.LMTP
outgoing: mailman.mta.deliver.deliver
lmtp_host: 127.0.0.1
lmtp_port: 8024
smtp_host: localhost
smtp_port: 25
configuration: python:mailman.config.postfix
[webservice]
hostname: localhost
port: 8001
use_https: no
admin_user: restadmin
admin_pass: restpass
api_version: 3.1
==================================================================================================
/etc/mailman-suite-1.0.0/mailman-suite_project/settings.py
==================================================================================================
In this file the main changes were:
DEBUG=True
SERVER_EMAIL = 'root(a)localhost.local'
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
Commented out three lines of code:
# if DEBUG == True:
# EMAIL_BACKEND = 'django.core.mail.backends.filebased.EmailBackend'
# EMAIL_FILE_PATH = os.path.join(BASE_DIR, 'emails')
Complete file:
"""
Django Settings for Mailman Suite (hyperkitty + postorius)
For more information on this file, see
https://docs.djangoproject.com/en/1.8/topics/settings/
For the full list of settings and their values, see
https://docs.djangoproject.com/en/1.8/ref/settings/
"""
# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
import os
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'change-this-on-your-production-server'
# SECURITY WARNING: don't run with debug turned on in production!
# Have to keep it True atm as the css styles screw up when set to False
DEBUG = True
ADMINS = (
('Mailman Suite Admin', 'root@localhost'),
)
SITE_ID = 1
# Hosts/domain names that are valid for this site; required if DEBUG is False
# See https://docs.djangoproject.com/en/1.8/ref/settings/#allowed-hosts
ALLOWED_HOSTS = [
"localhost", # Archiving API from Mailman, keep it.
"MAILMAN_SERVER_ADDRESS", <--- I inject IP Address here
# Add here all production URLs you may have.
]
# Mailman API credentials
MAILMAN_REST_API_URL = 'http://localhost:8001'
MAILMAN_REST_API_USER = 'restadmin'
MAILMAN_REST_API_PASS = 'restpass'
MAILMAN_ARCHIVER_KEY = 'SecretArchiverAPIKey'
MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1')
# Application definition
INSTALLED_APPS = (
'hyperkitty',
'postorius',
'django_mailman3',
# Uncomment the next line to enable the admin:
'django.contrib.admin',
# Uncomment the next line to enable admin documentation:
# 'django.contrib.admindocs',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
'rest_framework',
'django_gravatar',
'compressor',
'haystack',
'django_extensions',
'django_q',
'allauth',
'allauth.account',
'allauth.socialaccount',
'django_mailman3.lib.auth.fedora',
'allauth.socialaccount.providers.openid',
'allauth.socialaccount.providers.github',
'allauth.socialaccount.providers.gitlab',
'allauth.socialaccount.providers.google',
# 'allauth.socialaccount.providers.facebook',
'allauth.socialaccount.providers.twitter',
'allauth.socialaccount.providers.stackexchange',
)
MIDDLEWARE = (
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django.middleware.security.SecurityMiddleware',
'django_mailman3.middleware.TimezoneMiddleware',
'postorius.middleware.PostoriusMiddleware',
)
ROOT_URLCONF = 'urls'
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [],
'APP_DIRS': True,
'OPTIONS': {
'context_processors': [
'django.template.context_processors.debug',
'django.template.context_processors.i18n',
'django.template.context_processors.media',
'django.template.context_processors.static',
'django.template.context_processors.tz',
'django.template.context_processors.csrf',
'django.template.context_processors.request',
'django.contrib.auth.context_processors.auth',
'django.contrib.messages.context_processors.messages',
'django_mailman3.context_processors.common',
'hyperkitty.context_processors.common',
'postorius.context_processors.postorius',
],
},
},
]
WSGI_APPLICATION = 'wsgi.application'
# Database
# https://docs.djangoproject.com/en/1.8/ref/settings/#databases
DATABASES = {
'default': {
# Use 'sqlite3', 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
'ENGINE': 'django.db.backends.sqlite3',
# DB name or path to database file if using sqlite3.
'NAME': os.path.join(BASE_DIR, 'mailmansuite.db'),
# The following settings are not used with sqlite3:
'USER': 'mailmansuite',
'PASSWORD': 'mmpass',
# HOST: empty for localhost through domain sockets or '127.0.0.1' for
# localhost through TCP.
'HOST': '',
# PORT: set to empty string for default.
'PORT': '',
}
# Example for PostgreSQL (recommanded for production):
#'default': {
# 'ENGINE': 'django.db.backends.postgresql_psycopg2',
# 'NAME': 'database_name',
# 'USER': 'database_user',
# 'PASSWORD': 'database_password',
# 'HOST': 'localhost',
#}
}
# If you're behind a proxy, use the X-Forwarded-Host header
# See https://docs.djangoproject.com/en/1.8/ref/settings/#use-x-forwarded-host
# USE_X_FORWARDED_HOST = True
# And if your proxy does your SSL encoding for you, set SECURE_PROXY_SSL_HEADER
# https://docs.djangoproject.com/en/1.8/ref/settings/#secure-proxy-ssl-header
# SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
# SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_SCHEME', 'https')
# Other security settings
# SECURE_SSL_REDIRECT = True
# If you set SECURE_SSL_REDIRECT to True, make sure the SECURE_REDIRECT_EXEMPT
# contains at least this line:
# SECURE_REDIRECT_EXEMPT = [
# "archives/api/mailman/.*", # Request from Mailman.
# ]
# SESSION_COOKIE_SECURE = True
# SECURE_CONTENT_TYPE_NOSNIFF = True
# SECURE_BROWSER_XSS_FILTER = True
# CSRF_COOKIE_SECURE = True
# CSRF_COOKIE_HTTPONLY = True
# X_FRAME_OPTIONS = 'DENY'
# Password validation
# https://docs.djangoproject.com/en/1.9/ref/settings/#auth-password-validators
AUTH_PASSWORD_VALIDATORS = [
{
'NAME':
'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
},
{
'NAME':
'django.contrib.auth.password_validation.MinimumLengthValidator',
},
{
'NAME':
'django.contrib.auth.password_validation.CommonPasswordValidator',
},
{
'NAME':
'django.contrib.auth.password_validation.NumericPasswordValidator',
},
]
# Internationalization
# https://docs.djangoproject.com/en/1.8/topics/i18n/
LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = True
USE_L10N = True
USE_TZ = True
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/1.8/howto/static-files/
# Absolute path to the directory static files should be collected to.
# Don't put anything in this directory yourself; store your static files
# in apps' "static/" subdirectories and in STATICFILES_DIRS.
# Example: "/var/www/example.com/static/"
STATIC_ROOT = os.path.join(BASE_DIR, 'static')
# URL prefix for static files.
# Example: "http://example.com/static/", "http://static.example.com/"
STATIC_URL = '/static/'
# Additional locations of static files
STATICFILES_DIRS = (
# Put strings here, like "/home/html/static" or "C:/www/django/static".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.
# BASE_DIR + '/static/',
)
# List of finder classes that know how to find static files in
# various locations.
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
# 'django.contrib.staticfiles.finders.DefaultStorageFinder',
'compressor.finders.CompressorFinder',
)
# Django 1.6+ defaults to a JSON serializer, but it won't work with
# django-openid, see
# https://bugs.launchpad.net/django-openid-auth/+bug/1252826
SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'
LOGIN_URL = 'account_login'
LOGIN_REDIRECT_URL = 'list_index'
LOGOUT_URL = 'account_logout'
# If you enable internal authentication, this is the address that the emails
# will appear to be coming from. Make sure you set a valid domain name,
# otherwise the emails may get rejected.
# https://docs.djangoproject.com/en/1.8/ref/settings/#default-from-email
# DEFAULT_FROM_EMAIL = "mailing-lists(a)you-domain.org"
DEFAULT_FROM_EMAIL = 'postorius(a)localhost.local'
# If you enable email reporting for error messages, this is where those emails
# will appear to be coming from. Make sure you set a valid domain name,
# otherwise the emails may get rejected.
# https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SERVER_EMAIL
# SERVER_EMAIL = 'root(a)your-domain.org'
SERVER_EMAIL = 'root(a)localhost.local'
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
# Compatibility with Bootstrap 3
from django.contrib.messages import constants as messages # flake8: noqa
MESSAGE_TAGS = {
messages.ERROR: 'danger'
}
#
# Social auth
#
AUTHENTICATION_BACKENDS = (
'django.contrib.auth.backends.ModelBackend',
'allauth.account.auth_backends.AuthenticationBackend',
)
# Django Allauth
ACCOUNT_AUTHENTICATION_METHOD = "username_email"
ACCOUNT_EMAIL_REQUIRED = True
ACCOUNT_EMAIL_VERIFICATION = "mandatory"
# You probably want https in production, but this is a dev setup file
ACCOUNT_DEFAULT_HTTP_PROTOCOL = "http"
ACCOUNT_UNIQUE_EMAIL = True
SOCIALACCOUNT_PROVIDERS = {
'openid': {
'SERVERS': [
dict(id='yahoo',
name='Yahoo',
openid_url='http://me.yahoo.com'),
],
},
'google': {
'SCOPE': ['profile', 'email'],
'AUTH_PARAMS': {'access_type': 'online'},
},
'facebook': {
'METHOD': 'oauth2',
'SCOPE': ['email'],
'FIELDS': [
'email',
'name',
'first_name',
'last_name',
'locale',
'timezone',
],
'VERSION': 'v2.4',
},
}
#
# Gravatar
# https://github.com/twaddington/django-gravatar
#
# Gravatar base url.
# GRAVATAR_URL = 'http://cdn.libravatar.org/'
# Gravatar base secure https url.
# GRAVATAR_SECURE_URL = 'https://seccdn.libravatar.org/'
# Gravatar size in pixels.
# GRAVATAR_DEFAULT_SIZE = '80'
# An image url or one of the following: 'mm', 'identicon', 'monsterid',
# 'wavatar', 'retro'.
# GRAVATAR_DEFAULT_IMAGE = 'mm'
# One of the following: 'g', 'pg', 'r', 'x'.
# GRAVATAR_DEFAULT_RATING = 'g'
# True to use https by default, False for plain http.
# GRAVATAR_DEFAULT_SECURE = True
#
# django-compressor
# https://pypi.python.org/pypi/django_compressor
#
COMPRESS_PRECOMPILERS = (
('text/less', 'lessc {infile} {outfile}'),
('text/x-scss', 'sass -t compressed {infile} {outfile}'),
('text/x-sass', 'sass -t compressed {infile} {outfile}'),
)
# On a production setup, setting COMPRESS_OFFLINE to True will bring a
# significant performance improvement, as CSS files will not need to be
# recompiled on each requests. It means running an additional "compress"
# management command after each code upgrade.
# http://django-compressor.readthedocs.io/en/latest/usage/#offline-compression
# COMPRESS_OFFLINE = True
# Needed for debug mode
# INTERNAL_IPS = ('127.0.0.1',)
#
# Full-text search engine
#
HAYSTACK_CONNECTIONS = {
'default': {
'ENGINE': 'haystack.backends.whoosh_backend.WhooshEngine',
'PATH': os.path.join(BASE_DIR, "fulltext_index"),
# You can also use the Xapian engine, it's faster and more accurate,
# but requires another library.
# http://django-haystack.readthedocs.io/en/v2.4.1/installing_search_engines.h…
# Example configuration for Xapian:
#'ENGINE': 'xapian_backend.XapianEngine'
},
}
#
# Asynchronous tasks
#
Q_CLUSTER = {
'timeout': 300,
'save_limit': 100,
'orm': 'default',
}
# A sample logging configuration. The only tangible logging
# performed by this configuration is to send an email to
# the site admins on every HTTP 500 error when DEBUG=False.
# See http://docs.djangoproject.com/en/dev/topics/logging for
# more details on how to customize your logging configuration.
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'filters': {
'require_debug_false': {
'()': 'django.utils.log.RequireDebugFalse'
}
},
'handlers': {
'mail_admins': {
#'level': 'ERROR',
'level': 'INFO',
'filters': ['require_debug_false'],
'class': 'django.utils.log.AdminEmailHandler'
},
'file':{
#'level': 'ERROR',
'level': 'INFO',
#'class': 'logging.handlers.RotatingFileHandler',
'class': 'logging.handlers.WatchedFileHandler',
'filename': os.path.join(BASE_DIR, 'logs', 'mailmansuite.log'),
'formatter': 'verbose',
},
'console': {
'class': 'logging.StreamHandler',
'formatter': 'simple',
},
},
'loggers': {
'django.request': {
'handlers': ['mail_admins', 'file'],
#'level': 'ERROR',
'level': 'INFO',
'propagate': True,
},
'django': {
'handlers': ['file'],
#'level': 'ERROR',
'level': 'INFO',
'propagate': True,
},
'hyperkitty': {
'handlers': ['file'],
#'level': 'DEBUG',
'level': 'INFO',
'propagate': True,
},
'postorius': {
'handlers': ['console', 'file'],
#'level': 'ERROR',
'level': 'INFO',
},
},
'formatters': {
'verbose': {
'format': '%(levelname)s %(asctime)s %(process)d %(name)s %(message)s'
},
'simple': {
'format': '%(levelname)s %(message)s'
},
},
'root': {
'handlers': ['file'],
#'level': 'ERROR',
'level': 'INFO',
},
}
# Using the cache infrastructure can significantly improve performance on a
# production setup. This is an example with a local Memcached server.
#CACHES = {
# 'default': {
# 'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',
# 'LOCATION': '127.0.0.1:11211',
# }
#}
# When DEBUG is True, don't actually send emails to the SMTP server, just store
# them in a directory. This way you won't accidentally spam your mailing-lists
# while you're fiddling with the code.
# Kept DEBUG=True as it breaks css styling when set to False so commented out this code as temp fix.
#if DEBUG == True:
# EMAIL_BACKEND = 'django.core.mail.backends.filebased.EmailBackend'
# EMAIL_FILE_PATH = os.path.join(BASE_DIR, 'emails')
#
# HyperKitty-specific
#
# Only display mailing-lists from the same virtual host as the webserver
FILTER_VHOST = False
POSTORIUS_TEMPLATE_BASE_URL = 'http://localhost:8000'
try:
from settings_local import *
except ImportError:
pass
6 years, 2 months
Re: Newbie question 2: Rewriting issue for bounced emails
by William Oliver
On Sat, 2021-12-25 at 21:32 -0800, Mark Sapiro wrote:
>
>
> Have you added an Alias Domain for your domain?
>
> After doing that did you run `mailman aliases` or restart mailman to
> (re)generate the files.
>
> postfix_domains postfix_lmtp postfix_vmap
> postfix_domains.db postfix_lmtp.db postfix_vmap.db
>
>
> --
>
First, thanks for your patience. Two steps forward and one step back,
here. I have the interface running and I can create a list which
*does* send messages to my test recipients.
To answer your question, yes, I did all that, and that generates
postfix_domains and postfix_lmtp, but not postfix_vmap. Here's what I
got:
$more postfix_domains
# AUTOMATICALLY GENERATED BY MAILMAN ON 2021-12-26 22:29:27
#
# This file is generated by Mailman, and is kept in sync with the
binary hash
# file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what
you're
# doing, and can keep the two files properly in sync. If you screw it
up,
# you're on your own.
libertyfp.org libertyfp.org
$more postfix_lmtp
# AUTOMATICALLY GENERATED BY MAILMAN ON 2021-12-26 22:29:27
#
# This file is generated by Mailman, and is kept in sync with the
binary hash
# file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what
you're
# doing, and can keep the two files properly in sync. If you screw it
up,
# you're on your own.
# Aliases which are visible only in the @libertyfp.org domain.
testlist(a)libertyfp.org lmtp:[mail.libertyfp.org]:8024
testlist-bounces(a)libertyfp.org lmtp:[mail.libertyfp.org]:8024
testlist-confirm(a)libertyfp.org lmtp:[mail.libertyfp.org]:8024
testlist-join(a)libertyfp.org lmtp:[mail.libertyfp.org]:8024
testlist-leave(a)libertyfp.org lmtp:[mail.libertyfp.org]:8024
testlist-owner(a)libertyfp.org lmtp:[mail.libertyfp.org]:8024
testlist-request(a)libertyfp.org lmtp:[mail.libertyfp.org]:8024
testlist-subscribe(a)libertyfp.org lmtp:[mail.libertyfp.org]:8024
testlist-unsubscribe(a)libertyfp.org lmtp:[mail.libertyfp.org]:8024
But no postfix_vmap.
However, let me ask another question first:
When running mailman3, do I need to set up a completely different
virtual domain for it to run in? My "real" domain name is
libertyfp.org, and I'm trying to make mailman work on that domain, e.g.
"testlist(a)libertyfp.org." I'm starting to get the idea that I need to
stick a completely different domain in there for the mailinglist.
Which I can do -- I've got another two or three domain names to play
with. Is it a problem to run the mailinglist on the same domain that
the machine sits on for its regular business? A lot of the errors I'm
getting seem to be from trying to do regular mail *and* the mailinglist
on the same domain.
Now that I've installed all this stuff a couple of times, I can easily
re-install for a second virtual domain, if that's what I should be
doing.
But, on to what's not working now...
Unfortunately, I seem to have completely screwed the pooch on getting
postfix/dovecot to play nicely with respect to *receiving* mail.
First, adding "virtual_alias_domains" (and putting libertyfp.org in it)
and commenting out "virtual_mailbox_domains" resulted in postfix
ignoring all my virtual mailboxes. Mail still worked, but mail is now
being sent to /home/<user>/Maildir instead of
/home/vmail/libertyfp/<user>/Maildir -- which means that dovecot, which
looks in the virtual mailboxes, is now unaware of new mail. I suppose
I could link /home/<user>/Maildir to
/home/vmail/libertyfp.org/<user>/Maildir, but I suspect there will be
problems and it's not a real fix. But.. .a problem for another day.
Except... the same thing is happening with the mailinglist.
In mailman3:
I set up a test list (testlist(a)libertyfp.org) and added two test users
(one local and one on a different domain). They added just fine, and
both received the welcome message.
However, when I replied, both messages bounced with the error that
"testlist(a)libertyfp.org" was "user unknown in virtual alias table."
No problem, I thought. So I added:
testlist(a)libertyfp.org testlist
to /etc/postfix/virtual, and
testlist libertyfp.org/testlist/Maildir
to /etc/postfix/virtual-mailbox,
and I added testlist as a user:
$ adduser -m testlist
So, now mail from my list members goes to /home/testlist/Maildir, but
not to the mailinglist.
I also have managed to get another *different* warning, and the "there
ain't no vmap, newbie" error as well:
Dec 26 17:33:11 libertyfp systemd[1]: certbot.service: Consumed 1.041s
CPU time.
Dec 26 17:33:12 libertyfp postfix/smtpd[46453]: error: open database
/opt/mailman/mm/var/data/postfix_vmap.db: No such file or directory
Dec 26 17:33:12 libertyfp postfix/smtpd[46453]: error: unsupported
dictionary type: #hash
Dec 26 17:33:12 libertyfp postfix/smtpd[46453]: connect from
billoblog.com[162.144.108.19]
Dec 26 17:33:16 libertyfp postfix/trivial-rewrite[46479]: warning: do
not list domain libertyfp.org in BOTH virtual_alias_domains and
relay_domains
Dec 26 17:33:16 libertyfp postfix/smtpd[46453]: warning:
hash:/opt/mailman/mm/var/data/postfix_vmap is unavailable. open
database /opt/mailman/mm/var/data/postfix_vmap.db: No such file or
directory
Dec 26 17:33:16 libertyfp postfix/smtpd[46453]: warning:
hash:/opt/mailman/mm/var/data/postfix_vmap lookup error for
"fplist(a)libertyfp.org"
Dec 26 17:33:16 libertyfp postfix/smtpd[46453]: NOQUEUE: reject: RCPT
from billoblog.com[162.144.108.19]: 451 4.3.0 <fplist(a)libertyfp.org>:
Temporary lookup failure; from=<billo(a)billoblog.com>
to=<fplist(a)libertyfp.org> proto=ESMTP helo=<billoblog.com>
That "you can't have both virtual_alias_domains" and "relay_domains"
seems like it should be a clue. But I don't' know what for. Adding
virtual_alias_domains really changed things...
Anyway, here's the part of the /etc/postfix/main.cf that I think is
likely important. Note that I comments out "virtual_mailbox_domains".
myorigin = localhost
mydestination = localhost, localhost.$mydomain
alias_maps = /etc/aliases (which, by the way, just contains
"postmaster: root")
home_mailbox= Maildir
# add to the end (add ssl support)
smtpd_use_tls = yes
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_cert_file = /etc/letsencrypt/live/libertyfp.org/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/libertyfp.org/privkey.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
# add to the end (add virtual users)
# if specify multiple domains, specify comma or space separated
#virtual_mailbox_domains = libertyfp.org
virtual_mailbox_base = /home/vmail
virtual_mailbox_maps = hash:/etc/postfix/virtual-mailbox
virtual_uid_maps = static:20000
virtual_gid_maps = static:20000
# mailman3 changes
owner_request_special = no
always_add_missing_headers = yes
transport_maps = hash:/opt/mailman/mm/var/data/postfix_lmtp
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
hash:/opt/mailman/mm/var/data/postfix_lmtp
relay_domains = hash:/opt/mailman/mm/var/data/postfix_domains
default_destination_recipient_limit = 30
default_destination_concurrency_limit = 15
virtual_alias_domains = hash:/etc/postfix/domains
virtual_alias_maps = hash:/opt/mailman/mm/var/data/postfix_vmap
#hash:/etc/postfix/virtual
Here's the postfix maps:
/etc/postfix/domains:
libertyfp.org #
/etc/postfix/virtual:
fp145(a)libertyfp.org fp145
mailman(a)libertyfp.org mailman
testlist(a)libertyfp.org testlist
/etc/postfix/virtual-mailbox:
mailman libertyfp.org/mailadmin/Maildir/
fp145@localhost libertyfp.org/fp145/Maildir/
testlist libertyfp.org/testlist/Maildir
4 years, 7 months
Re: Issues with Mail delivery after Mailman 3 installation
by Chihurumnaya Ibiam
After making the above changes I talked about, mail transfer seems to work
as expected,
although I noticed users signing up don't get their confirmation emails
delivered for some reason, saw this in the logs;
(1632818) <177024281405.1632816.13618430493699791595(a)localhost.localdomain>
delivery to ibiam(a)sugarlabs.org failed with code 550, b'5.1.1 <
ibiam(a)sugarlabs.org>: Recipient address rejected: User unknown in local
recipient table'
What would be the best way to ensure that these get delivered?
Thank you for all your help, I really appreciate it.
I think I went into this rabbit hole because of this particular issue
above, and I thought something was wrong, mail was always sent to the
mailman user
and I thought that was odd, but now I know that's expected as that's the
user that Mailman runs on.
--
Ibiam Chihurumnaya
ibiamchihurumnaya(a)gmail.com
On Wed, Feb 4, 2026 at 10:15 PM Chihurumnaya Ibiam <
ibiamchihurumnaya(a)gmail.com> wrote:
> On Wed, Feb 4, 2026 at 9:06 PM Stephen J. Turnbull <steve(a)turnbull.jp>
> wrote:
>
>> Chihurumnaya Ibiam via Mailman-users writes:
>> > On Wed, Feb 4, 2026 at 4:21?PM Stephen J. Turnbull <steve(a)turnbull.jp>
>> > wrote:
>> >
>> > > Chihurumnaya Ibiam via Mailman-users writes:
>>
>> > Not uninstalled it, commented out from postfix master.cf the line;
>> > # dovecot unix - - y - - lmtp
>> [...]
>> > systemctl shows the service is still active,
>>
>> Life will be a lot easier if you shut that service down, and fix
>> whatever configuration in Postfix that's needed to talk directly to
>> Mailman (probably nothing since that configuration is in postfix_lmtp,
>> and if you put that table in transport_maps it's highest priority so
>> should work). You don't need a mailbox transport since you have no
>> local users who should be getting mail on the Mailman host, except
>> maybe root.
>>
>>
> I configured mailbox transport because that was how I was able to get lmtp
> to run on port 24,
> there wasn't any service before that and the documentation
> <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h…>
> for setting up a mail server mentions postfix delivering
> by default over port 24.
>
> Disabling this means there's no lmtp to be used by postfix, except I'm
> missing something.
>
> > I didn't end the service itself, I assumed the line above I
>> > commented out would prevent the dovecot service from running under
>> > postfix.
>>
>> The fact that there is a systemd service implies that dovecot will be
>> running by default unless it is disabled.
>>
>
> There's no service file for dovecot, I didn't create one.
>
>
>> If Mailman and Dovecot are running, each will try to open a socket with
>> parameters IP address and port number. The IP address is 127.0.0.1,
>> and the port number of Mailman is 24 according to the "mailman info"
>> output you provided. I don't know what the port number for Dovecot
>> is, but its default is also 24. If so, the one that opens that
>> listening socket first will win, and the other is going to be unable
>> to open its socket. I'm not sure if Mailman can even open a
>> privileged port (number less than 1024), since it should be running as
>> 'mailman', not 'root'.
>>
>>
> I set the port number for lmtp to be 24, and that's what I used, I'm not
> sure if Mailman sets up lmtp itself,
> if it does then I'll have to remove the config for that.
>
> I've stopped dovecot after our conversation so it's no longer running, the
> only way the port is open is through the
> config I set in postfix for mailbox_transport.
>
>
>> > Yes, that's how it's configured.
>>
>> Sure, but something is wrong with the configuration, and it might not
>> be just one thing.
>>
>
> I agree.
>
>
>>
>
> > I'll have to look at user authentication in lmtp then, because the
>> > earlier passwd-file arguments seems to have no effect, I probably
>> > didn't configure it properly.
>>
>> I don't understand why you have authentication for Mailman in any
>> case. From what you wrote before, there should only be one active
>> user on that host, and it's you, either as root or an ordinary user
>> with sudo. If anybody else can get in there, you have bigger problems
>> than connecting to ports 24 and 25.
>>
>
> There's just one active user, which is me, and I also have root access.
> I setup authentication for postfix because I'm used to setting it up that
> way, this was a force of habit.
> I assumed postfix would run just fine if I set postfix up the way I
> usually set it up.
>
>
>>
>> It may make sense for Postfix to authenticate to servers on other
>> hosts if it is purely internal to your network and does not talk to
>> the Internet. Similarly, it may make sense for Postfix to require
>> authentication for incoming messages if all your posters are expected
>> to send mail only from internal hosts. But if your Postfix talks to
>> hosts outside of your network, authentication should be off, because
>> almost certainly you have no way to configure it on the remote hosts.
>>
>
> This makes sense.
>
>
>>
>> > The listener on 24 is lmtp via postfix, the port opened after I
>> > added this line to postfix;
>> > mailbox_transport = lmtp:inet:localhost:24
>> >
>> > Dovecot also has lmtp as a running protocol, but that didn't open
>> > the port.
>>
>> This doesn't make sense. Mailman and Dovecot are LMTP servers, both
>> *must* open ports in order to receive connections. On the other hand,
>> Postfix is an LMTP client, it opens a connection to the port only when
>> it is delivering a message.
>>
>> What does "lsof -i @127.0.0.1 -i '@[::1]' | grep 24" output?
>>
>
> postgres 1592912 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> python3 1592922 mailman 27u IPv4 177685024 0t0 TCP
> localhost:8001 (LISTEN)
> python3 1592924 mailman 22u IPv6 177685051 0t0 TCP
> localhost:48638->localhost:postgresql (ESTABLISHED)
> postgres 1592939 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 1592941 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 1592943 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> python3 1592949 mailman 27u IPv4 177685024 0t0 TCP
> localhost:8001 (LISTEN)
> python3 1592950 mailman 27u IPv4 177685024 0t0 TCP
> localhost:8001 (LISTEN)
> postgres 1592953 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 1592954 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 1592954 postgres 9u IPv6 177686124 0t0 TCP
> localhost:postgresql->localhost:48498 (ESTABLISHED)
> postgres 1592955 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 1592957 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 1592959 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 1592963 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 1592966 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 1592970 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 1592974 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 1607364 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 1607478 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 3568035 postgres 5u IPv6 160224851 0t0 TCP
> localhost:postgresql (LISTEN)
> postgres 3568035 postgres 6u IPv4 160224852 0t0 TCP
> localhost:postgresql (LISTEN)
> postgres 3568035 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 3568037 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 3568038 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 3568039 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 3568040 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 3568041 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
> postgres 3568042 postgres 8u IPv6 160224857 0t0 UDP
> localhost:36787->localhost:36787
>
>
> The output shows mailman is indeed listening on the port, I now know
> Mailman is an LMTP server, I didn't know that before
> so there wasn't any need for me to do what I'd done.
>
>
>> > [mta] lmtp_host: *.*.*.*
>>
>> That should be 127.0.0.1. Mailman should not be listening on network
>> interfaces other than the loopback (localhost).
>>
>
> Yes, it is.
>
>
>>
>> > [mta] lmtp_port: 24
>>
>> This can't work if Dovecot is configured to use the same port, as is
>> Dovecot's default.
>>
>
> I've stopped the service.
>
>
>>
>> > [mta] outgoing: mailman.mta.deliver.deliver
>> > [mta] smtp_host: 127.0.0.1
>> > [mta] smtp_port: 25
>>
>> Those are normal.
>>
>> > [mta] smtp_pass: **************
>> > [mta] smtp_user: mailman
>>
>> This is going to cause Mailman to try to authenticate to Postfix.
>> That's OK if it's what you want and Postfix / saslauthd has been
>> properly configured to accept Mailman's credentials. Otherwise,
>> they must be left empty to disable authentication.
>>
>
> Okay.
>
>
>>
>> > I used the virtualenv method.
>>
>> Good. That's the preferred method, as distro packages generally lag
>> substantially, often a year or more.
>>
>>
> Yep, that's why I used it.
>
>
>> > The Message-ID being the way it is doesn't seem like a
>> > configuration issue, if it is then how do I look into it?
>>
>> Probably you don't have the full hostname in Postfix's myorigin or
>> myhostname parameter.
>>
>
> I do have the full hostname there, I also have it in /etc/mailname.
>
>
>> > Yes, it points to a configuration problem, the recipient_delimeter
>> > for postfix is set to +
>>
>> OK, then I don't know why mail is looping in that way.
>>
>> > How do I disable outgoing authentication? I don't remember enabling
>> > it.
>>
>> As mentioned above, you leave smtp_user and smtp_pass empty.
>>
>> > I also just noticed this in the logs;
>> >
>> > NOQUEUE: reject: RCPT from unknown[141.98.11.11]: 554 5.7.1
>> > <allenmccathyesq(a)gmail.com>: Relay access denied;
>> > from=<marketing(a)lists.sugarlabs.org> to=<allenmccathyesq(a)gmail.com>
>> > proto=ESMTP helo=<LS57X2JsBM>
>>
>> Reverse lookup for 141.98.11.11 returns axon-stall.riddlecamera.net,
>> but that doesn't roundtrip (the lookup on that domain goes to a
>> different customer address in Google Cloud). The IP address appears
>> to be in Lithuania. Is any of that expected? If not, I would guess
>> that's a spammer who is somehow spoofing the PTR record.
>>
>
> The log entry before that warned of the same, they're definitely a spammer.
> Relay access is denied though, so no mails are going through.
>
> The IP for the host that mailman is on does have a valid PTR record.
>
>
>>
>> > I turned submission back on, totally forgot it was used that way.
>>
>> What do you mean by "submission"? This entry in Postfix's master.cf?
>> submission inet n - y - - smtpd
>> (along with any -o options you are using)
>>
>
> No, I mean smtps.
>
> Someone uses that alias to send out emails, hence why I need it.
> Might have to disable smtps entirely as I just checked the old config and
> it's not used
> like I thought.
>
>
>>
>> If so, Mailman isn't going to use it, because Postfix's submission
>> service is an smtpd that listens on port 587 (unless you've changed
>> that in /etc/services). But you've specified that Mailman talk to
>> Postfix via port 25.
>>
>
> I had changed it, and I didn't do it for postfix.
>
>
>>
>> > I also added permit_auth_destination to smtpd_relay_restrictions for
>> the
>> > Relay access denied issue.
>>
>> I don't think permit_auth_destination does what you think it does.
>> Here's the Postfix doc:
>>
>> permit_auth_destination
>> Permit the request when one of the following is true:
>>
>> - Postfix is a mail forwarder: the resolved RCPT TO domain
>> matches $relay_domains or a subdomain thereof, and the address
>> contains no sender-specified routing (user@elsewhere@domain),
>> - Postfix is the final destination: the resolved RCPT TO domain
>> matches $mydestination, $inet_interfaces, $proxy_interfaces,
>> $virtual_alias_domains, or $virtual_mailbox_domains, and the
>> address contains no sender-specified routing
>> (user@elsewhere@domain).
>>
>
> I did read the documentation before adding it, I definitely misunderstood
> what it meant, and after looking at the old
> documentation, it makes sense not to add it.
>
> Could you help me understand what the above means?
>
>
>>
>> I thought this host is dedicated to Mailman? If so, you just want
>> permit_mynetworks in relay restrictions, and mynetworks_style = host.
>> This does what you want because Mailman is *not* an MTA. As far as
>> Postfix is concerned, delivery to Mailman is a *local* delivery (LMTP,
>> yes?), and the messages being delivered to subscribers are *new*
>> messages being sent by a *local* user. It is not a relay as far as
>> Postfix can tell. And $relay_domains should be empty, you don't want
>> anything else permitted.
>>
>
> Yes, this host is dedicated to Mailman.
>
> These are listed in smtpd_relay_restrictions;
> permit_mynetworks
> permit_sasl_authenticated
> reject_unauth_destination
> reject_unknown_recipient_domain
> reject_non_fqdn_recipient
> reject_unlisted_recipient
>
>
>>
>> From Postfix docs:
>> smtpd_relay_restrictions
>> (default: permit_mynetworks, permit_sasl_authenticated,
>> defer_unauth_destination)
>>
>> which is mostly what you want on a dedicated Mailman host. In fact,
>> once I know things are working I would normally delete
>> permit_sasl_authenticated, since I don't want third parties coming in
>> through submission and relaying directly out through Postfix without
>> going through the malware checking done by the milters that should be
>> attached to Postfix's smtp service. I would also change
>> defer_unauth_destination to either reject_unauth_destination or
>> reject, since I don't want relay attempts to be retried.
>>
>>
> I'll remove permit_sasl_authenticated, as my assumption no longer holds.
> That's why I disabled it earlier because I remembered it was never used
> for delivery, but then I remembered
> there was a conversation about the marketing alias so I assumed it was
> used for sending out emails.
>
>
>> > I usually set postfix user authentication through saslauthd, which is
>> > configured to use /etc/shadow for user lookup.
>>
>> But there shouldn't be any users with passwords on that host except
>> you. You can set one and authenticate the 'mailman' user if you want,
>> but there's little point to it. Furthermore, any system users that
>> might send mail (eg, cron) won't be able to do so since there's
>> typically no provision for them to do the SASL AUTH dance.
>>
>
> I did set one for the mailman user, seems I'll have to remove it and
> disable saslauthd too.
>
>
>>
>> > I was just reminded that it's needed though, the log entry above
>> reminded
>> > me of that.
>>
>> Well, there's always the alternative of doing what I suggested, which
>> is to reconfigure the system to be as simple as possible, and add
>> complexity only when the simple configuration is working.
>>
>
> Yes, this is where I'm headed as that's what I need.
>
>>
>> Steve
>>
>> --
>> GNU Mailman consultant (installation, migration, customization)
>> Sirius Open Source https://www.siriusopensource.com/
>> Software systems consulting in Europe, North America, and Japan
>>
>
>
> --
>
> Ibiam Chihurumnaya
> ibiamchihurumnaya(a)gmail.com
>
>
>
>
5 months, 3 weeks