My attack model for this would be "bad-actor gets access to IMAP account and injects a message with a fake A-R header". This is actually slightly easier with JMAP which doesn't have as reliable an ordering-of-appends as IMAP with its monotonically increasing UID field[1].
The other way to smuggle fake AR is by attaching an email as a MESSAGE/RFC822 part to a larger mime message, "I got this email". It oould have the fake A-R along with non-validating, but legitimate looking headers for the content. And of course, when migrating email between servers, the A-R header was added by the server which first received the message. It doesn't (at least now) sign that A-R header. We could make DKIM2 require the receiving system to sign the message (with a terminus record: no rt=, so it's not going anywhere else) as it delivers it into the mailbox. This is not a crazy idea, and one that was in my initial plan for this protocol pre-charter and pre-draft-writing. Bron. [1] for good reason, it's much easier to work with an eventually-consistent store if you allow states to fork and merge! The algorithm we use for split-brain recovery for IMAP in Cyrus-IMAPD is to re-inject any messages which were appended during the split, giving them both newer, higher UIDs to ensure that clients which saw either state get back in sync. The alternative is bumping UIDVALIDITY. Either causes re-downloads, but bumping UIDVALIDITY causes more. On Sat, Aug 30, 2025, at 01:39, John R. Levine wrote: > On Fri, 29 Aug 2025, Phillip Tao wrote: > > 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. > > Since it's basically impossible to get mail into Yahoo without a DKIM > signature, and pretty hard into Google or Outlook, I would be surprised if > there was an interesting amount of unsigned mail. Perhaps we can ask > people we know at large providers what they see. How much do you see at > iCloud? > > There are millions of VPS with preinstalled MTAs that don't have any > authentication configured, but since they send close to no mail, I don't > see why we would care. > > 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] > -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
