Hi, another season, another "From rewriting" proposal. Once again, it more or less amounts to wishing mailing lists away. So let me try to articulate precisely what is wrong with all those approaches:
A) The From field ================= 0) Unless I missed something, changing the semantics of RFC5322.From, even just for mailing lists, is way off charter for this group. 1) The From field semantics are important not just for interoperability with software systems, but also for "interoperability" with us *humans*, which makes them especially hard to change :-) This human meaning is twofold: a) the "friendly From" conveys *authorship*, that is the (possibly pseudonymal) identity of an *natural person* who claims credit and accepts responsibility for the content. A corporate entity such as a domain is *not* an author. And whatever the "moderation" mechanism, a censor is just that, and will never be an author either. b) the address part provides a *contact point* for the above-defined author, that must be as much as possible *stable* and under the control of an entity *trusted by the author*. 2) All proposed "From rewriting" mechanisms fail at least one of the above requirements. The traditional mechanism blurs the authorship, by introducing a false sense of *affiliation*. This message is authored by "Baptiste Carvello", not "IETF" or even "Baptiste Carvello by IETF". I demand full credit, and I'm sure IETF happily lets me bear full responsibility. Any mechanism that rewrites the address alone gives a wrong idea of the contact point and thus possibly "hijacks" communication attempts. The present proposal is especially egregious in that is does so without any hint to the reader. If this happened to me, I would feel like I'm subject to identity theft, sorry to say. In fact, I lied, the "unwrapping" mechanism could meet both requirements. Except that it is vaporware that no MUA has expressed interest in implementing. And that for all practical purposes, it would be equivalent to disabling DMARC for mailing-list traffic. Quite a loophole, right? B) Mailing lists ================ 1) Again, I question the process of redefining the operating principles of mailing lists in a forum where neither mailing-list operators, nor developers of mailing-list systems or even MUAs are represented. This seems like a recipe for "solving" the wrong problem. Fragmenting the ecosystem by creating a new incompatible "blessed by DMARC" kind of mailing list is of course worse than everything. 2) Specifically, the present proposal fails to take into account that mailing lists are fundamentally different from "closed-group communication systems", not by deficiency, but by *design*. Interoperability with direct e-mail, including the possibility to privately reply to the author (or to temporarily invite non-members by just CC-ing them), is a necessary feature, not a "security hazard" to be fixed. 3) Many (most?) mailing lists are not "intended to be a closed group" living only in the "environment" of their hosting domain. They are communication channels for open communities that have an autonomous existence, and as such should be resilient even to the loss of their mailing-list provider (if it closes shop, or "turns evil"). The community can then only be rescued if users know each-other's real addresses. Aliases would fail you precisely when you need them most! C) Now what =========== So what's my solution? Well I recognize it's not easy, but a first step could be to mandate that, in the case of DMARC FAIL and p=reject, a message coming in from a mailing list (with a List-Id header) must not be bounced, but *ignored*. The rationale is twofold: 1) Bounces produce no useful result whatsoever, as they never reach back to the originating domain. All they can do is have the recipient users delisted. 2) DMARC incorporates its own reporting mechanism, which goes to the right place. Once DMARC-compliant receivers do this, mailing list operators can remove their workarounds and happily get out of the way. Messages would be lost at first, but DMARC-compliant senders and receivers would collectively bear responsibility for solving *their* problem. Field-testing new solutions would be easier with only two partners, both involved in the DMARC community, than with three. I expect those solutions to be ARC + something… Cheers, Baptiste Le 04/10/2021 à 02:17, Douglas Foster a écrit : > As I hinted in a recent message, I believe that DMARC-compliant mailing > lists are possible. I have posted a draft which explicates how this > can be done. > > Doug Foster > > > ---------- Forwarded message --------- > From: <internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>> > Date: Sun, Oct 3, 2021 at 8:14 PM > Subject: New Version Notification for > draft-fosterd-dmarc-compliant-mailing-lists-00.txt > To: Douglas Foster <dougfoster.emailstanda...@gmail.com > <mailto:dougfoster.emailstanda...@gmail.com>> > > > > A new version of I-D, draft-fosterd-dmarc-compliant-mailing-lists-00.txt > has been successfully submitted by Douglas Foster and posted to the > IETF repository. > > Name: draft-fosterd-dmarc-compliant-mailing-lists > Revision: 00 > Title: DMARC Compliant Mailing Lists > Document date: 2021-10-03 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/archive/id/draft-fosterd-dmarc-compliant-mailing-lists-00.txt > Status: > https://datatracker.ietf.org/doc/draft-fosterd-dmarc-compliant-mailing-lists/ > Html: > > https://www.ietf.org/archive/id/draft-fosterd-dmarc-compliant-mailing-lists-00.html > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-fosterd-dmarc-compliant-mailing-lists > > > Abstract: > Mailing Lists often make changes to a message before it is > retransmitted. This invalidates DKIM signatures, causing a DMARC > test on the RFC5322.From addres to fail. A DMARC-compliant mailing > list is one which uses member alias addresses to identify the > document as sent by a specific author via the mechanism of the list. > An appropriate aliasing mechanism will not only prevent DMARC FAIL, > but will also allow messages between members, will look natural to > senders and recipients, and will allow list organization domains to > advance to p=reject. This document describes an aliasing approach > which meets these goals. > > > > > The IETF Secretariat > > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
