Unable to get Postfix to bounce messages to non-existent lists
We have Mailman working well in our environment, but there's one thing I can't seem to make happen no matter what I try. The situation is as follows:
Postfix runs on on a different server than Mailman. Its main.cf says
local_recipient_maps = $alias_maps transport_maps = regexp:/var/mailman-data/postfix_lmtp relay_domains = regexp:/var/mailman-data/postfix_domains
The file postfix_lmtp is initially generated by Mailman (running on a different machine). A background process creates a version of the file wherein the lmtp IP address is changed to the network IP of the Mailman server, and that version is sync'd over to the Postfix server. On the latter, a typical block for a list then reads as follows (where A.B.C.D is the IP address of the Mailman server):
/^some-list@lists\.scss\.tcd\.ie$/ lmtp:[A.B.C.D]:8024 /^some-list-bounces(\+.*)?@lists\.scss\.tcd\.ie$/ lmtp:[A.B.C.D]:8024 /^some-list-confirm(\+.*)?@lists\.scss\.tcd\.ie$/ lmtp:[A.B.C.D]:8024 /^some-list-join@lists\.scss\.tcd\.ie$/ lmtp:[A.B.C.D]:8024 /^some-list-leave@lists\.scss\.tcd\.ie$/ lmtp:[A.B.C.D]:8024 /^some-list-owner@lists\.scss\.tcd\.ie$/ lmtp:[A.B.C.D]:8024 /^some-list-request@lists\.scss\.tcd\.ie$/ lmtp:[A.B.C.D]:8024 /^some-list-subscribe@lists\.scss\.tcd\.ie$/ lmtp:[A.B.C.D]:8024 /^some-list-unsubscribe@lists\.scss\.tcd\.ie$/ lmtp:[A.B.C.D]:8024
The only problem with this is that if someone sends a message to a non-existent mailing list, Postfix nevertheless accepts the mail, and it loiters in the queue for several days before eventually being bounced back to the sender. I want to get Postfix to reject mail to non-existent mailing lists immediately. I've come up short with each variation of main.cf settings I've tried, and would greatly appreciate any advice.
Many thanks Stephen Kenny
On 2/19/24 09:14, skenny@scss.tcd.ie wrote:
The only problem with this is that if someone sends a message to a non-existent mailing list, Postfix nevertheless accepts the mail, and it loiters in the queue for several days before eventually being bounced back to the sender. I want to get Postfix to reject mail to non-existent mailing lists immediately. I've come up short with each variation of main.cf settings I've tried, and would greatly appreciate any advice.
What is Postfix's reason for deferring the mail - mailq will show the
reason.
What if you just omit the
relay_domains = regexp:/var/mailman-data/postfix_domains
setting. This may cause all list mail to be rejected, but it may work (I'm not sure if transport_maps takes priority).
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Aside from Mark's advice for the stock Mailman, there's also this patch:
https://gitlab.com/mailman/mailman/-/merge_requests/1161which allows Postfix to query Mailman's Postgres database directly. This patch isn't ready for application to the mainline for "cosmetic" reasons (see discussion in the MR), but it is used in production at a very large site as is for 6 months now.
With a little separate program, there is also the LMTP callback method documented in the installation documentation. There it takes advantage of internal support in Exim4, but could be implemented in 20 lines or so of Python which takes a TCP connection from Postfix and passes it on to Mailman's LMTP server, and reports the result of the RCPT TO command then QUITs. Finally, you could also use the REST API, but that means exposing what is normally a weakly authenticated unencrypted API on the wire.
Steve
Thanks Mark Sapiro and Stephen J. Turnbull for your responses.
Re the output of mailq - this was initially confusing (to me anyway). The diagnostic for the message stuck in the queue was "connection timed out", but the IP listed was the Postfix mail server's not Mailman's. At a guess, Postfix was trying to send the message to Postfix's local domain after it failed to LMTP it over to the Mailman server, and was unable to do that too.
Since I posted yesterday, I hit upon a solution that seems to work ... I set relay_recipient_maps to the same value as transport_maps, so that the relevant config lines now look like this:
transport_maps = regexp:/var/mailman-data/postfix_lmtp local_recipient_maps = $alias_maps relay_domains = regexp:/var/mailman-data/postfix_domains relay_recipient_maps = regexp:/var/mailman-data/postfix_lmtp
This seems to have the desired effect (and, I hope, no unintended consequences). If I fire a message at a non-existent list now, I get an immediate bounce message in my mail client - "Recipient address rejected: User [nonexistent-list@lists.scss.tcd.ie] unknown in relay recipient table". No longer is the message loitering in the Postfix queue.
The Postfix documentation for relay_recipient_maps says "Optional lookup tables with all valid addresses in the domains that match $relay_domains. [...] Technically, tables listed with $relay_recipient_maps are used as lists: Postfix needs to know only if a lookup string is found or not, but it does not use the result from the table lookup."
For transport_maps, it says "Optional lookup tables with mappings from recipient address to (message delivery transport, next-hop destination). "
Postfix does what we want now: bounce the message is the list name isn't found in relay_recipient_maps, forward it on to the Mailman server via LMTP (transport_maps setting) if it is.
Re Stephen J. Turnbull's comment about the patch allowing Postfix to query Mailman's database and more, I think I'll hold off for the moment, but good to know. We will reconfigure when it makes it into an official release (we're using Maxking's Docker images).
As ever I'm really grateful for your taking the time to respond, many thanks.
Kind regards.
skenny@scss.tcd.ie writes:
transport_maps = regexp:/var/mailman-data/postfix_lmtp relay_recipient_maps = regexp:/var/mailman-data/postfix_lmtp
This seems to have the desired effect (and, I hope, no unintended consequences).
I think that this means that transport_maps is a no-op: it's completely shadowed by relay_recipient_maps. (By the same token, it means you don't have to delete the transport_maps line.)
I should go back into the Postfix documentation and document how this "should" be done for mailing lists.
Steve
participants (3)
-
Mark Sapiro -
skenny＠scss.tcd.ie -
Stephen J. Turnbull