J. Gomez writes:

 > Missuse of DMARC's p=reject by Senders is here to stay. It won't go
 > away. It will only grow.[*] 

I'm not so sure.  Anyway, that doesn't mean we need to sanction it.

 > In my opinion, the least disruptive adaptation which mailing list
 > software can do is to take ownership --in a DMARC-compatible way--
 > of the Header-From,

I disagree.  The least disruptive adaption is whatever the users of
the mailing list think is the least disruptive adaptation.  That's why
Mailman provides multiple mitigation options, and will probably add
more as we think of them or they're contributed to us.

 > just like they already take ownership of the envelope's
 > ReturnPath-From.

Ah, but "just like" is a complete misstatement of the situation.
There's a big difference.  Users on a mailing list think of the
poster, not the mailing list, as responsible for the content.  So
according to RFC 5322, the poster's mailbox belongs in From:.
Remailed or not, the author belongs there.

According to the RFCs, Return-Path does not correspond to From, it's
more similar to the semantics of Sender (but not identical).  Whoever
is going to handle delivery issues belongs in Return-Path.  The
remailing agent belongs there, because the poster, in general, doesn't
know where the message is being sent, and can't help debug problems
between the remailer and the subscriber.

 > And, also in my opinion, that mailing list adaptation to DMARC
 > should be the new default out-of-the-box behaviour of mailing list
 > packages from now on, and the old behaviour should be regarded as
 > legacy and deprecated.

Actually, in GNU Mailman I suspect that going forward the default
behavior will be either no mitigation (as now, just by momentum), or
wrap-in-a-new-message-if-p=reject-detected, which is fully RFC
conformant, although not iDevice-Apple-Mail-friendly.  Some developers
are just prickly curmudgeons.[***]  cPanel and Plesk and RHEL are
welcome to patch their versions, of course.

[***] And that, too, is the way the world goes by.


Steve

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to