Is there a way of recording bounce messages?
Hi.
I recently had an incident of all gmail.com members being bounced off one email list (around 180 subscribers). The messages recording the bounce don't include the original DSN. Is there a way of getting the DSN recorded? I'm sure it will give me some nonsense Gmail refusal message but I would like to identify if messages are bouncing for specific users, or if I am harming my reputation by sending to disabled accounts etc.
Thanks. Andrew.
Andrew Hodgson writes:
I recently had an incident of all gmail.com members being bounced off one email list (around 180 subscribers).
This is almost certainly due to a recent policy change at Gmail, where they are requiring "from alignment"[1] but only for Gmail authors. That is, Gmail does not publish a p=reject policy, but the effect on Gmail recipients (only) is the same as if they did -- they all bounce every time a Gmail user posts.
Mark has a patch in process, search recent archives of this list for a pointer to it.
Instead of the patch, you can set the "munge from" option for all users instead of the option for p=reject domains only. Or you could ban Gmail addresses from posting. ;-)
Footnotes: [1] "From alignment" is the requirement in DMARC for p=reject or p=quarantine policies that there be a valid DKIM signature from the author's email domain (ie, the From address).
Stephen J. Turnbull wrote:
This is almost certainly due to a recent policy change at Gmail, where they are requiring "from alignment"[1] but only for Gmail authors. That is, Gmail does not publish a p=reject policy, but the effect on Gmail recipients (only) is the same as if they did -- they all bounce every time a Gmail user posts.
Another way to prevent gmail users from having delivery disabled and
being unsubscribed because of this is to enable VERP probes (set
verp_probes: yes in the [mta] section of mailman.cfg). Since the
probes are not sent from a gmail user, they won't bounce and the user's
delivery won't be disabled.
This is not a fix for the issue as the gmail users will still not receive posts from other gmail users, but they will receive other posts and won't get their delivery disabled by bounce.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 9/21/23 07:06, Andrew Hodgson wrote:
Hi.
The messages recording the bounce don't include the original DSN.
This is https://gitlab.com/mailman/mailman/-/issues/737 fixed in Mailman 3.3.5
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro <mark@msapiro.net> wrote:
On 9/21/23 07:06, Andrew Hodgson wrote:
Hi.
The messages recording the bounce don't include the original DSN.
This is https://gitlab.com/mailman/mailman/-/issues/737 fixed in Mailman 3.3.5
Hmm. I'm on 3.3.8 and there was no attached bounce message in any of the reports.
Thanks. Andrew.
On 9/21/23 11:28, Andrew Hodgson wrote:
Hmm. I'm on 3.3.8 and there was no attached bounce message in any of the reports.
Can you provide one of the bounce report messages and the corresponding bounce message from the MTA log.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro <mark@msapiro.net> wrote:
On 9/21/23 11:28, Andrew Hodgson wrote:
Hmm. I'm on 3.3.8 and there was no attached bounce message in any of the reports.
Can you provide one of the bounce report messages and the corresponding bounce message from the MTA log.
I only have the message I would get as the owner of the list that the delivery has been disabled, I don't have the original bounce message. One thing to note is the bounce messages coming in from Gmail are being generated by Office 365 (as that is the outbound smarthost for the Mailman server), so it may be due to the format of those NDRs why we aren't seeing the original bounce messages attached to the email.
Thanks. Andrew.
On 9/21/23 15:01, Andrew Hodgson wrote:
Mark Sapiro <mark@msapiro.net> wrote:
Can you provide one of the bounce report messages and the corresponding bounce message from the MTA log.
I only have the message I would get as the owner of the list that the delivery has been disabled,
That's the one I'm interested in. If possible I'd like to see the actual raw message, not some MUAs rendering of it.
I don't have the original bounce message. One thing to note is the bounce messages coming in from Gmail are being generated by Office 365 (as that is the outbound smarthost for the Mailman server), so it may be due to the format of those NDRs why we aren't seeing the original bounce messages attached to the email.
So as I understand it, Office 365 is sending the mail to the gmail recipient which is presumably rejecting the mail at SMTP with a 5xx status.
Does Office 365 report the failure to Mailman with a failure status at SMTP time or later with an emailed DSN.
If the former, there should be log messages in Mailman's smtp.log indicating the number of failures '$msgid post to $listname from $sender, $size bytes, $refused failures' and the reason for each '$msgid delivery to $recip failed with code $smtpcode, $smtpmsg'.
Also, we create a fake DSN. See https://gitlab.com/mailman/mailman/-/blame/master/src/mailman/runners/outgoi...
If the latter we have the DSN from Office 365. In either case, the DSN should be attached to the notice. I don't know why it wouldn't be.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark,
As a person fluent in MS365 they are a catchall. The MS server tends to always accept the message. It then triggers a bounce after the fact because of the multilayered transit patterns MS365 uses for handing off messages.
I know this because of custom mailing alert system integrations with MS365 not triggering SMTP transfer time alerts but receiving the bounces after MS365 has received the message and hands off to its edge transports to remote clients, then later sends a DSN. (I have spent three weeks digging on this for a FT Job task so I am unfortunately damned fluent in how MS365 processes SMTP to recipients that will decline or bounce...)
MS365's bounce handling is weird and they do not include a delivery report in the payload, instead they take the log data and append it as a text payload portion to the message. It's annoying and problematic when debugging (and likely triggers the mailman2 equivalent of "unprocessable bounce message").
If Andrew can provide the bounce message as an example in raw form (even off list) we can dissect it - myself probably more rapidly as I am fluent in reading them at this point from weeks worth of dealing with them - and that will probably yield the info you are looking for.
Thomas
Sent from my Galaxy
-------- Original message -------- From: Mark Sapiro <mark@msapiro.net> Date: 9/21/23 19:36 (GMT-05:00) To: mailman-users@mailman3.org Subject: [MM3-users] Re: Is there a way of recording bounce messages? On 9/21/23 15:01, Andrew Hodgson wrote: > Mark Sapiro <mark@msapiro.net> wrote: > >> Can you provide one of the bounce report messages and the corresponding bounce message from the MTA log. > > I only have the message I would get as the owner of the list that the delivery has been disabled, That's the one I'm interested in. If possible I'd like to see the actual raw message, not some MUAs rendering of it. > I don't have the original bounce message. One thing to note is the bounce messages coming in from Gmail are being generated by Office 365 (as that is the outbound smarthost for the Mailman server), so it may be due to the format of those NDRs why we aren't seeing the original bounce messages attached to the email. So as I understand it, Office 365 is sending the mail to the gmail recipient which is presumably rejecting the mail at SMTP with a 5xx status. Does Office 365 report the failure to Mailman with a failure status at SMTP time or later with an emailed DSN. If the former, there should be log messages in Mailman's smtp.log indicating the number of failures '$msgid post to $listname from $sender, $size bytes, $refused failures' and the reason for each '$msgid delivery to $recip failed with code $smtpcode, $smtpmsg'. Also, we create a fake DSN. See https://gitlab.com/mailman/mailman/-/blame/master/src/mailman/runners/outgoi... If the latter we have the DSN from Office 365. In either case, the DSN should be attached to the notice. I don't know why it wouldn't be. -- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/... This message sent to teward@thomas-ward.net
On 9/21/23 17:30, Thomas Ward wrote:
MS365's bounce handling is weird and they do not include a delivery report in the payload, instead they take the log data and append it as a text payload portion to the message. It's annoying and problematic when debugging (and likely triggers the mailman2 equivalent of "unprocessable bounce message").
If Andrew can provide the bounce message as an example in raw form (even off list) we can dissect it - myself probably more rapidly as I am fluent in reading them at this point from weeks worth of dealing with them - and that will probably yield the info you are looking for.
It appears however that Mailman does recognize the DSN returned by MS365 as the user's delivery is being disabled by bounce. The issue is whatever DSN is returned to the list-bounces address is not attached to the notice sent to the list owner about the disable and it should be.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro <mark@msapiro.net> wrote:
On 9/21/23 17:30, Thomas Ward wrote:
MS365's bounce handling is weird and they do not include a delivery report in the payload, instead they take the log data and append it as a text payload portion to the message. It's annoying and problematic when debugging (and likely triggers the mailman2 equivalent of "unprocessable bounce message").
If Andrew can provide the bounce message as an example in raw form (even off list) we can dissect it - myself probably more rapidly as I am fluent in reading them at this point from weeks worth of dealing with them - and that will probably yield the info you are looking for.
It appears however that Mailman does recognize the DSN returned by MS365 as the user's delivery is being disabled by bounce. The issue is whatever DSN is returned to the list-bounces address is not attached to the notice sent to the list owner about the disable and it should be.
Ok guys the plot thickens.
Yesterday using the Mailman Shell I unbounced all the users on that list. We had a couple of messages yesterday and I also enabled the From munging for all messages sent to the list partway through those messages coming to the list. This morning we got all Gmail users bounced again, with no NDR attached to the message.
However on one of the messages the NDR was attached, and so I'm going to send that to Mark separately. It looks like the NDR included the information for all the bouncing messages though, and that is probably because Mailman sends the messages to all users in one SMTP transaction.
The message returned from Google was:
user@gmail.com 9/22/2023 9:44:55 AM - Server at PAVPR08MB9257.eurprd08.prod.outlook.com returned '550 5.4.300 Message expired -> 421 4.4.2 Connection dropped due to SocketError' 9/22/2023 9:24:03 AM - Server at gmail-smtp-in.l.google.com (142.250.27.27) returned '421 4.4.2 Connection dropped due to SocketError'
Thanks. Andrew.
Hi.
Seems other people have had this on Office365 when I searched the specific error. I have enabled VERP now on probes and all list messages so lets see if that improves things. Thanks. Andrew.
-----Original Message----- From: Andrew Hodgson <andrew@hodgson.io> Sent: Friday, September 22, 2023 12:22 PM To: Mark Sapiro <mark@msapiro.net>; mailman-users@mailman3.org Subject: [MM3-users] Re: Is there a way of recording bounce messages?
Mark Sapiro <mark@msapiro.net> wrote:
On 9/21/23 17:30, Thomas Ward wrote:
MS365's bounce handling is weird and they do not include a delivery report in the payload, instead they take the log data and append it as a text payload portion to the message. It's annoying and problematic when debugging (and likely triggers the mailman2 equivalent of "unprocessable bounce message").
If Andrew can provide the bounce message as an example in raw form (even off list) we can dissect it - myself probably more rapidly as I am fluent in reading them at this point from weeks worth of dealing with them - and that will probably yield the info you are looking for.
It appears however that Mailman does recognize the DSN returned by MS365 as the user's delivery is being disabled by bounce. The issue is whatever DSN is returned to the list-bounces address is not attached to the notice sent to the list owner about the disable and it should be.
Ok guys the plot thickens.
Yesterday using the Mailman Shell I unbounced all the users on that list. We had a couple of messages yesterday and I also enabled the From munging for all messages sent to the list partway through those messages coming to the list. This morning we got all Gmail users bounced again, with no NDR attached to the message.
However on one of the messages the NDR was attached, and so I'm going to send that to Mark separately. It looks like the NDR included the information for all the bouncing messages though, and that is probably because Mailman sends the messages to all users in one SMTP transaction.
The message returned from Google was:
user@gmail.com 9/22/2023 9:44:55 AM - Server at PAVPR08MB9257.eurprd08.prod.outlook.com returned '550 5.4.300 Message expired -> 421 4.4.2 Connection dropped due to SocketError' 9/22/2023 9:24:03 AM - Server at gmail-smtp-in.l.google.com (142.250.27.27) returned '421 4.4.2 Connection dropped due to SocketError'
Thanks. Andrew.
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to andrew@hodgson.io
On 9/22/23 04:47, Andrew Hodgson wrote:
Yesterday using the Mailman Shell I unbounced all the users on that list. We had a couple of messages yesterday and I also enabled the From munging for all messages sent to the list partway through those messages coming to the list. This morning we got all Gmail users bounced again, with no NDR attached to the message.
However on one of the messages the NDR was attached, and so I'm going to send that to Mark separately. It looks like the NDR included the information for all the bouncing messages though, and that is probably because Mailman sends the messages to all users in one SMTP transaction.
There is only one DSN that mentions several users (I haven't received that, but I don't need it). Mailman will process that as a bounce for each mentioned user. Now, when that results in delivery being disabled for the users, the admin receives a separate notice for each user. Each notice should have the DSN attached, but the issue is when the first notice is processed, the saved DSN is deleted from the message store, so it isn't available for the subsequent notices. This is now https://gitlab.com/mailman/mailman/-/issues/1101
The message returned from Google was:
user@gmail.com 9/22/2023 9:44:55 AM - Server at PAVPR08MB9257.eurprd08.prod.outlook.com returned '550 5.4.300 Message expired -> 421 4.4.2 Connection dropped due to SocketError' 9/22/2023 9:24:03 AM - Server at gmail-smtp-in.l.google.com (142.250.27.27) returned '421 4.4.2 Connection dropped due to SocketError'
First, these appear to be due to some issue between the Server at PAVPR08MB9257.eurprd08.prod.outlook.com and the Server at gmail-smtp-in.l.google.com rather than gmail actually rejecting the message.
Second, these are delayed bounces. PAVPR08MB9257.eurprd08.prod.outlook.com has been retrying the message for some time (perhaps as much as 5 days) and has finally given up and returned the bounce. Thus, you will probably see more of these from older messages as they finally bounce.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I'm dealing with the same issue. Upon reviewing the logs, I've noticed a significant number of bounced emails for a particular mailing list. Gmail users have reported not receiving emails. I haven't been able to locate the "munge from" information. My current setup is using Mailman 3.1.1. I read it has been introduced in 3.2.
The Question is what to do with Mailman 3.1.1, if the upgrade is not an option.
I get in the logs messages like below with several Queue-ids:
Sep 25 09:03:55 localhost postfix/smtpd[26692]: 147583E927: client=a14-93.smtp-out.amazonses.com[54.240.14.93] Sep 25 09:03:55 localhost postfix/cleanup[26696]: 147583E927: message-id=<0100018acb94b326-fdf39193-144e-4fdc-8faf-0d3df54eb4ee-000000@email.amazonses.com> Sep 25 09:03:55 localhost postfix/qmgr[1298]: 147583E927: from=<>, size=24934, nrcpt=1 (queue active) Sep 25 09:03:55 localhost postfix/lmtp[26697]: 147583E927: to=<listname-bounces@servername>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.03, delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (250 Ok) Sep 25 09:03:55 localhost postfix/qmgr[1298]: 147583E927: removed
Mohsen
From: Andrew Hodgson <andrew@hodgson.io> Sent: Friday, September 22, 2023 7:47 AM To: Andrew Hodgson <andrew@hodgson.io>; Mark Sapiro <mark@msapiro.net>; mailman-users@mailman3.org <mailman-users@mailman3.org> Subject: [MM3-users] Re: Is there a way of recording bounce messages?
[EXTERNAL EMAIL]
Hi.
Seems other people have had this on Office365 when I searched the specific error. I have enabled VERP now on probes and all list messages so lets see if that improves things. Thanks. Andrew.
-----Original Message----- From: Andrew Hodgson <andrew@hodgson.io> Sent: Friday, September 22, 2023 12:22 PM To: Mark Sapiro <mark@msapiro.net>; mailman-users@mailman3.org Subject: [MM3-users] Re: Is there a way of recording bounce messages?
Mark Sapiro <mark@msapiro.net> wrote:
On 9/21/23 17:30, Thomas Ward wrote:
MS365's bounce handling is weird and they do not include a delivery report in the payload, instead they take the log data and append it as a text payload portion to the message. It's annoying and problematic when debugging (and likely triggers the mailman2 equivalent of "unprocessable bounce message").
If Andrew can provide the bounce message as an example in raw form (even off list) we can dissect it - myself probably more rapidly as I am fluent in reading them at this point from weeks worth of dealing with them - and that will probably yield the info you are looking for.
It appears however that Mailman does recognize the DSN returned by MS365 as the user's delivery is being disabled by bounce. The issue is whatever DSN is returned to the list-bounces address is not attached to the notice sent to the list owner about the disable and it should be.
Ok guys the plot thickens.
Yesterday using the Mailman Shell I unbounced all the users on that list. We had a couple of messages yesterday and I also enabled the From munging for all messages sent to the list partway through those messages coming to the list. This morning we got all Gmail users bounced again, with no NDR attached to the message.
However on one of the messages the NDR was attached, and so I'm going to send that to Mark separately. It looks like the NDR included the information for all the bouncing messages though, and that is probably because Mailman sends the messages to all users in one SMTP transaction.
The message returned from Google was:
user@gmail.com 9/22/2023 9:44:55 AM - Server at PAVPR08MB9257.eurprd08.prod.outlook.com returned '550 5.4.300 Message expired -> 421 4.4.2 Connection dropped due to SocketError' 9/22/2023 9:24:03 AM - Server at gmail-smtp-in.l.google.com (142.250.27.27) returned '421 4.4.2 Connection dropped due to SocketError'
Thanks. Andrew.
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mailman3.org%2Fmailman3%2Flists%2Fmailman-users.mailman3.org%2F&data=05%7C01%7Cmmasoudf%40aaas.org%7C72978c0056334ea941d208dbbb61be39%7C2eebd8ff9ed140f0a15638e5dfb3bc56%7C0%7C0%7C638309800710118735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EMFfZlJuqOTlpvMJVJs2JHKP9pzrvfwbvX7TrB6HK%2BI%3D&reserved=0<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> Archived at: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mailman3.org%2Farchives%2Flist%2Fmailman-users%40mailman3.org%2Fmessage%2F2XTG3AUZ7NOKVG56JLXAF4SOJR2MGJCB%2F&data=05%7C01%7Cmmasoudf%40aaas.org%7C72978c0056334ea941d208dbbb61be39%7C2eebd8ff9ed140f0a15638e5dfb3bc56%7C0%7C0%7C638309800710118735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1DJl%2BB%2FEgpdMw1l%2BZzFmgzwtTAW8vC2Esk22dlVLv0k%3D&reserved=0<https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/2XTG3AUZ7NOKVG56JLXAF4SOJR2MGJCB/>
This message sent to andrew@hodgson.io
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mailman3.org%2Fmailman3%2Flists%2Fmailman-users.mailman3.org%2F&data=05%7C01%7Cmmasoudf%40aaas.org%7C72978c0056334ea941d208dbbb61be39%7C2eebd8ff9ed140f0a15638e5dfb3bc56%7C0%7C0%7C638309800710118735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EMFfZlJuqOTlpvMJVJs2JHKP9pzrvfwbvX7TrB6HK%2BI%3D&reserved=0<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> Archived at: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mailman3.org%2Farchives%2Flist%2Fmailman-users%40mailman3.org%2Fmessage%2FAKSBXKVM35PUL7EML6NOU53UZIQG3JIF%2F&data=05%7C01%7Cmmasoudf%40aaas.org%7C72978c0056334ea941d208dbbb61be39%7C2eebd8ff9ed140f0a15638e5dfb3bc56%7C0%7C0%7C638309800710118735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2K6zWtoe4GNkV%2BBz8Cx9kF58jSDmGS8jOmS3w8i7XGo%3D&reserved=0<https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/AKSBXKVM35PUL7EML6NOU53UZIQG3JIF/>
This message sent to mmasoudf@aaas.org
On 9/26/23 11:29, Mohsen Masoudfar wrote:
I'm dealing with the same issue. Upon reviewing the logs, I've noticed a significant number of bounced emails for a particular mailing list. Gmail users have reported not receiving emails. I haven't been able to locate the "munge from" information. My current setup is using Mailman 3.1.1. I read it has been introduced in 3.2.
DMARC mitigations were introduced in Mailman 3.1.0. They should be available in 3.1.1. They were first exposed in Postorius 1.1.0.
Where are you looking for DMARC mitigations?
The Question is what to do with Mailman 3.1.1, if the upgrade is not an option.
I get in the logs messages like below with several Queue-ids:
Sep 25 09:03:55 localhost postfix/smtpd[26692]: 147583E927: client=a14-93.smtp-out.amazonses.com[54.240.14.93] Sep 25 09:03:55 localhost postfix/cleanup[26696]: 147583E927: message-id=<0100018acb94b326-fdf39193-144e-4fdc-8faf-0d3df54eb4ee-000000@email.amazonses.com> Sep 25 09:03:55 localhost postfix/qmgr[1298]: 147583E927: from=<>, size=24934, nrcpt=1 (queue active) Sep 25 09:03:55 localhost postfix/lmtp[26697]: 147583E927: to=<listname-bounces@servername>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.03, delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (250 Ok) Sep 25 09:03:55 localhost postfix/qmgr[1298]: 147583E927: removed
This only says that some Amazon MTA has relayed a bounce to Mailman. It says nothing about why the message bounced.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thank you Mark!
[EXTERNAL EMAIL]
On 9/26/23 11:29, Mohsen Masoudfar wrote:
I'm dealing with the same issue. Upon reviewing the logs, I've noticed a significant number of bounced emails for a particular mailing list. Gmail users have reported not receiving emails. I haven't been able to locate the "munge from" information. My current setup is using Mailman 3.1.1. I read it has been introduced in 3.2.
DMARC mitigations were introduced in Mailman 3.1.0. They should be available in 3.1.1. They were first exposed in Postorius 1.1.0.
Where are you looking for DMARC mitigations?
Sorry, It was my misunderstanding. DMARC mitigation is functioning well for newly created lists, even with Gmail addresses. I am suspicious that Gmail might be rejecting or bouncing emails from the list due to the reputation of those lists. It's worth noting that I am not the owner of the lists, but admin the Mailman3 infrastructure. My objective is to determine if our suspicious is accurate, whether Gmail is rejecting emails because of the bad reputation. We have asked Google, but no response so far. I am interested to know more about the reasons behind these bounces, they are all handled by Postfix and deleted.
The Question is what to do with Mailman 3.1.1, if the upgrade is not an option.
I get in the logs messages like below with several Queue-ids:
Sep 25 09:03:55 localhost postfix/smtpd[26692]: 147583E927: client=a14-93.smtp-out.amazonses.com[54.240.14.93] Sep 25 09:03:55 localhost postfix/cleanup[26696]: 147583E927: message-id=<0100018acb94b326-fdf39193-144e-4fdc-8faf-0d3df54eb4ee-000000@email.amazonses.com> Sep 25 09:03:55 localhost postfix/qmgr[1298]: 147583E927: from=<>, size=24934, nrcpt=1 (queue active) Sep 25 09:03:55 localhost postfix/lmtp[26697]: 147583E927: to=<listname-bounces@servername>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.03, delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (250 Ok) Sep 25 09:03:55 localhost postfix/qmgr[1298]: 147583E927: removed
This only says that some Amazon MTA has relayed a bounce to Mailman. It says nothing about why the message bounced.
Is there a way to send them to a mailbox? Or prevent them from being deleted, so that I can look into the message body?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mailman3.org%2Fmailman3%2Flists%2Fmailman-users.mailman3.org%2F&data=05%7C01%7Cmmasoudf%40aaas.org%7Cf37dd8a231d84ece033108dbbed72885%7C2eebd8ff9ed140f0a15638e5dfb3bc56%7C0%7C0%7C638313603546900379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IkGmf27AmO0XDrU81exf%2ByvQzfms9jpBVl6YTi45qOg%3D&reserved=0<https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> Archived at: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mailman3.org%2Farchives%2Flist%2Fmailman-users%40mailman3.org%2Fmessage%2FNYBKMEIMHDBTWSHG3YSNQDG5ACXPD5GZ%2F&data=05%7C01%7Cmmasoudf%40aaas.org%7Cf37dd8a231d84ece033108dbbed72885%7C2eebd8ff9ed140f0a15638e5dfb3bc56%7C0%7C0%7C638313603546900379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m%2FeWDpw3qHQ3DCx%2FU0JyUcPtg5i48VfzkSph22Ni9zA%3D&reserved=0<https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/NYBKMEIMHDBTWSHG3YSNQDG5ACXPD5GZ/>
This message sent to mmasoudf@aaas.org
On 9/27/23 06:35, Mohsen Masoudfar wrote:
I am interested to know more about the reasons behind these bounces, they are all handled by Postfix and deleted. ...>>> Is there a way to send them to a mailbox? Or prevent them from being deleted, so that I can look into the message body?
Presumibly you have settings for Postfix like those at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.ht... or https://docs.mailman3.org/en/latest/install/virtualenv.html#setup-mta
The simplest way is to deliver bounces to some user instead of Mailman. This will disable automated bounce processing for the list so it should be done temporarily only to see a few bounce messages and then reverted.
Lets say you have a few problem lists, list1@example.com and list2@example.com. Put the following in Postfix main.cf
virtual_alias_domains = example.com
virtual_alias_maps = regexp:/etc/postfix/temp-aliases
Then create /etc/postfix/temp-aliases with this content
list1-bounces@example.com user@example.net
list2-bounces@example.com user@example.net
where user@example.net is the address that should receive the bounces.
There are also ways to save copies of all mail received by Postfix. See, e.g., https://www.electricmonk.nl/log/2015/03/06/keep-an-archive-of-all-mails-goin...
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 9/28/23 11:15, Mark Sapiro wrote:
Lets say you have a few problem lists, list1@example.com and list2@example.com. Put the following in Postfix main.cf
virtual_alias_domains = example.com virtual_alias_maps = regexp:/etc/postfix/temp-aliasesThen create /etc/postfix/temp-aliases with this content
list1-bounces@example.com user@example.net list2-bounces@example.com user@example.netwhere user@example.net is the address that should receive the bounces.
I just realized it's not that simple. The above will bounce all mail to the example.com domain other than that addressed to the two -bounces addresses.
A possible fix is to set
list1-bounces@example.com user@example.net
list2-bounces@example.com user@example.net
^(.*)@example.com ${1}@x.example.com
in /etc/postfix/temp-aliases and edit Mailman's var/data/postfix-lmtp
and replace all @example.com with @x.example.com
Another approach is just to edit Mailman's var/data/postfix-lmtp and remove the list1-bounces@example.com and list2-bounces@example.com entries and add
list1-bounces: user@example.net
list2-bounces: user@example.net
to /etc/aliases
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Teilnehmer (5)
-
Andrew Hodgson -
Mark Sapiro -
Mohsen Masoudfar -
Stephen J. Turnbull -
Thomas Ward