[Mailman-Users] Erratic mail delivery times

[Stephen J. Turnbull]

Peter Shute writes:

 > Thanks, Dave. How are you coping with yahoo emails if you've only
 > got 2.1.17? I can't remember what changes it's got in it, but I
 > thought the latest dealt with it better.

IIRC the big difference between 2.1.17 and 2.1.18-1[1] is that in
2.1.17 the DMARC-mitigation features[2] are applied to *all* posts,
whereas in 2.1.18 you have the option of checking the DMARC policy and
only making those ugly changes to posts *from domains with a "p=reject"
DMARC policy* (requires an additional Python package to make the DNS
check for the policy).  You can also (in >= 2.1.18) "preemptively"[3]
reject such posts before trying to distribute them, and thus
distribute only posts that will not trigger DMARC rejects.

2.1.18-1 may also have some minor improvements in bounce handling, but
as far is I know this is still problematic as many receiving hosts
don't tell you that it's a DMARC reject, and even those that do have a
wide variety of idioms for indicating that.  So many DMARC rejects
will increment subscribers' bounce counts, even though the reject was
instigated by the poster's service provider.

Steve


Footnotes: 
[1]  Avoid 2.1.18, it has a bug that is fatal on some systems.

[2]  Encapsulation in a mini-digest which is From: mailman, or
directly munging from so that the address that appears there is
mailman's address, not the poster's.  The Reply-To field is tweaked so
that the poster can be addressed without copying the address by hand.

[3]  Usually at the Mailman host the post will pass the DMARC check,
and so the Mailman host's MTA may participate in DMARC protocols but
it will still deliver to Mailman regardless of DMARC policy at the
source.  However, due to the nature of the protocol, a Mailman list
which changes the post (even just a list tag in the Subject) will
necessarily fail the check, so Mailman knows when a DMARC reject of
distributed posts will occur.