Mysterious Bounces Being Logged
I keep seeing bounces being recorded in logs/bounce.log that have no corresponding entry in Postfix's mail.log. For instance one address had registered about 2 dozen bounces in the past week in bounce.log and yet every single entry for this address in mail.log has a status=sent. What am I missing here?
-- Brian Carpenter Harmonylists.com Emwd.com
On 3/26/21 11:31 AM, Brian Carpenter wrote:
I keep seeing bounces being recorded in logs/bounce.log that have no corresponding entry in Postfix's mail.log. For instance one address had registered about 2 dozen bounces in the past week in bounce.log and yet every single entry for this address in mail.log has a status=sent. What am I missing here?
They are being bounced by a downstream MTA. If you want to know why, you have a few choices. You can mail the address yourself and hopefully get a DSN back. You can install this patch: ```
diff --git a/src/mailman/runners/lmtp.py b/src/mailman/runners/lmtp.py index 6a0bdcf5e..eca474089 100644 --- a/src/mailman/runners/lmtp.py +++ b/src/mailman/runners/lmtp.py @@ -217,6 +217,8 @@ class LMTPHandler: slog.debug('%s subaddress: %s, queue: %s', message_id, canonical_subaddress, queue) status.append('250 Ok') + if queue == 'bounces': + config.switchboards['bad'].enqueue(msg, msgdata) except Exception: slog.exception('Queue detection: %s', msg['message-id']) config.db.abort()
``` which will add all received bounces as queue files in Mailman's var/queue/bad. At some point, we need to implement the attachment of the bounce DSN to the notices sent to the admin, but that isn't done yet. -- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 3/26/21 2:59 PM, Mark Sapiro wrote:
They are being bounced by a downstream MTA. If you want to know why, you have a few choices. You can mail the address yourself and hopefully get a DSN back. You can install this patch:
I would think any mail administrator for a mailman server would want to know why bounces are happening. I never saw this issue with Mailman 2. Did it exist?
Is the patch going to make it to the next version of Mailman 3 core? Are there any plans to make bounce processing more transparent to server admins so we can troubleshoot delivery issues?
-- Brian Carpenter Harmonylists.com Emwd.com
All,
Appreciation to Brian for bringing this up. After upgrading to MM3, a lot of legitimate users' subscriptions on my lists have been disabled even though they still get at least some messages (according to them), while some were correctly disabled.
Yes, I need to be informed of bounces, because when the accounts get disabled, I don't want my reply to be 'Huh? I don't have a clue why.'
I reported this before.
Yours,
AllanOn 3/26/21, 14:08 , "Brian Carpenter" <brian_carpenter@emwd.com> wrote:
On 3/26/21 2:59 PM, Mark Sapiro wrote:
> They are being bounced by a downstream MTA. If you want to know why, you
> have a few choices. You can mail the address yourself and hopefully get
> a DSN back. You can install this patch:
I would think any mail administrator for a mailman server would want to
know why bounces are happening. I never saw this issue with Mailman 2.
Did it exist?
Is the patch going to make it to the next version of Mailman 3 core? Are
there any plans to make bounce processing more transparent to server
admins so we can troubleshoot delivery issues?
--
Brian Carpenter
Harmonylists.com
Emwd.com
_______________________________________________
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/On March 26, 2021 2:08:01 PM PDT, Brian Carpenter <brian_carpenter@emwd.com> wrote:
I would think any mail administrator for a mailman server would want to
know why bounces are happening. I never saw this issue with Mailman 2. Did it exist?
No. Mailman 2.1 always included the DSN in notices to the admin.
Is the patch going to make it to the next version of Mailman 3 core?
No. I don't think it's generally useful. It's use is too obscure.
Are there any plans to make bounce processing more transparent to server admins so we can troubleshoot delivery issues?
Absolutely. At first MM3 wasn't processing bounces at all. A GSOC student did the bulk of the current implementation and we were happy to get that even though this piece was missing. We know we need it. If you don't think we're working fast enough, you can submit a merge request or dock our pay.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
On 3/26/21 6:13 PM, Mark Sapiro wrote:
Absolutely. At first MM3 wasn't processing bounces at all. A GSOC student did the bulk of the current implementation and we were happy to get that even though this piece was missing. We know we need it. If you don't think we're working fast enough, you can submit a merge request or dock our pay.
I don't understand the sarcasm here at all. I am just trying to figure out what the PRIORITIES are from the Mailman 3 developers. That's all. BTW, I still haven't figured it out.
It still doesn't explain why Postfix is not recording the delivery issues which I assume has nothing to do with Mailman 3. I see successful deliveries with Postfix and bounces with Mailman 3 core. I never seen that with Mailman 2 and Exim. They always matched. If you can help me to understand that with out the petty sarcasms then that would be great. If not, then ok.
-- Brian Carpenter Harmonylists.com Emwd.com
On 3/26/21 8:51 PM, Brian Carpenter wrote:
On 3/26/21 6:13 PM, Mark Sapiro wrote:
Absolutely. At first MM3 wasn't processing bounces at all. A GSOC student did the bulk of the current implementation and we were happy to get that even though this piece was missing. We know we need it. If you don't think we're working fast enough, you can submit a merge request or dock our pay.
I don't understand the sarcasm here at all. I am just trying to figure out what the PRIORITIES are from the Mailman 3 developers. That's all. BTW, I still haven't figured it out.
OK, the "dock our pay" remark was uncalled for, but I was only trying to point out that for the most part, all of this work is being done by or in some cases mentored by Abhilash and me, and we are both volunteers with other responsibilities.
This is a known issue <https://gitlab.com/mailman/mailman/-/issues/737> posted by me 8 months ago. There are no offers to help work on it, nor are there any comments to the effect that this should be higher priority than any of the 307 other open Mailman core issues in the tracker.
I can't speak for Abhilash, but my priorities are fix things that are trivial to fix as they arise and work on the harder stuff as time and interest allow. I realize that doesn't help you much, but I'm a volunteer. This is (one of) my hobbies. If it's not fun or at least satisfying, I won't do it.
It still doesn't explain why Postfix is not recording the delivery issues which I assume has nothing to do with Mailman 3. I see successful deliveries with Postfix and bounces with Mailman 3 core. I never seen that with Mailman 2 and Exim. They always matched. If you can help me to understand that with out the petty sarcasms then that would be great. If not, then ok.
I don't know why you never saw this with MM 2.1 and Exim. Possibly because MM 2.1 sent you the DSN with the admin notification, you never looked.
I told you in my initial reply in this thread "They are being bounced by a downstream MTA." To elaborate on that, Mailman's MTA be it Postfix, Exim or whatever, attempts to deliver the mail to the MX of the recipient domain. Sometimes this results in a 5xx status which is logged and reported as a bounce to the sender, i.e. the LIST-bounces address. Sometimes it results in a 4xx status which will cause the delivery to be retried at intervals until it is either accepted or exceeds a configured lifetime and is reported as a permanent failure. The rest of the time, the delivery succeeds, but that is only delivery to the MX for the domain. It may be that for that recipient, that MX is a relay to another MX in the delivery chain, and sometimes, either quickly or after some delay due to retries downstream eventually timing out, the ultimate delivery fails and a DSN is returned to the original envelope sender which is the LIST-bounces address.
If you look in the Postfix logs around the time that Mailman recorded the bounce, you should see an incoming message from=<> (DSNs always have a null envelope sender) and to=<LIST-bounces@list.domain> or if you are VERPing to=<LIST-bounces+recip=recip.domain@list.domain> which is the DSN being returned by the downstream MTA.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Allan Hansen -
Brian Carpenter -
Mark Sapiro