Comments inline. - Phillip
> On Aug 29, 2025, at 3:49 PM, John R. Levine <[email protected]> wrote: > > On Fri, 29 Aug 2025, Phillip Tao wrote: >>> Can you explain why? This is exactly what A-R was made to do. >> >> The main issue with A-R results are that, for a MUA which is not limited to >> working with only a single mailbox provider controlled by the same >> organization, there's no (standardized/easy) way to establish trust that the >> A-R header was actually inserted by the MDA (i.e. section 7.1 of RFC 8601). > > I suspect I'm not the only one here who completely doesn't understand your > threat model. Someone has enough confidence in their mail provider to let it > send, receive, and archive mail, but not that it can remove old A-R headers > and add new ones? The user and the MUA are not the same party. The user is the one making the decision of which mail provider to trust and use. But they likely have no understanding of A-R headers. The MUA has no way to know whether the mail provider does or does not support DKIM, DMARC, or strip fraudulent A-R headers. Now, you could say that the MUA also has no way to know whether the mail provider correctly implements sending or receiving either, but I would argue that the difference is that those are core functions that have been defined and widely implemented for decades longer than either the DKIM or A-R RFCs have existed. As I'm sure you know, there is a very long tail of MTAs out in the wild. It's not unreasonable to imagine that there's a sizable portion of those which have not yet adopted DKIM or A-R headers. > > If you consider the entire mail system to be an unreliable and potentially > hostile channel, Unreliable, hostile, and "out-of-date" are all different issues. Different parts of the email system may also have different characteristics. Senders can definitely be hostile. The user's mail provider is significantly less likely to be hostile, but they may still not have adopted all the latest specs and best practices. > we have PGP and S/MIME, which put all the trust at the ends but which we also > know from long experience is unworkable outside of narrow niches because the > key management doesn't work. One of the reasons DKIM works is that the > granularity is the domain level which lets you have fewer keys that you > publish in the DNS. I agree. I don't think anything I'm proposing here changes who is publishing keys or how many keys they're publishing. I guess no. 1 in the original email was a little misleading. I'm specifically interested in the MUA as the verifier. The signing is still done by the sending domain. > > If you're going to do something like DKIM, the keys are under the control of > the domain which is presumably the same entity controlling the MTAs. > Who assigns and manages the keys? How do recipients get the keys with which > they are supposed to verify the messages? > > Regards, > John Levine, [email protected], Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
