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