Issues with Mail delivery after Mailman 3 installation
I finished installing mailman3, setup lmtp and smtp for mail delivery and I followed the instructions on the mailman 3 installation page.
Mail delivery doesn't work and the logs show this;
Jan 31 12:53:53 lists postfix/lmtp[4131588]: 3B8121A89BD: to=<systems@lists.sugarlabs.org>, relay=127.0.0.1[127.0.0.1]:24, delay=11119, delays=11072/0.01/0.01/47, dsn=4.3.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.3.0 <systems@lists.sugarlabs.org> Temporary internal error (in reply to RCPT TO command)) 106029 Jan 31 12:53:53 lists postfix/lmtp[4131587]: 052BB1A8975: to=<mailman@lists.sugarlabs.org>, orig_to=<mailman>, relay=localhost[127.0.0.1]:24, delay=1432, delays=1385/0.02/0.01/47, dsn=4.3.0, status=deferred (host localhost[127.0.0.1] said: 451 4.3.0 <mailman@lists.sugarlabs.org> Temporary internal error (in reply to RCPT TO command)) Jan 31 12:53:53 lists dovecot: lmtp(4131586): Disconnect from 127.0.0.1: Logged out (state=READY) Jan 31 12:53:53 lists postfix/local[4131582]: F2DB61A8952: passing <mailman@lists.sugarlabs.org> to transport=lmtp Jan 31 12:53:53 lists dovecot: lmtp(4131590): Disconnect from 127.0.0.1: Logged out (state=READY) Jan 31 12:53:53 lists dovecot: lmtp(4131589): Disconnect from 127.0.0.1: Logged out (state=READY) Jan 31 12:53:53 lists postfix/local[4131584]: D172A1A8A0E: passing <mailman@lists.sugarlabs.org> to transport=lmtp Jan 31 12:53:53 lists dovecot: lmtp(4131586): Connect from 127.0.0.1 Jan 31 12:53:53 lists dovecot: lmtp(4131589): Connect from 127.0.0.1 Jan 31 12:53:54 lists postfix/lmtp[4128841]: connect to localhost[::1]:24: Connection refused Jan 31 12:53:54 lists postfix/lmtp[4128840]: connect to localhost[::1]:24: Connection refused Jan 31 12:53:54 lists postfix/lmtp[4128841]: 348981A8A2A: to=<mailman@lists.sugarlabs.org>, orig_to=<mailman>, relay=none, delay=113, delays=0.04/52/61/0, dsn=4.4.1, status=deferred (connect to localhost[::1]:24: Connection refused) Jan 31 12:53:54 lists postfix/lmtp[4128840]: 5382D1A8A27: to=<mailman@lists.sugarlabs.org>, orig_to=<mailman>, relay=none, delay=173, delays=0.02/111/61/0, dsn=4.4.1, status=deferred (connect to localhost[::1]:24: Connection refused) Jan 31 12:53:56 lists dovecot: lmtp(4128842): Disconnect from 127.0.0.1: Connection closed (state=READY) Jan 31 12:53:56 lists dovecot: lmtp(4127392): Disconnect from 127.0.0.1: Connection closed (state=READY) Jan 31 12:54:02 lists postfix/pickup[4131579]: 1D3E71A8A1C: uid=1005 from=<mailman> Jan 31 12:54:02 lists postfix/cleanup[4131852]: 1D3E71A8A1C: message-id=<20260131205402.1D3E71A8A1C@lists.sugarlabs.org> Jan 31 12:54:02 lists postfix/qmgr[4131580]: 1D3E71A8A1C: from=<mailman@lists.sugarlabs.org>, size=919, nrcpt=1 (queue active) Jan 31 12:54:53 lists dovecot: auth: Fatal: passdb passwd-file: Missing args Jan 31 12:54:53 lists dovecot: master: Error: service(auth): command startup failed, throttling for 60.000 secs Jan 31 12:54:53 lists dovecot: lmtp(mailman@lists.sugarlabs.org)<4131586><qMl1NuFrfmkCCz8AOj1W/w>: Error: auth-master: userdb lookup(mailman@lists.sugarlabs.org): Disconnected unexpectedly Jan 31 12:54:53 lists dovecot: lmtp(4131586): Error: lmtp-server: conn 127.0.0.1:56008 [2]: rcpt mailman@lists.sugarlabs.org: Failed to lookup user mailman@lists.sugarlabs.org: Internal error occurred. Refer to server log for more information. Jan 31 12:54:53 lists postfix/lmtp[4131585]: F2DB61A8952: host localhost[127.0.0.1] said: 451 4.3.0 <mailman@lists.sugarlabs.org> Temporary internal error (in reply to RCPT TO command) Jan 31 12:54:53 lists dovecot: lmtp(mailman@lists.sugarlabs.org)<4131589><kJd+NuFrfmkFCz8AOj1W/w>: Error: auth-master: userdb lookup(mailman@lists.sugarlabs.org): Disconnected unexpectedly Jan 31 12:54:53 lists dovecot: lmtp(4131589): Error: lmtp-server: conn 127.0.0.1:56014 [2]: rcpt mailman@lists.sugarlabs.org: Failed to lookup user mailman@lists.sugarlabs.org: Internal error occurred. Refer to server log for more information. Jan 31 12:54:53 lists postfix/lmtp[4131588]: D172A1A8A0E: host localhost[127.0.0.1] said: 451 4.3.0 <mailman@lists.sugarlabs.org> Temporary internal error (in reply to RCPT TO command) Jan 31 12:54:53 lists postfix/lmtp[4131585]: connect to localhost[::1]:24: Connection refused Jan 31 12:54:53 lists postfix/lmtp[4131588]: connect to localhost[::1]:24: Connection refused Jan 31 12:54:53 lists postfix/lmtp[4131585]: F2DB61A8952: to=<mailman@lists.sugarlabs.org>, orig_to=<mailman>, relay=none, delay=1492, delays=1385/47/60/0, dsn=4.4.1, status=deferred (connect to localhost[::1]:24: Connection refused) Jan 31 12:54:53 lists postfix/lmtp[4131588]: D172A1A8A0E: to=<mailman@lists.sugarlabs.org>, orig_to=<mailman>, relay=none, delay=591, delays=484/47/60/0, dsn=4.4.1, status=deferred (connect to localhost[::1]:24: Connection refused) Jan 31 12:54:53 lists postfix/local[4131582]: D92311A8A17: passing <mailman@lists.sugarlabs.org> to transport=lmtp Jan 31 12:54:53 lists postfix/local[4131584]: D52231A8A1A: passing <mailman@lists.sugarlabs.org> to transport=lmtp Jan 31 12:55:02 lists postfix/pickup[4131579]: 019161A8A2C: uid=1005 from=<mailman> Jan 31 12:55:02 lists postfix/cleanup[4131852]: 019161A8A2C: message-id=<20260131205502.019161A8A2C@lists.sugarlabs.org> Jan 31 12:55:02 lists postfix/qmgr[4131580]: 348981A8A2A: from=<mailman@lists.sugarlabs.org>, size=919, nrcpt=1 (queue active) Jan 31 12:55:02 lists postfix/qmgr[4131580]: 019161A8A2C: from=<mailman@lists.sugarlabs.org>, size=919, nrcpt=1 (queue active) Jan 31 12:55:02 lists postfix/qmgr[4131580]: 5382D1A8A27: from=<mailman@lists.sugarlabs.org>, size=919, nrcpt=1 (queue active) Jan 31 12:55:18 lists postfix/smtpd[4132212]: fatal: open dictionary: expecting "type:name" form instead of "dovecot"
I setup lmtp with dovecot, and I have this in dovecot.conf;
passdb passwd-file { driver = passwd-file }
I also have these set in postfix main.cf;
lmtp_sender_dependent_authentication = yes lmtp_sasl_auth_enable = yes lmtp_sasl_password_maps = hash:path_to_passwd_file
I'm wondering if I need to disable sasl because I set dovecot not to use ssl because lmtp is only running internally.
On 1/31/26 13:11, Ibiam Chihurumnaya via Mailman-users wrote:
I finished installing mailman3, setup lmtp and smtp for mail delivery and I followed the instructions on the mailman 3 installation page.
Mail delivery doesn't work and the logs show this; ... Jan 31 12:53:54 lists postfix/lmtp[4128841]: connect to localhost[::1]:24: Connection refused Jan 31 12:53:54 lists postfix/lmtp[4128840]: connect to localhost[::1]:24: Connection refused ...
Your /etc/hosts file has an IPv6 address for localhost and Postfix isn't listening for IPv6 connects
Either set the localhost IP in /etc/hosts to IPv4 as
127.0.0.1 localhost
or set
inet_interfaces = all inet_protocols = all
in Postfix main.cf
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Ibiam Chihurumnaya via Mailman-users writes:
I do have both inet_interfaces and inet_protocols set to all.
Note that that is just for Postfix. You also need to specify where Dovecot and Mailman are listening in their own configurations.
I suspect that Postfix will prefer IPv6 if available, so using "localhost" as the Mailman host may cause confusion. Use the IP address instead. If you specify the Mailman host as 127.0.0.1, I'm pretty sure that will work fine, as Mailman will listen on the specified port via IPv4, and the Postfix routing tables will be created with 127.0.0.1 and the specified port.
I don't know if Mailman will do the right thing if you specify [::1]; as far as I know we have never checked that Mailman is IPv6-clean, although the underlying Python libraries probably are.
If you have a preference for IPv6, we can discuss that after getting everything working with the well-tested IPv4 configuration.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Yes, I did specify the other ports needed in the necessary configurations.
You're right about "localhost" causing confusion, I switched to using the IP address instead, the logs showed that Mailman tried to connect on [::1] and there wasn't a response, that might be from Mailman itself though as the port is open.
I don't have a preference for IPv6.
--
Ibiam Chihurumnaya ibiamchihurumnaya@gmail.com
On Mon, Feb 2, 2026 at 4:44 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Ibiam Chihurumnaya via Mailman-users writes:
I do have both inet_interfaces and inet_protocols set to all.
Note that that is just for Postfix. You also need to specify where Dovecot and Mailman are listening in their own configurations.
I suspect that Postfix will prefer IPv6 if available, so using "localhost" as the Mailman host may cause confusion. Use the IP address instead. If you specify the Mailman host as 127.0.0.1, I'm pretty sure that will work fine, as Mailman will listen on the specified port via IPv4, and the Postfix routing tables will be created with 127.0.0.1 and the specified port.
I don't know if Mailman will do the right thing if you specify [::1]; as far as I know we have never checked that Mailman is IPv6-clean, although the underlying Python libraries probably are.
If you have a preference for IPv6, we can discuss that after getting everything working with the well-tested IPv4 configuration.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On 2/4/26 02:21, Chihurumnaya Ibiam via Mailman-users wrote:
You're right about "localhost" causing confusion, I switched to using the IP address instead, the logs showed that Mailman tried to connect on [::1] and there wasn't a response, that might be from Mailman itself though as the port is open.
I don't have a preference for IPv6.
Edit /etc/hosts and change the localhost entry from ::1 to 127.0.0.1
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
On 2/4/26 02:21, Chihurumnaya Ibiam via Mailman-users wrote:
You're right about "localhost" causing confusion, I switched to using the IP address instead, the logs showed that Mailman tried to connect on [::1] and there wasn't a response, that might be from Mailman itself though as the port is open. I don't have a preference for IPv6. Edit /etc/hosts and change the localhost entry from ::1 to 127.0.0.1
Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan I just did.
Mark, can you help me with Debugging the issue with confirmation emails not being sent?
I can see the uwsgi logs show that the confirm-email endpoint was accessed;
[Mon Feb 9 21:31:23 2026] GET /accounts/confirm-email/ => generated 1556 bytes in 40 msecs (HTTP/1.0 200) 9 headers in 359 bytes (1 switches on core 0)
but that's about it.
Nothing in postfix shows the email being sent or not sent, mailmanweb logs doesn't show anything either.
On 2/9/26 13:53, Ibiam Chihurumnaya via Mailman-users wrote:
Mark, can you help me with Debugging the issue with confirmation emails not being sent?
I can see the uwsgi logs show that the confirm-email endpoint was accessed;
[Mon Feb 9 21:31:23 2026] GET /accounts/confirm-email/ => generated 1556 bytes in 40 msecs (HTTP/1.0 200) 9 headers in 359 bytes (1 switches on core 0)
but that's about it.
What's in Django's log. Assuming your settings are like https://docs.mailman3.org/en/latest/install/virtualenv.html#initial-configur... the log will be at /opt/mailman/web/logs/mailmanweb.log.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
ERROR 2026-02-12 14:15:11,250 1985547 django.request Internal Server Error: /archives/list/soas@lists.sugarlabs.org/thread/CVAUPR7L6AYTNZXIWHQ263A6ZJUROTRC/ 233825 Traceback (most recent call last): 233826 File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner 233827 response = get_response(request) 233828 File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/base.py", line 197, in _get_response 233829 response = wrapped_callback(request, *callback_args, **callback_kwargs) 233830 File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/lib/view_helpers.py", line 137, in inner 233831 return func(request, *args, **kwargs) 233832 File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/views/thread.py", line 238, in thread_index 233833 return render(request, "hyperkitty/thread.html", context=context) 233834 File "/opt/mailman/venv/lib/python3.10/site-packages/django/shortcuts.py", line 25, in render 233835 content = loader.render_to_string(template_name, context, request, using=using) 233836 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/loader.py", line 62, in render_to_string 233837 return template.render(context, request) 233838 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/backends/django.py", line 107, in render 233839 return self.template.render(context) 233840 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 172, in render 233841 return self._render(context) 233842 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 164, in _render 233843 return self.nodelist.render(context) 233844 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 1018, in render 233845 return SafeString("".join([node.render_annotated(context) for node in self])) 233846 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 1018, in <listcomp> 233847 return SafeString("".join([node.render_annotated(context) for node in self])) 233848 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 979, in render_annotated 233849 return self.render(context) 233850 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/loader_tags.py", line 159, in render 233851 return compiled_parent._render(context) 233852 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 164, in _render 233853 return self.nodelist.render(context) 233854 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 1018, in render 233855 return SafeString("".join([node.render_annotated(context) for node in self])) 233856 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 1018, in <listcomp> 233857 return SafeString("".join([node.render_annotated(context) for node in self])) 233858 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 979, in render_annotated 233859 return self.render(context) 233860 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/loader_tags.py", line 65, in render 233861 result = block.nodelist.render(context) 233862 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 1018, in render 233863 return SafeString("".join([node.render_annotated(context) for node in self])) 233864 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 1018, in <listcomp> 233865 return SafeString("".join([node.render_annotated(context) for node in self])) 233866 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 979, in render_annotated 233867 return self.render(context) 233868 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/loader_tags.py", line 210, in render 233869 return template.render(context) 233870 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 174, in render 233871 return self._render(context) 233872 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 164, in _render 233873 return self.nodelist.render(context) 233874 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 1018, in render 233875 return SafeString("".join([node.render_annotated(context) for node in self])) 233876 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 1018, in <listcomp> 233877 return SafeString("".join([node.render_annotated(context) for node in self])) 233878 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 979, in render_annotated 233879 return self.render(context) 233880 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 1077, in render 233881 output = self.filter_expression.resolve(context) 233882 File "/opt/mailman/venv/lib/python3.10/site-packages/django/template/base.py", line 750, in resolve 233883 new_obj = func(obj, *arg_vals) 233884 File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/templatetags/decorate.py", line 42, in render 233885 return mark_safe(text_renderer(content)) 233886 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/markdown.py", line 120, in __call__ 233887 return self.parse(s)[0] 233888 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/markdown.py", line 93, in parse 233889 self.block.parse(state) 233890 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/block_parser.py", line 458, in parse 233891 end_pos2 = self.parse_method(m, state) 233892 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/core.py", line 216, in parse_method 233893 return func(m, state) 233894 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/block_parser.py", line 369, in parse_block_quote 233895 text, end_pos = self.extract_block_quote(m, state) 233896 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/block_parser.py", line 346, in extract_block_quote 233897 end_pos = self.parse_method(m4, state) 233898 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/core.py", line 216, in parse_method 233899 return func(m, state) 233900 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/block_parser.py", line 388, in parse_list 233901 return parse_list(self, m, state) 233902 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/list_parser.py", line 64, in parse_list 233903 groups = _parse_list_item(block, bullet, groups, token, state, rules) 233904 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/list_parser.py", line 178, in _parse_list_item 233905 block.parse(child, rules) 233906 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/block_parser.py", line 458, in parse 233907 end_pos2 = self.parse_method(m, state) 233908 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/core.py", line 214, in parse_method 233909 assert lastgroup 233910 AssertionError
This is the last error in the log, the errors before that are similar.
Please don't reply to unrelated threads when reporting a new issue. It's not just the subject being wrong (Django has nothing to do with delivery, this is a problem with viewing archives, I believe). Continuing a thread with an unrelated issue creates an apparent context which is at best temporarily confusing, and could interfere with solving the problem in worst case.
Ibiam Chihurumnaya via Mailman-users writes:
ERROR 2026-02-12 14:15:11,250 1985547 django.request Internal Server Error: /archives/list/soas@lists.sugarlabs.org/thread/CVAUPR7L6AYTNZXIWHQ263A6ZJUROTRC/
This is in HyperKitty, viewing a thread or a thread index.
233904 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/list_parser.py", line 178, in _parse_list_item 233905 block.parse(child, rules) 233906 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/block_parser.py", line 458, in parse 233907 end_pos2 = self.parse_method(m, state) 233908 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/core.py", line 214, in parse_method 233909 assert lastgroup 233910 AssertionError
I'm pretty sure this is a known bug in mistune. It's pretty much identical to the head of the thread ending the message below. (I don't think there's anything interesting in the followups to the thread, it's a different problem.)
See https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Stephen J. Turnbull wrote:
Please don't reply to unrelated threads when reporting a new issue. It's not just the subject being wrong (Django has nothing to do with delivery, this is a problem with viewing archives, I believe). Continuing a thread with an unrelated issue creates an apparent context which is at best temporarily confusing, and could interfere with solving the problem in worst case.
You're right, I'll open a different thread for this.
ERROR 2026-02-12 14:15:11,250 1985547 django.request Internal Server Error: /archives/list/soas@lists.sugarlabs.org/thread/CVAUPR7L6AYTNZXIWHQ263A6ZJUROTRC/ This is in HyperKitty, viewing a thread or a thread index. 233904 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/list_parser.py", line 178, in _parse_list_item 233905 block.parse(child, rules) 233906 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/block_parser.py", line 458, in parse 233907 end_pos2 = self.parse_method(m, state) 233908 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/core.py", line 214, in parse_method 233909 assert lastgroup 233910 AssertionError I'm pretty sure this is a known bug in mistune. It's pretty much identical to the head of the thread ending the message below. (I don't think there's anything interesting in the followups to the
Ibiam Chihurumnaya via Mailman-users writes: thread, it's a different problem.) See https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
Thank you!
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Ibiam Chihurumnaya via Mailman-users writes:
I finished installing mailman3, setup lmtp and smtp for mail delivery and I followed the instructions on the mailman 3 installation page.
First, make sure that all the mail services are listening on the same protocol for localhost (IPv4 or IPv6), as Mark says in his reply.
Is this a separate host (hardware, VM, or container) that handles ONLY mailman lists? Or do you want this host to handle other incoming mail as well? If it's dedicated to Mailman, you don't need Dovecot, and it complicates the system by quite a bit. Removing it from the system will simply configuration considerably. If the host is handling other incoming mail, then Dovecot is a good system for providing IMAP (and I seem to recall POP3 as well) for user mailboxes and well worth the complexity.
I've folded log messages below for readability.
Jan 31 12:53:54 lists postfix/lmtp[4128841]: 348981A8A2A: to=<mailman@lists.sugarlabs.org>, orig_to=<mailman>, relay=none, delay=113, delays=0.04/52/61/0, dsn=4.4.1, status=deferred (connect to localhost[::1]:24: Connection refused)
The log entry above says that you are sending Mailman (list) mail to port 24, the port used in Dovecot's documentation for 'inet' LMTP services. This may be in contention with Dovecot, unless you are trying to pass Mailman traffic through Dovecot. If Dovecot is listening on an 'inet' socket, what port is Dovecot listening on? What port is Mailman listening on?
I recommend that you NOT have Mailman pass through Dovecot, because it will be confusing to anyone familiar with Mailman operations trying to help you. Normally, Mailman listens on 8024, which is routed directly by the MTA (Postfix, in your case).
Jan 31 12:54:53 lists dovecot: lmtp(mailman@lists.sugarlabs.org)<4131586><qMl1NuFrfmkCCz8AOj1W/w>: Error: auth-master: userdb lookup(mailman@lists.sugarlabs.org): Disconnected unexpectedly
The log entry above says that Dovecot is trying to handle Mailman traffic, but something went wrong with the userdb lookup. I can't help you with that.
Jan 31 12:55:18 lists postfix/smtpd[4132212]: fatal: open dictionary: expecting "type:name" form instead of "dovecot"
I setup lmtp with dovecot, and I have this in dovecot.conf;
If you are referring to the log message above, that is from Postfix, and it appears that one of Postfix's tables is configure as "dovecot" rather than a proper Postfix database.
passdb passwd-file { driver = passwd-file }
I also have these set in postfix main.cf;
lmtp_sender_dependent_authentication = yes lmtp_sasl_auth_enable = yes lmtp_sasl_password_maps = hash:path_to_passwd_file
I assume that "path_to_password_file" is a placeholder for the password file, which is typically /etc/postfix/sasl/sasl_passwd.db, compiled from the source in /etc/postfix/sasl/sasl_passwd using postmap.
I'm wondering if I need to disable sasl because I set dovecot not to use ssl because lmtp is only running internally.
SASL authentication is independent in the SMTP protocol with a separate keyword "AUTH", so disabling SSL is irrelevant unless Postfix always uses TLS (a very unusual configuration for a Mailman site). However, as long as LMTP is running only internally, I believe authentication is not very useful since any attacker who can access internal communications likely can read the password file and authenticate.
Too many things can go wrong. I recommend that you disable all the authentication until you have all mail flows working without authentication, then add authentication as you require for your applications.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On Sun, Feb 1, 2026 at 7:25 AM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Ibiam Chihurumnaya via Mailman-users writes:
I finished installing mailman3, setup lmtp and smtp for mail delivery and I followed the instructions on the mailman 3 installation page.
First, make sure that all the mail services are listening on the same protocol for localhost (IPv4 or IPv6), as Mark says in his reply.
Is this a separate host (hardware, VM, or container) that handles ONLY mailman lists? Or do you want this host to handle other incoming mail as well? If it's dedicated to Mailman, you don't need Dovecot, and it complicates the system by quite a bit. Removing it from the system will simply configuration considerably. If the host is handling other incoming mail, then Dovecot is a good system for providing IMAP (and I seem to recall POP3 as well) for user mailboxes and well worth the complexity.
Yes, it's a separate host that handles only mailman lists, it doesn't handle other incoming mail.
I'll remove dovecot, and report back.
I've folded log messages below for readability.
Jan 31 12:53:54 lists postfix/lmtp[4128841]: 348981A8A2A: to=<mailman@lists.sugarlabs.org>, orig_to=<mailman>, relay=none, delay=113, delays=0.04/52/61/0, dsn=4.4.1, status=deferred (connect to localhost[::1]:24: Connection refused)
The log entry above says that you are sending Mailman (list) mail to port 24, the port used in Dovecot's documentation for 'inet' LMTP services. This may be in contention with Dovecot, unless you are trying to pass Mailman traffic through Dovecot. If Dovecot is listening on an 'inet' socket, what port is Dovecot listening on? What port is Mailman listening on?
Yes, I used port 24 because of Dovecot's documentation, and the goal was to pass mailman traffic through Dovecot for authentication.
I only configured lmtp for Dovecot to listen on port 24, I didn't configure any other service.
I recommend that you NOT have Mailman pass through Dovecot, because it will be confusing to anyone familiar with Mailman operations trying to help you. Normally, Mailman listens on 8024, which is routed directly by the MTA (Postfix, in your case).
I don't see mailman listening on 8024 from my end, the port isn't open.
Jan 31 12:54:53 lists dovecot: lmtp(mailman@lists.sugarlabs.org)<4131586><qMl1NuFrfmkCCz8AOj1W/w>: Error: auth-master: userdb lookup(mailman@lists.sugarlabs.org): Disconnected unexpectedly
The log entry above says that Dovecot is trying to handle Mailman traffic, but something went wrong with the userdb lookup. I can't help you with that.
Jan 31 12:55:18 lists postfix/smtpd[4132212]: fatal: open dictionary: expecting "type:name" form instead of "dovecot"
I setup lmtp with dovecot, and I have this in dovecot.conf;
If you are referring to the log message above, that is from Postfix, and it appears that one of Postfix's tables is configure as "dovecot" rather than a proper Postfix database.
passdb passwd-file { driver = passwd-file }
I also have these set in postfix main.cf;
lmtp_sender_dependent_authentication = yes lmtp_sasl_auth_enable = yes lmtp_sasl_password_maps = hash:path_to_passwd_file
I assume that "path_to_password_file" is a placeholder for the password file, which is typically /etc/postfix/sasl/sasl_passwd.db, compiled from the source in /etc/postfix/sasl/sasl_passwd using postmap.
Yes, it's a placeholder for the password file, and yes it was compiled using postmap.
I'm wondering if I need to disable sasl because I set dovecot not to use ssl because lmtp is only running internally.
SASL authentication is independent in the SMTP protocol with a separate keyword "AUTH", so disabling SSL is irrelevant unless Postfix always uses TLS (a very unusual configuration for a Mailman site). However, as long as LMTP is running only internally, I believe authentication is not very useful since any attacker who can access internal communications likely can read the password file and authenticate.
Too many things can go wrong. I recommend that you disable all the authentication until you have all mail flows working without authentication, then add authentication as you require for your applications.
I'll try this, thank you!
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@gmail.com
Chihurumnaya Ibiam via Mailman-users writes:
On Sun, Feb 1, 2026 at 7:25?AM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Is this a separate host (hardware, VM, or container) that handles ONLY mailman lists?
Yes, it's a separate host that handles only mailman lists, it doesn't handle other incoming mail.
I'll remove dovecot, and report back.
Good, that will make getting set up easier.
I recommend that you NOT have Mailman pass through Dovecot, because it will be confusing to anyone familiar with Mailman operations trying to help you. Normally, Mailman listens on 8024, which is routed directly by the MTA (Postfix, in your case).
I don't see mailman listening on 8024 from my end, the port isn't open.
Hm. Did you start Mailman?
If Mailman is started, what port is in your mailman.cfg file? (Search for "lmtp" (without the quotes) in that file, it will say what host and port Mailman is listening on.) Do not assume you know where that file is (normally /etc/mailman3/mailman.cfg). If you are starting Mailman via systemd, check the service file for a "-C conffile" option in the start command. If you are using the 'mailman' utility, cd to the directory where you normally start Mailman, and use "mailman info" to find out where the running Mailman thinks the configuration file is.
Too many things can go wrong. I recommend that you disable all the authentication until you have all mail flows working without authentication, then add authentication as you require for your applications.
I'll try this, thank you!
OK, let us know!
You mentioned that you wanted Dovecot to do authentication. I don't know if Mailman can do authentication itself. I think the Python module can, but I don't know how to set it up. I personally don't think it's necessary on a dedicated host where Mailman and the MTA can communicate over the loopback address, but if you do, let me know and I'll see what we can do.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On Mon, Feb 2, 2026 at 4:56 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
On Sun, Feb 1, 2026 at 7:25?AM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Is this a separate host (hardware, VM, or container) that handles ONLY mailman lists?
Yes, it's a separate host that handles only mailman lists, it doesn't handle other incoming mail.
I'll remove dovecot, and report back.
Good, that will make getting set up easier.
I've removed this, and it does seem like dovecot still runs when mailman hands mail to lmtp, but I don't see any authentication issues, the logs show this;
lists postfix/lmtp[1376243]: 458381A894B: to=<mailman@lists.sugarlabs.org>, orig_to=<mailman>, relay=localhost[127.0.0.1]:24, delay=0.03, delays=0.02/0/0.01/0, dsn=5.1.1, status=bounced (host localhost[127.0.0.1] said: 550 5.1.1 <mailman@lists.sugarlabs.org> User doesn't exist: mailman@lists.sugarlabs.org (in reply to RCPT TO command))
The user does exist, which is the weird part.
I recommend that you NOT have Mailman pass through Dovecot, because it will be confusing to anyone familiar with Mailman operations trying to help you. Normally, Mailman listens on 8024, which is routed directly by the MTA (Postfix, in your case).
I don't see mailman listening on 8024 from my end, the port isn't open.
Hm. Did you start Mailman?
If Mailman is started, what port is in your mailman.cfg file? (Search for "lmtp" (without the quotes) in that file, it will say what host and port Mailman is listening on.) Do not assume you know where that file is (normally /etc/mailman3/mailman.cfg). If you are starting Mailman via systemd, check the service file for a "-C conffile" option in the start command. If you are using the 'mailman' utility, cd to the directory where you normally start Mailman, and use "mailman info" to find out where the running Mailman thinks the configuration file is.
I'm starting mailman via systemd, and the mailman config was passed through an environment variable - MAILMAN_CONFIG_FILE -.
The installation instructions <https://docs.mailman3.org/en/latest/install/install.html> don't say anything about mailman listening on a port
Too many things can go wrong. I recommend that you disable all the authentication until you have all mail flows working without authentication, then add authentication as you require for your applications.
I'll try this, thank you!
OK, let us know!
You mentioned that you wanted Dovecot to do authentication. I don't know if Mailman can do authentication itself. I think the Python module can, but I don't know how to set it up. I personally don't think it's necessary on a dedicated host where Mailman and the MTA can communicate over the loopback address, but if you do, let me know and I'll see what we can do.
I've removed authentication and the only error in the log is the one I shared above, although there are some errors in mailman smtp logs;
1551 Jan 31 12:44:03 2026 (4128778) <176979064563.3611678.6370323034981829398@lists> smtp to sugar-devel@lists.sugarlabs.org for 1 recips, completed in 0.009501457214355469 seconds 1552 Jan 31 12:44:03 2026 (4128778) <176979064563.3611678.6370323034981829398@lists> post to sugar-devel@lists.sugarlabs.org from sugar-devel-confirm+edc5e1df6d76fe7955475023efd08101ed2edb17@lists.sugarlabs.org, 1707 bytes, 1 failures 1553 Jan 31 12:44:03 2026 (4128778) <176979064563.3611678.6370323034981829398@lists> delivery to sarthakkad2005@gmail.com failed with code 444, SMTP AUTH extension not supported by server. 1554 Feb 02 06:57:21 2026 (4128778) while connecting to SMTP: 1555 Feb 02 06:59:37 2026 (664714) <176979064563.3611678.6370323034981829398@lists> low level smtp error: [Errno 110] Connection timed out 1556 Feb 02 06:59:37 2026 (664714) <176979064563.3611678.6370323034981829398@lists> smtp to sugar-devel@lists.sugarlabs.org for 1 recips, completed in 130.81689381599426 seconds 1557 Feb 02 06:59:37 2026 (664714) <176979064563.3611678.6370323034981829398@lists> post to sugar-devel@lists.sugarlabs.org from sugar-devel-confirm+edc5e1df6d76fe7955475023efd08101ed2edb17@lists.sugarlabs.org, 1707 bytes, 1 failures 1558 Feb 02 06:59:37 2026 (664714) <176979064563.3611678.6370323034981829398@lists> delivery to sarthakkad2005@gmail.com failed with code 444, [Errno 110] Connection timed out 1559 Feb 02 07:14:36 2026 (664714) <176979064563.3611678.6370323034981829398@lists> low level smtp error: [Errno 110] Connection timed out 1560 Feb 02 07:14:36 2026 (664714) <176979064563.3611678.6370323034981829398@lists> smtp to sugar-devel@lists.sugarlabs.org for 1 recips, completed in 130.05159902572632 seconds 1561 Feb 02 07:14:36 2026 (664714) <176979064563.3611678.6370323034981829398@lists> post to sugar-devel@lists.sugarlabs.org from sugar-devel-confirm+edc5e1df6d76fe7955475023efd08101ed2edb17@lists.sugarlabs.org, 1707 bytes, 1 failures 1562 Feb 02 07:14:36 2026 (664714) <176979064563.3611678.6370323034981829398@lists> delivery to sarthakkad2005@gmail.com failed with code 444, [Errno 110] Connection timed out 1563 Feb 02 07:29:37 2026 (664714) <176979064563.3611678.6370323034981829398@lists> low level smtp error: [Errno 110] Connection timed out 1564 Feb 02 07:29:37 2026 (664714) <176979064563.3611678.6370323034981829398@lists> smtp to sugar-devel@lists.sugarlabs.org for 1 recips, completed in 131.08647632598877 seconds 1565 Feb 02 07:29:37 2026 (664714) <176979064563.3611678.6370323034981829398@lists> post to sugar-devel@lists.sugarlabs.org from sugar-devel-confirm+edc5e1df6d76fe7955475023efd08101ed2edb17@lists.sugarlabs.org, 1707 bytes, 1 failures 1566 Feb 02 07:29:37 2026 (664714) <176979064563.3611678.6370323034981829398@lists> delivery to sarthakkad2005@gmail.com failed with code 444, [Errno 110] Connection timed out 1567 Feb 02 07:44:36 2026 (664714) <176979064563.3611678.6370323034981829398@lists> low level smtp error: [Errno 110] Connection timed out 1568 Feb 02 07:44:36 2026 (664714) <176979064563.3611678.6370323034981829398@lists> smtp to sugar-devel@lists.sugarlabs.org for 1 recips, completed in 130.05518007278442 seconds 1569 Feb 02 07:44:36 2026 (664714) <176979064563.3611678.6370323034981829398@lists> post to sugar-devel@lists.sugarlabs.org from sugar-devel-confirm+edc5e1df6d76fe7955475023efd08101ed2edb17@lists.sugarlabs.org, 1707 bytes, 1 failures 1570 Feb 02 07:44:36 2026 (664714) <176979064563.3611678.6370323034981829398@lists> delivery to sarthakkad2005@gmail.com failed with code 444, [Errno 110] Connection timed out 1571 Feb 02 07:48:32 2026 (678685) <176979064563.3611678.6370323034981829398@lists> low level smtp error: [Errno 110] Connection timed out 1572 Feb 02 07:48:32 2026 (678685) <176979064563.3611678.6370323034981829398@lists> smtp to sugar-devel@lists.sugarlabs.org for 1 recips, completed in 130.0330526828766 seconds 1573 Feb 02 07:48:32 2026 (678685) <176979064563.3611678.6370323034981829398@lists> post to sugar-devel@lists.sugarlabs.org from sugar-devel-confirm+edc5e1df6d76fe7955475023efd08101ed2edb17@lists.sugarlabs.org, 1707 bytes, 1 failures 1574 Feb 02 07:48:32 2026 (678685) <176979064563.3611678.6370323034981829398@lists> delivery to sarthakkad2005@gmail.com failed with code 444, [Errno 110] Connection timed out 1575 Feb 02 07:59:31 2026 (683226) <176979064563.3611678.6370323034981829398@lists> smtp to sugar-devel@lists.sugarlabs.org for 1 recips, completed in 0.05027198791503906 seconds 1576 Feb 02 07:59:31 2026 (683226) <176979064563.3611678.6370323034981829398@lists> post to sugar-devel@lists.sugarlabs.org from sugar-devel-confirm+edc5e1df6d76fe7955475023efd08101ed2edb17@lists.sugarlabs.org, 1707 bytes 1577 Feb 03 03:10:07 2026 (683226) <177011700641.683263.16748966738137655513@localhost.localdomain> smtp to gsoc@lists.sugarlabs.org for 1 recips, completed in 0.04062008857727051 seconds 1578 Feb 03 03:10:07 2026 (683226) <177011700641.683263.16748966738137655513@localhost.localdomain> post to gsoc@lists.sugarlabs.org from gsoc-confirm+423bc3fbc7ece192437c9d571b798025137b3f95@lists.sugarlabs.org, 1635 bytes 1579 Feb 03 03:10:19 2026 (683226) <177011701801.683263.13618900516538057849@localhost.localdomain> smtp to bugs@lists.sugarlabs.org for 1 recips, completed in 0.025012493133544922 seconds 1580 Feb 03 03:10:19 2026 (683226) <177011701801.683263.13618900516538057849@localhost.localdomain> post to bugs@lists.sugarlabs.org from bugs-confirm+f896a698312c25195fa072104d42dd324badddbf@lists.sugarlabs.org, 1652 bytes 1581 Feb 03 23:41:25 2026 (683226) <177019088335.683263.8347259112808463258@localhost.localdomain> smtp to gsoc@lists.sugarlabs.org for 1 recips, completed in 0.037694454193115234 seconds 1582 Feb 03 23:41:25 2026 (683226) <177019088335.683263.8347259112808463258@localhost.localdomain> post to gsoc@lists.sugarlabs.org from gsoc-confirm+b6aea46ef8d420e6ca3047abe1f44230725a6c5d@lists.sugarlabs.org, 1630 bytes
I don't know why the connection timed out when it did, I'll assume it was an issue with smtp, but that's about the only time it happened.
I also commented out the smtp_user and smtp_pass details from mailman.cfg because of the error about the user not existing, just to see if I'll get a different error but I still get the same error, I've uncommented it out though.
I'm using port 25 for smtp, I wasn't sure I'll need submission because I'd done that earlier and it didn't seem to change anything, does mailman need submission?
-- 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@gmail.com
Chihurumnaya Ibiam via Mailman-users writes:
I've removed this [Dovecot?],
You mean you uninstalled it? If not, where did you remove it from?
and it does seem like dovecot still runs when mailman hands mail to lmtp,
I assume by "seem like dovecot still runs" you're referring to the log entry below. If not, what evidence are you seeing that dovecot is running?
but I don't see any authentication issues, the logs show this;
lists postfix/lmtp[1376243]: 458381A894B: to=<mailman@lists.sugarlabs.org>, orig_to=<mailman>, relay=localhost[127.0.0.1]:24, delay=0.03,
This says the postfix is sending to 127.0.0.1 over port 24. This is probably Mailman, since LMTP is the only way for Postfix to send mail to Mailman, and Mailman is trying to process mail according to your logs.
delays=0.02/0/0.01/0, dsn=5.1.1, status=bounced (host localhost[127.0.0.1] said: 550 5.1.1 <mailman@lists.sugarlabs.org> User doesn't exist:
This means that whatever is listening on port 24 doesn't know about the 'mailman' user. Mailman only knows about lists in the postfix_lmtp file (that is compiled to postfix_lmtp.db).
mailman@lists.sugarlabs.org (in reply to RCPT TO command))
The user does exist, which is the weird part.
Not really. Postfix knows how to deliver to local users in file-based mailboxes, but it's delivering via LMTP or SMTP to port 24. I suppose Dovecot does as well, but if it's been uninstalled by a package manager, the running instance will have been stopped and there won't be anything to run. Most likely the listener on 24 is Mailman, which does *not* know how to deliver to local users at all.
I'm starting mailman via systemd, and the mailman config was passed through an environment variable - MAILMAN_CONFIG_FILE -.
You should run "mailman -C /etc/mailman3/mailman.cfg conf -s mta", which will tell you the basic information about Mailman's handling of external mail both incoming and outgoing.
The installation instructions <https://docs.mailman3.org/en/latest/install/install.html> don't say anything about mailman listening on a port
That's implied by using LMTP which is a network protocol. Mailman 3 defaults to using 8024 for that port. If you're using Postfix, that port will be in the postfix_lmtp file, so it's configured automatically. I forget how other MTAs get information about the Mailman host and port.
Which installation method did you use? Your package manager, or virtualenv? If it's a package manager, who knows what it has configured.
I've removed authentication and the only error in the log is the one I shared above, although there are some errors in mailman smtp logs;
1551 Jan 31 12:44:03 2026 (4128778) <176979064563.3611678.6370323034981829398@lists> smtp to sugar-devel@lists.sugarlabs.org for 1 recips, completed in 0.009501457214355469 seconds
This seems to be the incoming message to Mailman, which Mailman accepted. The Message-ID (in <> angle brackets) is not of the recommended form. It should have the full domain (presumably lists.sugarlabs.org) to ensure global uniqueness.
1552 Jan 31 12:44:03 2026 (4128778) <176979064563.3611678.6370323034981829398@lists> post to sugar-devel@lists.sugarlabs.org from sugar-devel-confirm+edc5e1df6d76fe7955475023efd08101ed2edb17@lists.sugarlabs.org, 1707 bytes, 1 failures
I'm not sure what's going on here, but I think there's a serious configuration problem because Mailman is sending confirmation codes (probably for subscriptions) back to the list.
What is your postfix setting for recipient_delimiter? That needs to be '+' or possibly '+-'. If it's '-', that will cause this kind of mail loop, I think.
1553 Jan 31 12:44:03 2026 (4128778) <176979064563.3611678.6370323034981829398@lists> delivery to sarthakkad2005@gmail.com failed with code 444, SMTP AUTH extension not supported by server.
The above 2 say that you're trying to send to 1 user at Gmail, but some server doesn't handle the AUTH extension. You need to disable outgoing authentication, unless you're delivering only to MTAs you control.
Is there anything in the Postfix logs that indicated it tried to connect to gmail.com, and the message was rejected? I suspect that there won't be, and that the problem is that you have smtp_user and smtp_pass configured. Then Mailman will use those and the AUTH command to try to authenticate to your Postfix. That can be done, but you need to configure Postfix (not a system user and password) to accept the AUTH command. There may be a way to get Postfix to /etc/passwd to authenticate a user, but I don't know what it is.
1554 Feb 02 06:57:21 2026 (4128778) while connecting to SMTP: 1555 Feb 02 06:59:37 2026 (664714) <176979064563.3611678.6370323034981829398@lists> low level smtp error: [Errno 110] Connection timed out
I'm not sure what's going on with the above two.
The rest of the messages follow the same pattern for different lists.
I'm using port 25 for smtp, I wasn't sure I'll need submission because I'd done that earlier and it didn't seem to change anything, does mailman need submission?
No. submission doesn't make sense for Mailman in most configurations (that is, all the configurations I've ever seen).
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On Wed, Feb 4, 2026 at 4:21 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
I've removed this [Dovecot?],
You mean you uninstalled it? If not, where did you remove it from?
Not uninstalled it, commented out from postfix master.cf the line; # dovecot unix - - y - - lmtp
and it does seem like dovecot still runs when mailman hands mail to lmtp,
I assume by "seem like dovecot still runs" you're referring to the log entry below. If not, what evidence are you seeing that dovecot is running?
systemctl shows the service is still active, I didn't end the service itself, I assumed the line above I commented out would prevent the dovecot service from running under postfix.
I realize now that it won't stop the service because I have lmtp set as the mailbox transport and it's configuration seems to be handled by dovecot.
but I don't see any authentication issues, the logs show this;
lists postfix/lmtp[1376243]: 458381A894B: to=< mailman@lists.sugarlabs.org>, orig_to=<mailman>, relay=localhost[127.0.0.1]:24, delay=0.03,
This says the postfix is sending to 127.0.0.1 over port 24. This is probably Mailman, since LMTP is the only way for Postfix to send mail to Mailman, and Mailman is trying to process mail according to your logs.
Yes, that's how it's configured.
delays=0.02/0/0.01/0, dsn=5.1.1, status=bounced (host localhost[127.0.0.1] said: 550 5.1.1 <mailman@lists.sugarlabs.org> User doesn't exist:
This means that whatever is listening on port 24 doesn't know about the 'mailman' user. Mailman only knows about lists in the postfix_lmtp file (that is compiled to postfix_lmtp.db).
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.
mailman@lists.sugarlabs.org (in reply to RCPT TO command))
The user does exist, which is the weird part.
Not really. Postfix knows how to deliver to local users in file-based mailboxes, but it's delivering via LMTP or SMTP to port 24. I suppose Dovecot does as well, but if it's been uninstalled by a package manager, the running instance will have been stopped and there won't be anything to run. Most likely the listener on 24 is Mailman, which does *not* know how to deliver to local users at all.
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.
I'm starting mailman via systemd, and the mailman config was passed through an environment variable - MAILMAN_CONFIG_FILE -.
You should run "mailman -C /etc/mailman3/mailman.cfg conf -s mta", which will tell you the basic information about Mailman's handling of external mail both incoming and outgoing.
[mta] configuration: python:mailman.config.postfix [mta] delivery_retry_period: 5d [mta] incoming: mailman.mta.postfix.LMTP [mta] lmtp_host: *.*.*.* [mta] lmtp_port: 24 [mta] max_autoresponses_per_day: 10 [mta] max_delivery_threads: 0 [mta] max_recipients: 10 [mta] max_sessions_per_connection: 0 [mta] outgoing: mailman.mta.deliver.deliver [mta] remove_dkim_headers: no [mta] smtp_host: 127.0.0.1 [mta] smtp_pass: ************** [mta] smtp_port: 25 [mta] smtp_secure_mode: smtp [mta] smtp_user: mailman [mta] smtp_verify_cert: yes [mta] smtp_verify_hostname: yes [mta] verp_confirm_format: $address+$cookie [mta] verp_confirm_regexp: ^(.*<)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$ [mta] verp_confirmations: yes [mta] verp_delimiter: + [mta] verp_delivery_interval: 1 [mta] verp_format: ${bounces}+${local}=${domain} [mta] verp_personalized_deliveries: yes [mta] verp_probe_format: $bounces+$token@$domain [mta] verp_probe_regexp: ^(?P<bounces>[^+]+?)\+(?P<token>[^@]+)@.*$ [mta] verp_probes: no [mta] verp_regexp: ^(?P<bounces>[^+]+?)\+(?P<local>[^=]+)=(?P<domain>[^@]+)@.*$
This is as expected, as I set some of these myself.
The installation instructions <https://docs.mailman3.org/en/latest/install/install.html> don't say anything about mailman listening on a port
That's implied by using LMTP which is a network protocol. Mailman 3 defaults to using 8024 for that port. If you're using Postfix, that port will be in the postfix_lmtp file, so it's configured automatically. I forget how other MTAs get information about the Mailman host and port.
Which installation method did you use? Your package manager, or virtualenv? If it's a package manager, who knows what it has configured.
I used the virtualenv method.
I've removed authentication and the only error in the log is the one I shared above, although there are some errors in mailman smtp logs;
1551 Jan 31 12:44:03 2026 (4128778) <176979064563.3611678.6370323034981829398@lists> smtp to sugar-devel@lists.sugarlabs.org for 1 recips, completed in 0.009501457214355469 seconds
This seems to be the incoming message to Mailman, which Mailman accepted. The Message-ID (in <> angle brackets) is not of the recommended form. It should have the full domain (presumably lists.sugarlabs.org) to ensure global uniqueness.
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?
1552 Jan 31 12:44:03 2026 (4128778) <176979064563.3611678.6370323034981829398@lists> post to sugar-devel@lists.sugarlabs.org from
sugar-devel-confirm+edc5e1df6d76fe7955475023efd08101ed2edb17@lists.sugarlabs.org , 1707 bytes, 1 failures
I'm not sure what's going on here, but I think there's a serious configuration problem because Mailman is sending confirmation codes (probably for subscriptions) back to the list.
What is your postfix setting for recipient_delimiter? That needs to be '+' or possibly '+-'. If it's '-', that will cause this kind of mail loop, I think.
Yes, it points to a configuration problem, the recipient_delimeter for postfix is set to +
1553 Jan 31 12:44:03 2026 (4128778) <176979064563.3611678.6370323034981829398@lists> delivery to sarthakkad2005@gmail.com failed with code 444, SMTP AUTH extension not supported by server.
The above 2 say that you're trying to send to 1 user at Gmail, but some server doesn't handle the AUTH extension. You need to disable outgoing authentication, unless you're delivering only to MTAs you control.
How do I disable outgoing authentication? I don't remember enabling it.
I also just noticed this in the logs;
NOQUEUE: reject: RCPT from unknown[141.98.11.11]: 554 5.7.1 < allenmccathyesq@gmail.com>: Relay access denied; from=< marketing@lists.sugarlabs.org> to=<allenmccathyesq@gmail.com> proto=ESMTP helo=<LS57X2JsBM>
I turned submission back on, totally forgot it was used that way.
I also added permit_auth_destination to smtpd_relay_restrictions for the Relay access denied issue.
Is there anything in the Postfix logs that indicated it tried to connect to gmail.com, and the message was rejected? I suspect that there won't be, and that the problem is that you have smtp_user and smtp_pass configured. Then Mailman will use those and the AUTH command to try to authenticate to your Postfix. That can be done, but you need to configure Postfix (not a system user and password) to accept the AUTH command. There may be a way to get Postfix to /etc/passwd to authenticate a user, but I don't know what it is.
I did configure smtp_user and smtp_pass, but I commented it out after I disabled submission earlier.
I usually set postfix user authentication through saslauthd, which is configured to use /etc/shadow for user lookup.
1554 Feb 02 06:57:21 2026 (4128778) while connecting to SMTP: 1555 Feb 02 06:59:37 2026 (664714) <176979064563.3611678.6370323034981829398@lists> low level smtp error: [Errno 110] Connection timed out
I'm not sure what's going on with the above two.
The rest of the messages follow the same pattern for different lists.
I'm using port 25 for smtp, I wasn't sure I'll need submission because I'd done that earlier and it didn't seem to change anything, does mailman need submission?
No. submission doesn't make sense for Mailman in most configurations (that is, all the configurations I've ever seen).
Agreed, which is why I removed it as it wasn't needed. I was just reminded that it's needed though, the log entry above reminded me of that.
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@gmail.com
Chihurumnaya Ibiam via Mailman-users writes:
On Wed, Feb 4, 2026 at 4:21?PM Stephen J. Turnbull <steve@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 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.
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'.
Yes, that's how it's configured.
Sure, but something is wrong with the configuration, and it might not be just one thing.
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.
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.
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?
[mta] lmtp_host: *.*.*.*
That should be 127.0.0.1. Mailman should not be listening on network interfaces other than the loopback (localhost).
[mta] lmtp_port: 24
This can't work if Dovecot is configured to use the same port, as is Dovecot's default.
[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.
I used the virtualenv method.
Good. That's the preferred method, as distro packages generally lag substantially, often a year or more.
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.
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@gmail.com>: Relay access denied; from=<marketing@lists.sugarlabs.org> to=<allenmccathyesq@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.
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)
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 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 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.
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 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 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.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On Wed, Feb 4, 2026 at 9:06 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
On Wed, Feb 4, 2026 at 4:21?PM Stephen J. Turnbull <steve@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.ht...> 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@gmail.com>: Relay access denied; from=<marketing@lists.sugarlabs.org> to=<allenmccathyesq@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@gmail.com
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@localhost.localdomain> delivery to ibiam@sugarlabs.org failed with code 550, b'5.1.1 < ibiam@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@gmail.com
On Wed, Feb 4, 2026 at 10:15 PM Chihurumnaya Ibiam < ibiamchihurumnaya@gmail.com> wrote:
On Wed, Feb 4, 2026 at 9:06 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
On Wed, Feb 4, 2026 at 4:21?PM Stephen J. Turnbull <steve@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.ht...> 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@gmail.com>: Relay access denied; from=<marketing@lists.sugarlabs.org> to=<allenmccathyesq@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@gmail.com
Chihurumnaya Ibiam via Mailman-users writes:
On Wed, Feb 4, 2026 at 9:06 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
systemctl shows the service is still active, 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.
As far as I know, if systemd knows about a service, there's a control file somewhere. systemd will create a unit from an rc file in /etc/rcN.d if there is one. (I was perfectly happy with SysV init, but I guess systemd makes hyperscalars happy.) I don't know if "systemctl disable" works on those.
I configured mailbox transport because that was how I was able to get lmtp to run on port 24,
Something like that would be necessary for Dovecot, which I believe can be configured to automatically create a mailbox for any address. It is not necessary for Mailman, which tells Postfix how to deliver to Mailman lists in the postfix_lmtp table. You can find that in /opt/mailman/mm/var/data, if you followed the virtualenv installation to the letter.
It's problematic for Mailman because that means that *all* local mail will be delivered to Mailman, which will reject it if it's not list-related.
I'm not sure this is why the confirmation mails are getting rejected, but at a guess, for some classes of mail Postfix will first try the whole address, and if that fails to route, it will remove the extension (starting with "+"), and try again. Perhaps it does NOT do that for the mailbox_transport.
there wasn't any service before that and the documentation <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.ht...> for setting up a mail server mentions postfix delivering by default over port 24.
What it says is this:
Postfix will deliver via LMTP over port 24 by default, however if
you are not running Mailman as root, you’ll need to change this to
a higher port number, as shown above.Are you running Mailman as root? If so, stop it, change lmtp_port back to 8024 in mailman.cfg, and stop and start Mailman to regenerate the postfix_lmtp.db. There's no need for running as root unless you have an MTA that is hard-coded to think that 24 is the one and only lmtp port handed down from Mount Olympus. Postfix knows better.
Furthermore, you should NOT run mailman as root if there's any alternative. Mailman occasionally crashes for various reasons (I've never seen it take Python down, but then, if there were an exploit, I wouldn't), and is not securely authenticated (I mean, it's reasonably secure, but it is just a password, and once you get in to Mailman core, you're the superuser for Mailman) and if there *is* an exploit and Mailman is running as root, you've got system root, too.
Don't run Mailman as root. Please.
Disabling this means there's no lmtp to be used by postfix, except I'm missing something.
Yes, you're missing something. Postfix is always able to speak LMTP, and is very flexible about when to do so. If you followed the virtualenv installation to the letter, you have
transport_maps = hash:/opt/mailman/mm/var/data/postfix_lmtp
in main.cf (perhaps there's other maps there), and in that file you have lines that end in "lmtp:[127.0.0.1]:24", which tell Postfix "connect to IP address 127.0.0.1, port 24, and speak LMTP to that connection." If you change lmtp_port to 8024 and restart Mailman as suggested, all those lines will change to "lmtp:[127.0.0.1]:8024" and Postfix will be happy to deliver to Mailman that way without being 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.
That should get it working, except that with mailbox_transport set there's a good chance that Mailman functions that use "+" extensions will mess up as described above. Those functions are confirmations and I think VERP probes.
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 might. But "Internet Mail" is another name for Dante's Third Circle of Hell. (You must have committed a horrible felony to be sentenced to administer an Internet mail host. :-D That's just a joke, it sounds to me like your "usual setup" is quite solid and secure.) Anyway, any deviation from the setup described in virtualenv.html is a chance for everything to go wrong. "What I usually do" is just not deep enough knowledge if you're working with a new mail application with complex routing needs.
What does "lsof -i @127.0.0.1 -i '@[::1]' | grep 24" output?
python3 1592922 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) python3 1592949 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) python3 1592950 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN)
The above are Mailman (actually, a gunicorn application) listening for connections to its REST API. These are HTTP listeners used by Postorius and HyperKitty (I guess those aren't running?), not for email.
postgres 3568035 postgres 5u IPv6 160224851 0t0 TCP localhost:postgresql (LISTEN) postgres 3568035 postgres 6u IPv4 160224852 0t0 TCP localhost:postgresql (LISTEN)
These are PostgreSQL listening for database connections.
python3 1592924 mailman 22u IPv6 177685051 0t0 TCP localhost:48638->localhost:postgresql (ESTABLISHED)
This is Mailman talking to Postfix.
postgres 1592954 postgres 9u IPv6 177686124 0t0 TCP localhost:postgresql->localhost:48498 (ESTABLISHED) postgres 1592912 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787
- 21 more copies of the above, differing only in the PID. Don't know what's going on with those, not a PostgreSQL wizard. I probably should have specified TCP in the lsof command, UDP applications are either trivial or they are black magic.
It appears that *nothing* is listening on or connected to port 24. I'm not sure how that works. I'm guessing that when mail was getting to Mailman, Mailman had opened port 24 and Dovecot was cut out of the loop (maybe check logs for Dovecot complaining it couldn't bind to port 24?)
[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.
OK
[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.
OK
[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.
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.
I don't understand it then. Perhaps the mail composition client is providing the Message-ID.
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.
OK.
No, I mean smtps.
Same problem except the port that Mailman is *not* using is 465.
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 gotta run now, I'll come back to it later. You're probably asleep, anyway. :-)
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
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@localhost.localdomain> delivery to ibiam@sugarlabs.org failed with code 550, b'5.1.1 <ibiam@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@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
On Thu, Feb 5, 2026 at 2:21 PM Stephen J. Turnbull <steve@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@localhost.localdomain> delivery to ibiam@sugarlabs.org failed with code 550, b'5.1.1 <ibiam@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@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@gmail.comT
On Thu, Feb 5, 2026 at 4:35 AM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
On Wed, Feb 4, 2026 at 9:06 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
systemctl shows the service is still active, 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.
As far as I know, if systemd knows about a service, there's a control file somewhere. systemd will create a unit from an rc file in /etc/rcN.d if there is one. (I was perfectly happy with SysV init, but I guess systemd makes hyperscalars happy.) I don't know if "systemctl disable" works on those.
I don't plan on shutting down the host anytime soon, so hopefully, I remember to the next time it restarts.
I started out with Fedora the year before it adopted systemd, so I never really knew about SysV init until today.
I configured mailbox transport because that was how I was able to get lmtp to run on port 24,
Something like that would be necessary for Dovecot, which I believe can be configured to automatically create a mailbox for any address. It is not necessary for Mailman, which tells Postfix how to deliver to Mailman lists in the postfix_lmtp table. You can find that in /opt/mailman/mm/var/data, if you followed the virtualenv installation to the letter.
Yes, postfix_lmtp table is set in transport_maps, virtual_mailbox_maps, relay_domains, local_recipient_maps.
It's problematic for Mailman because that means that *all* local mail will be delivered to Mailman, which will reject it if it's not list-related.
I'm totally fine with this because that's why we setup the host, although one thing I noticed in the logs was that other servers trying to connect to the host was rejected, they're trying to send logs to a mailing list, which should work just fine but then it seems they need to connect to this host.
connect to weblate.sugarlabs.org[192.184.220.214]:25: Connection refused 165968 Feb 5 04:48:46 lists postfix/smtp[1941010]: connect to weblate.sugarlabs.org[2001:5a8:601:f::214]:25: Connection refused 165969 Feb 5 04:48:46 lists postfix/smtp[1941010]: B785D1A897F: to=< root@weblate.sugarlabs.org>, relay=none, delay=17323, delays=17323/0.02/0.33/0, dsn=4.4.1, status=deferred (connect to weblate.sugarlabs.org[2001:5a8:601:f::214]:25: Connection refused)
I tried to fix this with check_client_access hash:/etc/postfix/client_access, which contains a wild card for the main domain and subdomains, which seems to have no effect.
I'm not sure this is why the confirmation mails are getting rejected, but at a guess, for some classes of mail Postfix will first try the whole address, and if that fails to route, it will remove the extension (starting with "+"), and try again. Perhaps it does NOT do that for the mailbox_transport.
there wasn't any service before that and the documentation < https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.ht...
for setting up a mail server mentions postfix delivering by default over port 24.
What it says is this:
Postfix will deliver via LMTP over port 24 by default, however if you are not running Mailman as root, you’ll need to change this to a higher port number, as shown above.
Are you running Mailman as root? If so, stop it, change lmtp_port back to 8024 in mailman.cfg, and stop and start Mailman to regenerate the postfix_lmtp.db. There's no need for running as root unless you have an MTA that is hard-coded to think that 24 is the one and only lmtp port handed down from Mount Olympus. Postfix knows better.
No, I'm not running mailman as root, it's run as mailman. Seeing as that's the case, would I still need to change lmtp_port?
Furthermore, you should NOT run mailman as root if there's any alternative. Mailman occasionally crashes for various reasons (I've never seen it take Python down, but then, if there were an exploit, I wouldn't), and is not securely authenticated (I mean, it's reasonably secure, but it is just a password, and once you get in to Mailman core, you're the superuser for Mailman) and if there *is* an exploit and Mailman is running as root, you've got system root, too.
Don't run Mailman as root. Please.
I haven't, I was never going to.
Disabling this means there's no lmtp to be used by postfix, except I'm missing something.
Yes, you're missing something. Postfix is always able to speak LMTP, and is very flexible about when to do so. If you followed the virtualenv installation to the letter, you have
transport_maps = hash:/opt/mailman/mm/var/data/postfix_lmtp
in main.cf (perhaps there's other maps there), and in that file you have lines that end in "lmtp:[127.0.0.1]:24", which tell Postfix "connect to IP address 127.0.0.1, port 24, and speak LMTP to that connection." If you change lmtp_port to 8024 and restart Mailman as suggested, all those lines will change to "lmtp:[127.0.0.1]:8024" and Postfix will be happy to deliver to Mailman that way without being root.
After your comment about Postfix being an LMTP server, I understood this better.
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.
That should get it working, except that with mailbox_transport set there's a good chance that Mailman functions that use "+" extensions will mess up as described above. Those functions are confirmations and I think VERP probes.
It did get it working, I can see mail being sent in the logs. I sent a ping to the systems list just to get delivery confirmation and I'm yet to get a response.
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 might. But "Internet Mail" is another name for Dante's Third Circle of Hell. (You must have committed a horrible felony to be sentenced to administer an Internet mail host. :-D That's just a joke, it sounds to me like your "usual setup" is quite solid and secure.) Anyway, any deviation from the setup described in virtualenv.html is a chance for everything to go wrong. "What I usually do" is just not deep enough knowledge if you're working with a new mail application with complex routing needs.
😅😅 Funniest thing I've read today.
I agree with your last sentence, needed to be reminded of that.
What does "lsof -i @127.0.0.1 -i '@[::1]' | grep 24" output?
python3 1592922 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) python3 1592949 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) python3 1592950 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN)
The above are Mailman (actually, a gunicorn application) listening for connections to its REST API. These are HTTP listeners used by Postorius and HyperKitty (I guess those aren't running?), not for email.
Postorius and HyperKitty are running.
postgres 3568035 postgres 5u IPv6 160224851 0t0 TCP localhost:postgresql (LISTEN) postgres 3568035 postgres 6u IPv4 160224852 0t0 TCP localhost:postgresql (LISTEN)
These are PostgreSQL listening for database connections.
python3 1592924 mailman 22u IPv6 177685051 0t0 TCP localhost:48638->localhost:postgresql (ESTABLISHED)
This is Mailman talking to Postfix.
postgres 1592954 postgres 9u IPv6 177686124 0t0 TCP localhost:postgresql->localhost:48498 (ESTABLISHED) postgres 1592912 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787
- 21 more copies of the above, differing only in the PID. Don't know what's going on with those, not a PostgreSQL wizard. I probably should have specified TCP in the lsof command, UDP applications are either trivial or they are black magic.
It appears that *nothing* is listening on or connected to port 24. I'm not sure how that works. I'm guessing that when mail was getting to Mailman, Mailman had opened port 24 and Dovecot was cut out of the loop (maybe check logs for Dovecot complaining it couldn't bind to port 24?)
The logs don't show Dovecot complaining about binding to port 24, the only thing.
This is one that's consistent with Dovecot in the logs;
157322 Feb 4 12:27:02 lists postfix/cleanup[1593312]: AC7381A8978: message-id=<20260204202702.AC7381A8978@lists.sugarlabs.org> 157323 Feb 4 12:27:02 lists postfix/bounce[1587396]: A26F71A8977: sender non-delivery notification: AC7381A8978 157324 Feb 4 12:27:02 lists postfix/qmgr[1593314]: AC7381A8978: from=<>, size=3129, nrcpt=1 (queue active) 157325 Feb 4 12:27:02 lists postfix/local[1593315]: AC7381A8978: passing < mailman@lists.sugarlabs.org> to transport=lmtp 157326 Feb 4 12:27:02 lists dovecot: lmtp(1600482): Connect from 127.0.0.1 157327 Feb 4 12:27:02 lists postfix/qmgr[1593314]: A26F71A8977: removed 157328 Feb 4 12:27:02 lists postfix/lmtp[1593316]: AC7381A8978: to=< mailman@lists.sugarlabs.org>, relay=localhost[127.0.0.1]:24, delay=0.04, delays=0.02/0/0/0.01, dsn=5.1.1, status=bounced (host localhost[127.0.0.1] said: 550 5.1.1 <mailman@lists.sugarlabs.org> User doesn't exist: mailman@lists.sugarlabs.org (in reply to RCPT TO command)) 157329 Feb 4 12:27:02 lists dovecot: lmtp(1600482): Disconnect from 127.0.0.1: Logged out (state=READY)
Which we've established that mailman doesn't know how to deliver to local users.
[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.
OK
[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.
OK
[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.
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.
I don't understand it then. Perhaps the mail composition client is providing the Message-ID.
Could be, doesn't seem to be an issue at the moment so I won't worry about it.
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.
OK.
No, I mean smtps.
Same problem except the port that Mailman is *not* using is 465.
Yes, earlier when I set it up I had set the port for Mailman to use as 465.
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 gotta run now, I'll come back to it later. You're probably asleep, anyway. :-)
-- 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@gmail.com
On 2/5/26 06:30, Chihurumnaya Ibiam via Mailman-users wrote:
Yes, postfix_lmtp table is set in transport_maps, virtual_mailbox_maps, relay_domains, local_recipient_maps.
I'm coming in late here so I may have missed things, but ...
If you actually have virtual_mailbox_domains and virtual_mailbox_maps, see https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.ht...
No, I'm not running mailman as root, it's run as mailman. Seeing as that's the case, would I still need to change lmtp_port?
The lmtp_port setting determines what port mailman listens on and what port is in the lmtp: entries in postfix_lmtp. Id should absolutely NOT be the same port dovecot listens on and the default 8024 is a good value.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
On 2/5/26 06:30, Chihurumnaya Ibiam via Mailman-users wrote:
Yes, postfix_lmtp table is set in transport_maps, virtual_mailbox_maps, relay_domains, local_recipient_maps. I'm coming in late here so I may have missed things, but ... If you actually have virtual_mailbox_domains and virtual_mailbox_maps, see https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.ht...
I don't have those, postfix isn't configured to use a virtual interface.
No, I'm not running mailman as root, it's run as mailman. Seeing as that's the case, would I still need to change lmtp_port? The lmtp_port setting determines what port mailman listens on and what port is in the lmtp: entries in postfix_lmtp. Id should absolutely NOT be the same port dovecot listens on and the default 8024 is a good value.
Yes, I commented the setting out and it now defaults to 8024.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2/6/26 08:14, Ibiam Chihurumnaya via Mailman-users wrote:
Mark Sapiro wrote:
The lmtp_port setting determines what port mailman listens on and what port is in the lmtp: entries in postfix_lmtp. Id should absolutely NOT be the same port dovecot listens on and the default 8024 is a good value.
Yes, I commented the setting out and it now defaults to 8024.
I'm not sure what all you did, but you may need to run
mailman aliases
to regenerate the var/data/postfix* files, specifically postfix_lmtp.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Chihurumnaya Ibiam via Mailman-users writes:
About disabling dovecot:
I don't plan on shutting down the host anytime soon, so hopefully, I remember to the next time it restarts.
systemctl stop dovecot systemctl disable dovecot systemctl daemon-reload
should do the trick without rebooting the host.
Yes, postfix_lmtp table is set in transport_maps, virtual_mailbox_maps, relay_domains, local_recipient_maps.
Do you have lists.sugarlabs.org in $virtual_mailbox_domains? As Mark points out, virtual mailboxes make life more complicated. Also, I don't think postfix_lmtp should be in $relay_domains (that table contains addresses which won't match domains being looked up). If anything it should be postfix_domains.
It's problematic for Mailman because that means that *all* local mail will be delivered to Mailman, which will reject it if it's not list-related.
I'm totally fine with this because that's why we setup the host,
I'm sorry, that was unclear. By "list-related", I meant that "the key Postfix is trying to match is an exact match for a key in the postfix_lmtp table". Because these are hash tables, it is Postfix's responsibility to strip "+extension" from the recipient address before presenting the stripped address to the table for matching -- the table can't do it.
Specifically, this applies to the confirmation and VERP cookies that may be attached to addresses for various reasons.
a mailing list, which should work just fine but then it seems they need to connect to this host.
165968 Feb 5 04:48:46 lists postfix/smtp[1941010]: connect to weblate.sugarlabs.org[2001:5a8:601:f::214]:25: Connection refused 165969 Feb 5 04:48:46 lists postfix/smtp[1941010]: B785D1A897F: to= <root@weblate.sugarlabs.org>, relay=none, delay=17323, delays=17323/0.02/0.33/0, dsn=4.4.1, status=deferred (connect to weblate.sugarlabs.org[2001:5a8:601:f::214]:25: Connection refused)
This is a problem at weblate.sugarlabs.org. Is it supposed to be receiving mail? I don't think that this is an authentication problem (SASL authentication takes place after connection), although if "weblate" expects authenticated TLS that might be the problem. So "lists" needs to be whitelisted (eg in $mynetworks) at weblate (I suppose Postfix is also the MTA at "weblate"?) If you have only the toplevel domain sugarlabs.org whitelisted, you may need to set another parameter to automatically include subdomains such as lists.sugarlabs.org.
No, I'm not running mailman as root, it's run as mailman. Seeing as that's the case, would I still need to change lmtp_port?
Yes, as far as I know. That's because by convention ports < 1024 can only bound to programs running as root (enforced by the kernel). I don't understand how Mailman is receiving mail configured to listen on port 24. This may have something to do with dovecot running.
However I really don't understand the lsof output, because you present logs that indicate that Mailman is processing mail for lists, but nothing was listening or connected on port 24. You also say Postorius and HyperKitty are running, but nothing showed up on port 8000, which is where they would be listening. Maybe I got the lsof options wrong, but it did find Postgres and Mailman's REST API.
It did get it working, I can see mail being sent in the logs. I sent a ping to the systems list just to get delivery confirmation and I'm yet to get a response.
I don't have an idea what's going on yet. The mail you see being sent in the logs, is that to a gmail address? Or is it a sugarlabs.org address? (Both of these seem to be problematic at the moment.)
What does "lsof -i @127.0.0.1 -i '@[::1]' | grep 24" output?
python3 1592922 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) python3 1592949 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) python3 1592950 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN)
The above are Mailman (actually, a gunicorn application) listening for connections to its REST API. These are HTTP listeners used by Postorius and HyperKitty (I guess those aren't running?), not for email.
Postorius and HyperKitty are running.
But they should show up as several Python applications running as mailman, listening or connected on port 8000. But they're not here. Try "lsof -i :8000 -i :24".
This is one that's consistent with Dovecot in the logs;
This is Postfix sending a non-delivery notification about A26F71A8977:
157323 Feb 4 12:27:02 lists postfix/bounce[1587396]: A26F71A8977: sender non-delivery notification: AC7381A8978
The <> tells us that this is the nondelivery notification referred to as AC7381A8978 so there's no return address to send to:
157324 Feb 4 12:27:02 lists postfix/qmgr[1593314]: AC7381A8978: from=<>, size=3129, nrcpt=1 (queue active)
postfix/local looks at mailbox_transport and sends it to lmtp, where dovecot is listening;
157325 Feb 4 12:27:02 lists postfix/local[1593315]: AC7381A8978: passing <mailman@lists.sugarlabs.org> to transport=lmtp 157326 Feb 4 12:27:02 lists dovecot: lmtp(1600482): Connect from 127.0.0.1
Postfix is done with A26F71A8977, and pops it off the queue:
157327 Feb 4 12:27:02 lists postfix/qmgr[1593314]: A26F71A8977: removed
dovecot denies knowing about a local user named "mailman", rejecting it:
157328 Feb 4 12:27:02 lists postfix/lmtp[1593316]: AC7381A8978: to=<mailman@lists.sugarlabs.org>, relay=localhost[127.0.0.1]:24, delay=0.04, delays=0.02/0/0/0.01, dsn=5.1.1, status=bounced (host localhost[127.0.0.1] said: 550 5.1.1 <mailman@lists.sugarlabs.org> User doesn't exist: mailman@lists.sugarlabs.org (in reply to RCPT TO command))
dovecot says "I'm done here":
157329 Feb 4 12:27:02 lists dovecot: lmtp(1600482): Disconnect from 127.0.0.1: Logged out (state=READY)
Which we've established that mailman doesn't know how to deliver to local users.
So that's a bounce from dovecot. I don't know enough about dovecot or your configuration of dovecot to guess what happened.
Could be, doesn't seem to be an issue at the moment so I won't worry about it.
The Message-ID is syntactically well-formed. I'm worried about side effects from the hostname not being the FQDN in mail protocols. As long as all the configurations for Postfix use the FQDN (Postfix is smart enough to abbreviate when that's useful), there shouldn't be any problems like that.
Yes, earlier when I set it up I had set the port for Mailman to use as 465.
OK.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On Fri, Feb 6, 2026 at 7:57 AM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
About disabling dovecot:
I don't plan on shutting down the host anytime soon, so hopefully, I remember to the next time it restarts.
systemctl stop dovecot systemctl disable dovecot systemctl daemon-reload
should do the trick without rebooting the host.
That did, showed it was removed from /etc/systemd/system/multi-user.target.wants/.
Yes, postfix_lmtp table is set in transport_maps, virtual_mailbox_maps, relay_domains, local_recipient_maps.
Do you have lists.sugarlabs.org in $virtual_mailbox_domains? As Mark points out, virtual mailboxes make life more complicated. Also, I don't think postfix_lmtp should be in $relay_domains (that table contains addresses which won't match domains being looked up). If anything it should be postfix_domains.
No, I don't have virtual_mailbox_domains set, I didn't need to.
Yes, postfix_lmtp isn't in relay_domains, that was my fault, it's postfix_domains.
It's problematic for Mailman because that means that *all* local mail will be delivered to Mailman, which will reject it if it's not list-related.
I'm totally fine with this because that's why we setup the host,
I'm sorry, that was unclear. By "list-related", I meant that "the key Postfix is trying to match is an exact match for a key in the postfix_lmtp table". Because these are hash tables, it is Postfix's responsibility to strip "+extension" from the recipient address before presenting the stripped address to the table for matching -- the table can't do it.
Specifically, this applies to the confirmation and VERP cookies that may be attached to addresses for various reasons.
Now I understand why it's a problem.
Going by your earlier assumption that perhaps the same thing doesn't happen for mailbox_transport, how would I use that as a fallback in such cases?
a mailing list, which should work just fine but then it seems they need to connect to this host.
165968 Feb 5 04:48:46 lists postfix/smtp[1941010]: connect to weblate.sugarlabs.org[2001:5a8:601:f::214]:25: Connection refused 165969 Feb 5 04:48:46 lists postfix/smtp[1941010]: B785D1A897F: to= <root@weblate.sugarlabs.org>, relay=none, delay=17323, delays=17323/0.02/0.33/0, dsn=4.4.1, status=deferred (connect to weblate.sugarlabs.org[2001:5a8:601:f::214]:25: Connection refused)
This is a problem at weblate.sugarlabs.org. Is it supposed to be receiving mail? I don't think that this is an authentication problem (SASL authentication takes place after connection), although if "weblate" expects authenticated TLS that might be the problem. So "lists" needs to be whitelisted (eg in $mynetworks) at weblate (I suppose Postfix is also the MTA at "weblate"?) If you have only the toplevel domain sugarlabs.org whitelisted, you may need to set another parameter to automatically include subdomains such as lists.sugarlabs.org.
No, weblate isn't supposed to receive email. It runs a service that sends emails just like MM3. Yes, postfix is also the MTA at weblate.
I can include subdomains, but I don't see a reason for doing so at the moment.
One thing I had done to remediate the error - which didn't do anything from the logs - is add check_client_access hash:/etc/postfix/client_access in smtpd_client_restrictions.
No, I'm not running mailman as root, it's run as mailman. Seeing as that's the case, would I still need to change lmtp_port?
Yes, as far as I know. That's because by convention ports < 1024 can only bound to programs running as root (enforced by the kernel). I don't understand how Mailman is receiving mail configured to listen on port 24. This may have something to do with dovecot running.
However I really don't understand the lsof output, because you present logs that indicate that Mailman is processing mail for lists, but nothing was listening or connected on port 24. You also say Postorius and HyperKitty are running, but nothing showed up on port 8000, which is where they would be listening. Maybe I got the lsof options wrong, but it did find Postgres and Mailman's REST API.
Me configuring lmtp_port to 24 earlier did interfere with Mailman because I had dovecot running on the same port at the time, after disabling dovecot and commenting out lmtp_port, I noticed Mailman listening on 8024, postfix_lmtp also showed this.
I don't know why Postorious and Hyperkitty didn't show up at the time, but I just ran lsof and this is the output; $ lsof -i TCP@127.0.0.1 -i 'TCP@[::1]' | grep 24 python3 1983955 mailman 26u IPv4 181237054 0t0 TCP localhost:8024 (LISTEN) uwsgi 1985531 mailman 9u IPv4 181247623 0t0 TCP localhost:8000 (LISTEN) uwsgi 1985547 mailman 9u IPv4 181247623 0t0 TCP localhost:8000 (LISTEN) uwsgi 1985548 mailman 9u IPv4 181247623 0t0 TCP localhost:8000 (LISTEN) mailman-w 1985554 mailman 44u IPv6 185803776 0t0 TCP localhost:60244->localhost:postgresql (ESTABLISHED) postgres 2458591 postgres 9u IPv6 185580185 0t0 TCP localhost:postgresql->localhost:43102 (ESTABLISHED) postgres 2458595 postgres 9u IPv6 185581026 0t0 TCP localhost:postgresql->localhost:43140 (ESTABLISHED) postgres 2458607 postgres 9u IPv6 185579124 0t0 TCP localhost:postgresql->localhost:43234 (ESTABLISHED) postgres 2482767 postgres 9u IPv6 185805780 0t0 TCP localhost:postgresql->localhost:60244 (ESTABLISHED) postgres 2482831 postgres 9u IPv6 185807057 0t0 TCP localhost:postgresql->localhost:56188 (ESTABLISHED) postgres 3568035 postgres 5u IPv6 160224851 0t0 TCP localhost:postgresql (LISTEN) postgres 3568035 postgres 6u IPv4 160224852 0t0 TCP localhost:postgresql (LISTEN)
Which shows the expected ports being listened on, I'll assume the issue with Postorious was probably because the mailmanweb service stopped at some point as I tried to restart it and that was basically running uwsgi, it didn't run and when I looked further I noticed uwsgi was running so there was no need to do this, as that's what it was trying to do.
It did get it working, I can see mail being sent in the logs. I sent a ping to the systems list just to get delivery confirmation and I'm yet to get a response.
I don't have an idea what's going on yet. The mail you see being sent in the logs, is that to a gmail address? Or is it a sugarlabs.org address? (Both of these seem to be problematic at the moment.)
It was to a sugarlabs.org address, I've been able to receive mail owner messages to my inbox, I configured a gmail address as the admin for Mailman suite, which indicates that mail delivery works as expected.
What does "lsof -i @127.0.0.1 -i '@[::1]' | grep 24" output?
python3 1592922 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) python3 1592949 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) python3 1592950 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN)
The above are Mailman (actually, a gunicorn application) listening for connections to its REST API. These are HTTP listeners used by Postorius and HyperKitty (I guess those aren't running?), not for email.
Postorius and HyperKitty are running.
But they should show up as several Python applications running as mailman, listening or connected on port 8000. But they're not here. Try "lsof -i :8000 -i :24".
I agree, I've explained a probable cause above. They now show up in the lsof output.
This is one that's consistent with Dovecot in the logs;
This is Postfix sending a non-delivery notification about A26F71A8977:
157323 Feb 4 12:27:02 lists postfix/bounce[1587396]: A26F71A8977: sender non-delivery notification: AC7381A8978
The <> tells us that this is the nondelivery notification referred to as AC7381A8978 so there's no return address to send to:
157324 Feb 4 12:27:02 lists postfix/qmgr[1593314]: AC7381A8978: from=<>, size=3129, nrcpt=1 (queue active)
postfix/local looks at mailbox_transport and sends it to lmtp, where dovecot is listening;
mailbox_transport currently doesn't have a value.
157325 Feb 4 12:27:02 lists postfix/local[1593315]: AC7381A8978: passing <mailman@lists.sugarlabs.org> to transport=lmtp 157326 Feb 4 12:27:02 lists dovecot: lmtp(1600482): Connect from 127.0.0.1
Postfix is done with A26F71A8977, and pops it off the queue:
157327 Feb 4 12:27:02 lists postfix/qmgr[1593314]: A26F71A8977: removed
dovecot denies knowing about a local user named "mailman", rejecting it:
Yes, this probably because I haven't properly configured user lookup on dovecot.
157328 Feb 4 12:27:02 lists postfix/lmtp[1593316]: AC7381A8978: to=<mailman@lists.sugarlabs.org>, relay=localhost[127.0.0.1]:24, delay=0.04, delays=0.02/0/0/0.01, dsn=5.1.1, status=bounced (host localhost[127.0.0.1] said: 550 5.1.1 <mailman@lists.sugarlabs.org> User doesn't exist: mailman@lists.sugarlabs.org (in reply to RCPT TO command))
dovecot says "I'm done here":
157329 Feb 4 12:27:02 lists dovecot: lmtp(1600482): Disconnect from 127.0.0.1: Logged out (state=READY)
Which we've established that mailman doesn't know how to deliver to local users.
So that's a bounce from dovecot. I don't know enough about dovecot or your configuration of dovecot to guess what happened.
At the moment, I've disabled the service and have no configurations for it. I commented out my earlier configs before disabling it.
Could be, doesn't seem to be an issue at the moment so I won't worry about it.
The Message-ID is syntactically well-formed. I'm worried about side effects from the hostname not being the FQDN in mail protocols. As long as all the configurations for Postfix use the FQDN (Postfix is smart enough to abbreviate when that's useful), there shouldn't be any problems like that.
All the configurations that are supposed to contain the FQDN does; mydestination, mydomain, myhostname.
Am I missing any?
Yes, earlier when I set it up I had set the port for Mailman to use as
OK.
-- 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@gmail.com
Chihurumnaya Ibiam via Mailman-users writes:
On Fri, Feb 6, 2026 at 7:57?AM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Going by your earlier assumption that perhaps the same thing doesn't happen for mailbox_transport, how would I use that as a fallback in such cases? [...] mailbox_transport currently doesn't have a value.
Just use the normal configuration for local recipients:
local_recipient_maps = proxy:unix:passwd.byname $alias_maps hash:/path/to/postfix_lmtp
# default, I put aliases in /etc/postfix alias_maps = hash:/etc/aliases # you may want to set virtual_alias_maps =
No, weblate isn't supposed to receive email. It runs a service that sends emails just like MM3. Yes, postfix is also the MTA at weblate.
OK, then what "lists" is trying to send to "weblate" is probably a DSN (Delivery Status Notice). I would put any addresses that are authorized to send to mailing lists in a table in virtual_alias_maps and send them to a local mailbox. The local mailbox can be either a user's mailbox (such as root or mailman) or it could be aliased to a file.
I can include subdomains, but I don't see a reason for doing so at the moment.
OK
One thing I had done to remediate the error - which didn't do anything from the logs - is add check_client_access hash:/etc/postfix/client_access in smtpd_client_restrictions.
That is what allows remote MTAs to talk to your local Postfix. The message in the log was *outgoing*.
I don't know why Postorious and Hyperkitty didn't show up at the time, but I just ran lsof and this is the output; $ lsof -i TCP@127.0.0.1 -i 'TCP@[::1]' | grep 24 [...] Which shows the expected ports being listened on, I'll assume the issue with Postorious was probably because the mailmanweb service stopped at some point
OK, the listeners are there as expected and I think you're right, you just ran lsof the last time when the web UIs were stopped.
I don't have an idea what's going on yet. The mail you see being sent in the logs, is that to a gmail address? Or is it a sugarlabs.org address? (Both of these seem to be problematic at the moment.)
It was to a sugarlabs.org address, I've been able to receive mail owner messages to my inbox, I configured a gmail address as the admin for Mailman suite, which indicates that mail delivery works as expected.
Hm. That doesn't help me figure out what's happening. We'll see if the changes so far help.
Yes, this probably because I haven't properly configured user lookup on dovecot. [...] At the moment, I've disabled the service and have no configurations for it. I commented out my earlier configs before disabling it.
Just getting dovecot out of the loop should help a lot. Deleting the mailman_transport setting and setting Mailman's lmtp_port to 8024 should clear up most list-traffic problems.
All the configurations that are supposed to contain the FQDN does; mydestination, mydomain, myhostname.
Am I missing any?
I don't think so. I think I mentioned earlier that the shortname might be a mail client setting Message-ID, not Postfix.
Regards, Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On Sat, Feb 7, 2026 at 7:28 AM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
On Fri, Feb 6, 2026 at 7:57?AM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Going by your earlier assumption that perhaps the same thing doesn't happen for mailbox_transport, how would I use that as a fallback in such cases? [...] mailbox_transport currently doesn't have a value.
Just use the normal configuration for local recipients:
local_recipient_maps = proxy:unix:passwd.byname $alias_maps hash:/path/to/postfix_lmtp
# default, I put aliases in /etc/postfix alias_maps = hash:/etc/aliases # you may want to set virtual_alias_maps =
I'm not sure this would solve the problem because there are no users on the host, just me and root. It'll most likely keep bouncing those confirmation emails, I need to test this again and see if I still get the same error as I've been able to receive bounce messages.
No, weblate isn't supposed to receive email. It runs a service that sends emails just like MM3. Yes, postfix is also the MTA at weblate.
OK, then what "lists" is trying to send to "weblate" is probably a DSN (Delivery Status Notice). I would put any addresses that are authorized to send to mailing lists in a table in virtual_alias_maps and send them to a local mailbox. The local mailbox can be either a user's mailbox (such as root or mailman) or it could be aliased to a file.
Okay.
I can include subdomains, but I don't see a reason for doing so at
the moment.
OK
One thing I had done to remediate the error - which didn't do anything from the logs - is add check_client_access hash:/etc/postfix/client_access in smtpd_client_restrictions.
That is what allows remote MTAs to talk to your local Postfix. The message in the log was *outgoing*.
Yes, I wonder why this host is trying to connect to those machines. I know that those machines send their logs to a list, that's about it.
I don't know why Postorious and Hyperkitty didn't show up at the time, but I just ran lsof and this is the output; $ lsof -i TCP@127.0.0.1 -i 'TCP@[::1]' | grep 24 [...] Which shows the expected ports being listened on, I'll assume the issue with Postorious was probably because the mailmanweb service stopped at some point
OK, the listeners are there as expected and I think you're right, you just ran lsof the last time when the web UIs were stopped.
I don't have an idea what's going on yet. The mail you see being sent in the logs, is that to a gmail address? Or is it a sugarlabs.org address? (Both of these seem to be problematic at the moment.)
It was to a sugarlabs.org address, I've been able to receive mail owner messages to my inbox, I configured a gmail address as the admin for Mailman suite, which indicates that mail delivery works as expected.
Hm. That doesn't help me figure out what's happening. We'll see if the changes so far help.
Yes, this probably because I haven't properly configured user lookup on dovecot. [...] At the moment, I've disabled the service and have no configurations for it. I commented out my earlier configs before disabling it.
Just getting dovecot out of the loop should help a lot. Deleting the mailman_transport setting and setting Mailman's lmtp_port to 8024 should clear up most list-traffic problems.
Yes, that did help.
I need to test email confirmation again and see what's going on in the logs, will do that later today.
All the configurations that are supposed to contain the FQDN does; mydestination, mydomain, myhostname.
Am I missing any?
I don't think so. I think I mentioned earlier that the shortname might be a mail client setting Message-ID, not Postfix.
Alright.
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@gmail.com
Chihurumnaya Ibiam via Mailman-users writes:
On Sat, Feb 7, 2026 at 7:28?AM Stephen J. Turnbull <steve@turnbull.jp> wrote:
# default, I put aliases in /etc/postfix alias_maps = hash:/etc/aliases # you may want to set virtual_alias_maps =
I'm not sure this would solve the problem because there are no users on the host, just me and root.
That's *exactly* the point of aliases and virtual aliases, when you don't have (or perhaps don't want) a local user to receive the mail at the apparent domain.
So for example it definitely helps you to get a handle on the mail to "weblate" problem. You use a virtual alias to direct that mail to either a user on "list" such as root, or to a file, or even (when you are confident in Mailman) to a mailing list. Then you can see what the mail is.
And you should definitely have such a alias, since there's no recipient at weblate. Or perhaps you would use a transport map to catch all mail to weblate.
Yes, I wonder why this host is trying to connect to those machines. I know that those machines send their logs to a list, that's about it.
In particular with the mail to "weblate", it's almost certainly some DSN about mail that "weblate" is sending to Mailman. If you catch the recipient address at "weblate" with a virtual alias, you can send that to root or to a file (possibly via a local alias, I don't think virtual aliases can go to files or pipes).
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On Mon, Feb 9, 2026 at 2:09 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
On Sat, Feb 7, 2026 at 7:28?AM Stephen J. Turnbull <steve@turnbull.jp> wrote:
# default, I put aliases in /etc/postfix alias_maps = hash:/etc/aliases # you may want to set virtual_alias_maps =
I'm not sure this would solve the problem because there are no users on the host, just me and root.
That's *exactly* the point of aliases and virtual aliases, when you don't have (or perhaps don't want) a local user to receive the mail at the apparent domain.
So for example it definitely helps you to get a handle on the mail to "weblate" problem. You use a virtual alias to direct that mail to either a user on "list" such as root, or to a file, or even (when you are confident in Mailman) to a mailing list. Then you can see what the mail is.
And you should definitely have such a alias, since there's no recipient at weblate. Or perhaps you would use a transport map to catch all mail to weblate.
I've set it, and I set an empty file but confirmation emails still aren't sent. Password reset emails also aren't being delivered, can't see entries for these in the logs so I'll check later.
Considering virutal_alias_maps enable delivery to addresses which aren't users, while this seems like a good security practice, I don't see how it should work to deliver mailman emails to user accounts.
Yes, I wonder why this host is trying to connect to those machines. I know that those machines send their logs to a list, that's about it.
In particular with the mail to "weblate", it's almost certainly some DSN about mail that "weblate" is sending to Mailman. If you catch the recipient address at "weblate" with a virtual alias, you can send that to root or to a file (possibly via a local alias, I don't think virtual aliases can go to files or pipes).
I'll not worry about this because weblate only sends emails to user accounts created there, and it seems to work just fine at the moment.
-- 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@gmail.com
Chihurumnaya Ibiam via Mailman-users writes:
Considering virutal_alias_maps enable delivery to addresses which aren't users, while this seems like a good security practice, I don't see how it should work to deliver mailman emails to user accounts.
It's not related to delivering posts to subscribers. However, it can be useful for things like trapping undeliverable mail to noreply sources like weblate
I'll not worry about this because weblate only sends emails to user accounts created there, and it seems to work just fine at the moment.
You said that weblate was sending mail to Mailman, and there are conditions under which Mailman would send back. For example, if weblate's mail is being held for moderation, or rejected (vs. discarded, where the mail is sent to /dev/null without notifying the sender).
Regards, Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Stephen J. Turnbull wrote:
Considering virutal_alias_maps enable delivery to addresses which aren't users, while this seems like a good security practice, I don't see how it should work to deliver mailman emails to user accounts. It's not related to delivering posts to subscribers. However, it can be useful for things like trapping undeliverable mail to noreply
Chihurumnaya Ibiam via Mailman-users writes: sources like weblate
Okay.
I'll not worry about this because weblate only sends emails to user accounts created there, and it seems to work just fine at the moment. You said that weblate was sending mail to Mailman, and there are conditions under which Mailman would send back. For example, if weblate's mail is being held for moderation, or rejected (vs. discarded, where the mail is sent to /dev/null without notifying the sender).
This makes sense.
I'll see if I can get more logs so I can debug this particular issue.
Regards, Steve
GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
It would be great if mailman can ban domains and not just users, just noticed a flurry of spam from a particular domain.
On 2/9/26 12:17, Ibiam Chihurumnaya via Mailman-users wrote:
It would be great if mailman can ban domains and not just users, just noticed a flurry of spam from a particular domain.
It can. Entries in the ban list can be addresses or regexps beginning with ^ that match addresses such as
^.*[@.]example.com$
to match any address in the example.com domain or a subdomain thereof.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (4)
-
Chihurumnaya Ibiam -
Ibiam Chihurumnaya
-
Mark Sapiro -
Stephen J. Turnbull