[Mailman-Developers] Adding DMARC support for Mailman 3

[Stephen J. Turnbull]

Franck Martin writes:

 > The current practice for a postmaster is to trust (or not) emails
 > from specific mailing lists, not who post them to the list.

Really?  I thought they trusted SMTP connections from specified MTAs
(IP addresses).  (More precisely, folks who seem to be running
legitimate lists who run into problems generally find that their IP is
blocked, not any identification of the list.)  Anyway, List-Id is
trivial to forge; I wouldn't trust it.

 > Adding DKIM to the list and taking ownership will only improve it.

DKIM is fine, if postmasters actually do trust lists.  Just use
List-Id as one of the signed headers and add your own DKIM signature.
Done, no need to violate RFC 5322.

So I went back and re-read the DMARC spec (more carefully than I did a
year ago, it seems, because it seems to be a rather different document
than the one I remember reading :-/), and it seems to me that From-
munging is not only a bad idea from the point of view of mailing list
custom and RFC 5322 conformance, but it violates the spirit of DMARC
as well.

DMARC is a framework for implementing, evaluating, and improving
sender policies at the domain level.  It insists (correctly, for the
intended application of anti-phishing) on using From and nothing else.
In most cases the primary users[1] of DMARC (institutions that handle
private data, whose domain names are well-known -- at least to
correspondents -- and can be used for phishing) want to ensure that
only messages originating from their domain can use their domain name,
or at least that non-technical users can be given a very obvious
indication that something funny is going on if a "From" using their
domain name originated from a different domain.  But they *want* their
domain names seen.  They don't want them munged.

*****

But this philosophical discussion isn't really convincing even to me.
I'd like to see examples of real use cases for DMARC, and the
recommended policy settings for them.


Footnotes: 
[1]  The users whose requirements are reflected in DMARC's specific
requirements.