In response to Ale's comment that we describe the mailing list problem without defining a path forward, I suggest the text below.
Doug Foster Some legitimate messages are sent on behalf of an individual account, based on an established relationship between the sender and the account owner, but without domain owner involvement, These messages are legitimate in the sense that the RFC5322.From address represents the true author, but the messages do not produce DMARC Pass because the sender does not have a DKIM private key from the domain owner. Mailing list messages are one example. We shall call these Special Senders. The mechanism which evaluators use to determine whether a message source should be classified as a Special Sender is outside the scope of this document. [ARC could be part of the process.] Once identified, an alternate authentication technique is needed to distinguish Special Senders from other sources, particularly malicious actors. To facilitate this alternate authentication, senders of such messages SHOULD use their own domain name for the Mail From address, and SHOULD apply a DKIM signature corresponding to the Mail From domain, and SHOULD ensure that the messages produce SPF Pass. When these identification measures are in place, the evaluator can authenticate the Special Sender, and use that identification to override DMARC Fail or DMARC No Policy. - For messages received directly, the evaluator detects the Special Sender's Mail From address or domain, and authenticates the message based on SPF Pass, aligned DKIM Pass, or both. Other message headers may also be used, specific to the situation, to ensure precise identification. - For messages received after secondary forwarding, but without Mail From rewrite, identification is based on the Mail From address and a verified DKIM signature aligned with the Mail From address. - For messages received after secondary forwarding and Mail From rewrite, authentication is more difficult. Before any message can be assigned Special Sender status, the evaluator must be able to detect that Special Sender status might apply. A DKIM signature for the Special Sender is the only verifiable identifier for this purpose. In most cases, the evaluator will need to use other message headers to supplement the DKIM signature as part of the Special Sender authentication, to ensure precise identification of the Special Sender messages. Alternatively, the evaluator may have reason to trust the secondary forwarder's authentication process, and accept the message on the basis of having been allowed through the secondary forwarder. On Wed, Apr 3, 2024 at 7:17 AM Alessandro Vesely <ves...@tana.it> wrote: > On 02/04/2024 20:16, Murray S. Kucherawy wrote: > > On Tue, Apr 2, 2024 at 9:01 AM Alessandro Vesely <ves...@tana.it> wrote: > > > >>>>>> By now, most mailing lists arranged to either rewrite From: or not > break > >>>>>> DKIM signatures. We all hope those hacks are temporary. > >>>>> > >>>>> What do you mean by "temporary", given the time scales that have > already > >>>>> passed since RFC 7489 saw wide deployment? Do you envision those > >>>>> techniques ending sometime soon? > >>>> > >>>> Yeah, the time scale is killing us. Is ten years soon enough? > >>> > >>> You tell me. You say you're hoping they're temporary, yet they've > been > >>> around a long time and I'm not sure that there's an alternative on the > >>> table. I'm asking you to explain. > >> > >> I believe alternatives are possible. Can't say how long it's going > >> to take, but I presume when they are available, the nasty hacks > >> will slowly fade out.> > > So what are you suggesting should go in this document that's in WGLC? > > > Section 8.6 states the ML problem very well, but it says nothing about the > way forward. Section 5.8, cross referenced with 8.6, talks about "other > knowledge and analysis". Neither that is forward looking, as it seems to > suggest some kind of presently available, heuristic content analysis. > > Some sort of contract or agreement between sender and receiver seems to me > to be unavoidable if we want to leverage ARC without having a global domain > reputation system. We don't have a precise method to do that. We need to > experiment and standardize something to that extent, which I hope this WG > can do after publishing -bis. > > Meanwhile, we can mention ARC, in Section 5.8 (minimal text proposed in > another thread[*]). How much can we expand that? For example, can we > whisper something about the need to trust specific sealers for specific > streams? > > In Section 8.3 the draft says: > > 550 5.7.1 Email rejected per DMARC policy for example.com > > I guess it would be too much to say: > > 550-5.7.1 Email rejected per DMARC policy for example.com, > 550-5.7.1 ARC seal by forwarder.example verified but not trusted. > 550 5.7.1 See https://receiver.example/arc-streams-registration/ > > Wouldn't it? > > > Best > Ale > -- > > [*] > https://mailarchive.ietf.org/arch/msg/dmarc/1aPplXPF1cYpnRzYHgxsTCPPzHg > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
