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