![](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