On 10/23/21 10:51 AM, David Bremner wrote:
I'm getting (many) uncaught bounce messages for one user. Other than forcibly unsubscribing them, is there anything I can do? I hesitate to post this message publically, but here is what I can see, somewhat anonymized
If you send me the complete bounce message off list, I can see if it should be added to the recognition at https://gitlab.com/warsaw/flufl.bounce/. BTW, is flufl.bounce in your installation version 4.0? If not you can update via
pip install -U flufl.bounce
which may help. Actually, depending on how these where installed, it might be necessart=y to do
pip install -U flufl.bounce flufl.lock flufl.i18n
To avoid import errors due to packaging issues.
The MIME structure looks like
└┬╴multipart/mixed 7030 bytes ├─╴text/plain 442 bytes ├─╴message/delivery-status 176 bytes └─╴text/rfc822-headers 5301 bytes
This is not a RFC 3464 compliant DSN which looks like the above except the top level is multipart/report, not multipart/mixed. However, our recognizer shouldn't care as it only looks at the message/delivery-status part.
In /var/log/mailman3/bounce.log I see lines like
Oct 23 08:20:00 2021 (5320) Bounce message w/no discernable addresses: <hex-digits@foo.bar>
<hex-digits@foo.bar> is the Message-ID:
In the delivery-status part I see
A compliant DSN will also have a
Reporting-MTA:
section preceding the Final-Recipient: section.
Final-Recipient: rfc822; fub@foo.bar Action: delayed Status: 4.0.0
This is not a bounce. It is a 'delivery delayed' message. If delivery is not accomplished within an MTA configured time (days), it will turn into a 5.x.x failure which is a bounce, but since fub@foo.bar was not recognized, the DSN is non-compliant in some way.
In any case, please send me a copy of the bounce so I can see about recognizing it.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan