This is a great analysis, and I am happy to highlight the points of agreement and disagreement.
Author Identifiers help me associate all the disparate elements of a communication stream, and they serve as a recall clue to help me integrate a new message with prior messages. This is why they need to be permanent and memorable. I believe much of the emotion around From Munging comes from the fact that Author=AuthorDomain@ListDomain is NOT memorable, so it fails to serve as a recall clue. Any transition to an alias-based system will encounter significant resistance because it will break that permanence. We clearly disagree about whether mailing list SHOULD be a closed group. I don't give away my email address lightly. We use multiple email addresses for personal purposes, to separate retail mass mailings from friends. Facebook is successful for the very reason that it does not give away email addresses to other participants, even though it probably compromise our privacy in a thousand other ways. Closed groups allow me to disconnect from a mail stream when it becomes problematic. Once my email address is published to a list, I lose all control over where it lands and how it is used. My defense has been to use an email address dedicated to this list. We also disagree about authorship. I argue that a message received directly from you is very different from a message received via the list. The message from the list is either more trustworthy, if I understand the list reputation, or less trustworthy, if the list is unrecognized. You propose special handling of messages from lists, but you gloss over the difficulties of identifying a list message. List headers appear in lots of mass mailings, and any header that cannot be authenticated cannot be trusted. IETF list messages are pretty easy to identify because they come from a single server and I already have a reputation assigned to IETF. So I trust the server, not the list identifier. These features are not present in the general case. There is a widespread perception that mailing lists are not currently subject to address harvesting or list spoofing. This perception leads to an assumption that this state will persist forever. I don't build my security strategies around assumptions that good luck will last forever. We need to think about options. If a change is not necessary now, it is still useful to plan for what changes will be needed when the situation changes. Currently, lists have an outsized impact on network security. Education organizations participate in lists. Lists make participant organizations unwilling to enforce DMARC. As a result, spammers know that universities are widely respected and easily spoofed, so those domains become weapons. Those attacks affect organizations who do participate in DMARC and do not participate in lists. So there are ethical issues around the status quo. In the end, it is a power issue. As long as participants are willing to compromise security for list participation, the status quo can continue. I can accept the assertion that lists are not politically required to change right now. But I do want to break the assumption that their is no alternative other than to kill lists off. Doug Foster On Tue, Oct 5, 2021 at 10:17 AM Baptiste Carvello < [email protected]> wrote: > 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: <[email protected] <mailto:[email protected]>> > > 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 <[email protected] > > <mailto:[email protected]>> > > > > > > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
