[Mailman-Developers] Fixing DMARC problems with .invalid munge

Stephen J. Turnbull stephen at xemacs.org
Mon May 5 09:38:08 CEST 2014


John R Levine writes:

 > One advantage of this hack is that you can just turn it off when
 > you don't need it, much easier than the stuff that puts the list
 > address in the From: line which affects everyone.

You're wrong on both counts.  In Mailman 2.1.18, "From" munging is
equally easy to turn off -- two clicks on an admin page.  In Mailman
2.1, it's unlikely that anything will ever get easier than that (not a
lot of Web 2.0 fancy click-once-and-be-done-with-it stuff in 2.1).
And Mailman 2.1.18 has an option that munges "From" only in case of a
published "p=reject" DNS record.

As for the rest of your post, you didn't say anything new and you
didn't rebut my point about the limitations on what will be visible to
individual postmasters in the short run.  Until we have more evidence
(or at least much better theory than I've seen so far, including from
myself) on the long-run system-wide effects of ".invalid", I'm going
to oppose implementing it *in Mailman*.

To give you one example that demonstrates how little we know about
system-wide effects, I don't recall predictions of mass unsubscribes
of third parties when a major freemail provider changed policy to
"p=reject".  That's an "oops".  I doubt that ".invalid" will have that
obvious an effect in the short run, but I think there is a real,
worrisome possibility that it will have a more subtle, infrequent
effect that cumulates over time.

Note that I am not telling *you* what to do or not to do.  I am saying
that the *Mailman Project* should act according to "Look Before You
Leap" (and IMO preferably not leap ever, but that's just my opinion),
rather than being seduced by "Easier to Ask Forgiveness than
Permission."  It may be *easy* for Mailman to ask, but if things do go
south, forgiveness may not be forthcoming.



More information about the Mailman-Developers mailing list