outgoing.py mailman@example.com issue
I deployed Mailman3 last night and today we've had some "bounced" messages with headers referencing mailman@example.com. This has only happened with a few lists. Any ideas what causes this? We are using an SMTP relay server for incoming and outgoing messages in front of the Mailman3 service.
Thanks!
Received: from [172.17.0.2] (ec2-52-25-39-43.us-west-2.compute.amazonaws.com [52 .25.39.43]) by smtp2.caltech.edu (Postfix) with ESMTP id B97472076421 for <xxxxxxx@caltech.edu>; Fri, 5 Nov 2021 12:34:34 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.caltech.edu B97472076421 From: Mailman <mailman@example.com> To: Mailman Bounces <mailman-bounces@example.com> Subject: SMTP Delivery Failure Message-ID: <163614051784.271.12319265021103466218@badc5045e1e5> Date: Fri, 05 Nov 2021 12:28:37 -0700
-- Dan
dancab@caltech.edu writes:
I deployed Mailman3 last night and today we've had some "bounced" messages with headers referencing mailman@example.com. This has only happened with a few lists. Any ideas what causes this?
Somewhere in the distributed configuration files there is a sample configuration for "mailman@example.com" that you have to override in the site configuration. <mailman@your-site.tld> is the "site list" which standard list for Mailman operational queries, and your site admins (at least) should be subscribed. Also, this list must be configured for your site to operate properly. (It's been a while but I seem to recall Mailman won't even start if this address isn't configured.) To find the relevant configuration and probably some documentation in comments, grep the source files (probably in src/mailman/config) to find it.
Somebody put this in the list owner's email for those lists. This seems less likely than 1.
Mark may have a better idea.
Steve
On 11/7/21 1:22 AM, Stephen J. Turnbull wrote:
dancab@caltech.edu writes:
I deployed Mailman3 last night and today we've had some "bounced" messages with headers referencing mailman@example.com. This has only happened with a few lists. Any ideas what causes this? ... Mark may have a better idea.
This is a fake DSN that is generated when Mailman's attempt to send a bounce probe results in a failure from the MTA to which Mailman delivers. See code at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/runners/outgoin... and around https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/runners/outgoin...
-- 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 11/7/21 1:22 AM, Stephen J. Turnbull wrote:
dancab@caltech.edu writes: I deployed Mailman3 last night and today we've had some "bounced" messages with headers referencing mailman@example.com. This has only happened with a few lists. Any ideas what causes this? ... Mark may have a better idea. This is a fake DSN that is generated when Mailman's attempt to send a bounce probe results in a failure from the MTA to which Mailman delivers. See code at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/runners/outgoin... and around https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/runners/outgoin...
We do have mailman@caltech.edu configured with valid members/owners. We're using Postfix for the MTA. Is it possible there's a misconfiguration there?
We've been testing the system with a handful of lists for months.
-- Dan
On 11/8/21 11:10 AM, dancab@caltech.edu wrote:
We do have mailman@caltech.edu configured with valid members/owners. We're using Postfix for the MTA. Is it possible there's a misconfiguration there?
We've been testing the system with a handful of lists for months.
The bounce you saw
From: Mailman mailman@example.com To: Mailman Bounces mailman-bounces@example.com Subject: SMTP Delivery Failure
may have sent because you have VERP probes enabled (verp_probes: yes in the mta section of mailman.cfg) and a user on some list reached the bounce score threshold and a Mailman attempted to send a probe and the MTA refused the message, or it may have been sent because Mailman attempted to send a message to the user and the MTA refused it.
In either case, the bounce message (fake DSN) should have contained a message body like
Mail to user@example.com failed at outgoing SMTP
with the actual user's address. These fake DSNs are sent in the case where the outgoing MTA refuses a message from Mailman so there is no actual failure DSN.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
In either case, the bounce message (fake DSN) should have contained a message body like Mail to user@example.com failed at outgoing SMTP with the actual user's address. These fake DSNs are sent in the case where the outgoing MTA refuses a message from Mailman so there is no actual failure DSN.
Thanks. I think I'm missing how I can configure Mailman so that the actual user's address is used.
On 11/8/21 8:28 PM, dancab@caltech.edu wrote:
In either case, the bounce message (fake DSN) should have contained a message body like Mail to user@example.com failed at outgoing SMTP with the actual user's address. These fake DSNs are sent in the case where the outgoing MTA refuses a message from Mailman so there is no actual failure DSN.
Thanks. I think I'm missing how I can configure Mailman so that the actual user's address is used.
I think you are missing the point. This is a pseudo DSN. If it were a real DSN it would be something like
From: mailer-daemon@somewhere To: listname-bounces@listdomain
However, there is no real DSN because Mailman has gotten a reject in it's attempt to deliver to the outgoing MTA so it creates it's own pseudo DSN for the failure.
Another way of looking at this is if you configured Mailman to deliver to a local MTA and configured that MTA to relay to your remote MTA, your local MTA would accept the message and then receive the 5xx status upon delivery to the Remote MTA and would then send an appropriate DSN back to the list-bounces address.
Since you are skipping the local MTA part, Mailman gets the 5xx status upon delivery to the remote MTA and creates it's own DSN for itself.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks for clarifying that. I had adjusted postfix yesterday and wanted to be sure I wasn't missing anything else. The postfix configuration was causing repeated local look up failures and resulting in the behavior you described. We were getting so many at one point that I wanted to be sure there was nothing else to look at.
Thanks yet again!
participants (3)
-
dancab＠caltech.edu -
Mark Sapiro -
Stephen J. Turnbull