Re: [Mailman-Developers] Adding DMARC support for Mailman 3
![](https://secure.gravatar.com/avatar/a66e05f54765bbac4a8f86c86af21755.jpg?s=120&d=mm&r=g)
----- Original Message -----
From: "Mark Sapiro" <mark@msapiro.net> To: "Franck Martin" <franck@peachymango.org> Sent: Monday, July 8, 2013 10:37:01 AM Subject: Re: [Mailman-Developers] Adding DMARC support for Mailman 3
On 07/08/2013 08:34 AM, Franck Martin wrote:
I suspect this process has been improved in MM3, but I have not had a look at the code. The purpose is for mailman to recognize 5.7.x bounces and not count them against the recipient (or as soft bounce). Hard bounce is the default for any non recognized bounce.
MM3 uses flufl.bounce <https://launchpad.net/flufl.bounce> for bounce processing. The process, algorithms and heuristics are essentially identical to MM2.1
In the case of an RFC 3464 compliant DSN, MM does not look at the Status field at all. It only looks at the Action field. Actions beginning with 'fail' result in a 'permanent failure' determination. Actions beginning with 'delayed' result in a 'temporary failure' determination. All other actions result in the bounce being ignored.
I see in MM2 that regex are used to classify the bounces: http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/files/head:/Mailman/...
which is described in broad terms here: http://www.esosoft.com/support/mailinglist/mailman/bounce.html
It seems flufl has the same structure http://bazaar.launchpad.net/~mailman-coders/flufl.bounce/trunk/files/head:/f...
but I just read the code quickly...
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 07/08/2013 10:52 AM, Franck Martin wrote:
I see in MM2 that regex are used to classify the bounces: http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/files/head:/Mailman/...
Yes and no. Bounce processing in the non-VERP case works by processing the DSN through a series of heuristic recognizers. A recognizer returns a possibly empty list of bouncing addresses or a special STOP signal.
If the STOP signal is returned, it means "I recognize this, but ignore it" and processing of this bounce stops. If a non-empty list is returned, bounces are scored for those addresses and processing stops. If an empty list is returned, processing continues to the next recognizer. Several of the heuristic recognizers use regexps in the recognition process, but ideally, all DSNs would be RFC 3464 compliant and the recognizer for these looks only at the Action field to determine what to do.
Of course in the real world, not all DSNs are RFC 3464 compliant, so we have a bunch of other recognizers.
This is different in the VERP case in that the bouncing address is always obtained from the envelope recipient and the recognozers are only called to determine if the bounce is fatal or not.
MM3 is different in that its recognizers return two sets of addresses, one for permanent and one for temporary failures.
which is described in broad terms here: http://www.esosoft.com/support/mailinglist/mailman/bounce.html
And which is not strictly correct for MM2.1 at least because in MM2.1, contrary to the documentation, there are no 'soft bounces'. Either delivery failed, even for a full mailbox, in which case we score a 'hard bounce', or it didn't (yet) in which case we score nothing.
It seems flufl has the same structure http://bazaar.launchpad.net/~mailman-coders/flufl.bounce/trunk/files/head:/f...
In essence, the structure and process are the same, but it does add the temporary failure notion.
It would certainly be possible to add recognition of a DMARC policy rejection and not report it as a bounce for a recipient (or fix the bugs one by one as they are reported), although I suspect it would be some while before the dust settles and most all the non-compliant MTAs bounces are properly classified.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Franck Martin
-
Mark Sapiro