On Tue, Apr 29, 2025, at 14:20, Alessandro Vesely wrote: > On Mon 28/Apr/2025 22:41:03 +0200 Bron Gondwana wrote: > > On Mon, Apr 28, 2025, at 15:37, Tero Kivinen wrote: > >> Bron Gondwana writes: > >>> [...] > >>> > >>> With DKIM2, the second message would have on its copy from me: > >>> > >>> DKIM2-Signature: i=1; [email protected]; [email protected]; > >>> d= > >>> fastmailteam.com > >>> > >>> And then on its copies from the mailing list: > >>> > >>> DKIM2-Signature: i=2; [email protected]; [email protected]; > >>> d=ietf.org > >>> DKIM2-Signature: i=2; [email protected]; [email protected]; > >>> d=ietf.org > >>> DKIM2-Signature: i=2; [email protected]; > >>> [email protected]; d=ietf.org > >>> > >>> etc. Each with a separate signature, so they would be clearly not just a > >>> replay of a single message which was directed at the mailing list. > > > I'm not clear about the logic by which we can assume that IETF MLs will > promptly adopt DKIM2 but will ignore DKOR. Since DKOR is much simpler, it > sounds more likely people will adopt it more quickly than DKIM2. >
Unless I mis-understood it, DKOR wouldn't be applied by the IETF MLs because they aren't the initiator of the message. DKOR is very lightly specified, so I may have misread that. Certainly the IETF list is not currently adding a DKIM signature. This message that I am replying to has a single DKIM-Signature header field, with `d=tata.it`. > >> [... cost discussion elided ...] > > >>> Even more importantly, they would have delta header fields: > >>> > >>> DKIM2-Delta-Header: i=2; > >>> > >>> b=Content-Type,bXVsdGlwYXJ0L2FsdGVybmF0aXZlOyBib3VuZGFyeT0iXy0tLS0tLS0tLS09XzE3MjkwMDgzODQzMTE0NjAi; > >>> t=Reply-To; > >>> t=Subject,Re: [Ietf-dkim] Re: Fwd: New Version > >>> Notification for draft-crocker-dkor-00.txt; > >>> t=To,[email protected] > >>> DKIM2-Delta-Body: i=2; > >>> c=126-5231 > >>> > >>> Which would allow the gmail server to tell, if it didn't like content of > >>> the > >>> message, whether the badness had been introduced by the IETF server, or > >>> was > >>> present in the original message from me. And it could validate the first > >>> DKIM2-Signature (i=1) to be sure that the bad content had come from > >>> Fastmail's > >>> server. > >> > >> I do not know how gmail will know whether the changes done by the IETF > >> list was done in bad actor manner or not even if it has the diff of > >> changes the IETF mailing list does. > > > > Neither do I. Yet somehow, people can feed a message into a "is this > > spammy" AI or regex or human, and get an answer. They could do this with > > the previous version as well, and see if the answer was similar. Sure this > > is an imperfect science. > > > If the user says it's spam, how would the AI or human decide whether what > hurt > was in the added part or in the original one? Attributing responsibility to > either signer requires that recognition. As I said in the quoted bit above "I don't know", but I am quite confident that with that information available, it would be pretty trivial to tell. And people who do anti-abuse for pretty large systems seem to agree with me that this would be sufficient information for them. > > > [...] > > If 99% of the email that the IETF servers are generating is considered > > "unwanted" by Gmail's users, then its reputation is going into the toilet > > and its email isn't going to be reaching inboxes, regardless of whether > > it's just an update to remind them of the Notewell that the users all > > consider objectionable. > > > >> My guess is it depends on the recipient. Only recipient (the actual > >> user) can decide whether things changes done are over what he/she > >> expected. > > > > Yes, precisely. And in aggregate, that's the input signal that most email > > sites are using. There's no moral judgement of "good" or "bad" to > > particular content, it's a crowd-sourced reputation of whether users want > > it. > > > The reasoning is a bit different for mailing lists. If someone subscribes, > (s)he is committed to accept every message the ML forwards. If (s)he later > changes h{er,is} mind, (s)he unsubscribes. There is no option to block a > particular poster. People have to resort to local killfiles for that. > > So, besides it being difficult to tell the origin of what the user dislikes, > it > is also somewhat useless for mailing lists. I disagree with your analysis and your conclusions. That above commitment is an implementation detail. Lists often do filtering to try to avoid sending unwanted messages onwards, and mailbox filters often filter some content from mailing lists into Junk folders and other content from the same list into non-Junk folders based on their content. Fastmail allows you to "killfile" by creating a server-side filter. Many other mailbox providers do as well. > > > The value of a "DKIM Replay" attack, to a fair approximation, is in > > hijacking of reputation systems - which were built on DKIM (for good or > > ill). One of the largest values of DKIM2 (disclaimer about naming included > > by reference) is that it makes it much easier for reputation systems to > > distinguish said dishonesty. > > > >>>> Yours brings some benefit, but the overall benefit is trivial > >>> > >>> So, making it easy to detect DKIM Repaly is a trivial benefit? Wow. > >>> > >> If it detected DKIM Replay in the general case, it would not be trivial - > >> however it only detects DKIM Replay in the direct case. It's still not > >> possible to distinguish between an alumni forwarder and a DKIM replay; > >> short > >> of keeping a database of every alumni forwarder that points to you, and at > >> scale that's decidedly non-trivial. > > > If the alumni forwarder adopted DKOR, its signature would show MAIL-FROM: > [email protected] RCPT-TO: [email protected]. It seems to > me > DKIM2 is not going to provide much more info. Again, DKOR doesn't seem to provide that every hop does a signature. If it does, that's not much different from DKIM2; except that it allows for re-entry which means it has the same problems that ARC has, of re-injection. Alumni forwarders would either: a) be usable to launder DKIM replay messages, as they could receive a message with DKOR pointing to somewhere else and then add a new DKOR header; or b) would have to not add DKOR headers unless the source message DKOR was aligned - in which case the we're doing something much more like DKIM2 but without the delta support, and without the explicit n= headers to ensure ordering is correct. > What I'm concerned about, which is why I'd like to test DKOR before > endeavoring > in much more complicated stuff, is that telling whether the forwarding is > good > or bad is only based on reputation, an imperfect science. How do you anticipate that we "test DKOR"? > > >> Alumni forwarders etc are not set up by random people. For you to have > >> such forwarding means you actually are alumni of that place. So for > >> the final recipient of the email it is TRIVIAL to know what forwarders > >> he/she has that will forward email to his/her mailbox. > > > > Uh huh. > > > > I do actually somewhat buy this. And even the "it's trivial to know which > > mailing lists you are signed up to". > > > > But that information is only available at quite a distance and at scale > > that's a lot of manual fiddling. The SMTP server receiving an email and > > deciding whether to reject at SMTP time, or generate a delayed MDN later, > > or discard it - that's not the "final recipient" with their reliable recall > > of which addresses represent them. > > > >> So setting up for trusted ARC signers for the user is trivial for that > >> user, but impossible for anybody else. > >> > >> And note, that user might also have forwarding that he/she did not > >> request which he/she does not consider trusted, and whose ARC > >> signatures he/she does not want to be consider valid. > >> > >> Email forwardings does not happen randomly. The user sets up those > >> forwarders that he/she cares about. Adding that forwarder to the > >> trusted ARC signers list at the same time is easy task. > >> > >> And that is very scalable situation. I would assume most people have > >> only few (less than 5) alumni forwarding types of email forwardings. > >> > >> Mailing lists are different thing, I have no idea how many mailing > >> lists normal users are member of, but again they are something that > >> they know about themselfs, so when they join mailing list they can add > >> that as trusted ARC signer at the same time. > >> > >> The reason ARC has not been usable is that some people do think there > >> should be this "global trusted ARC signers list". This whole concept > >> of global list is wrong. I do not have any forwardings from > >> yahoo/hotmail/gmail etc to my final mailbox, so I do not trust ARC > >> signers of those domains, as they should not ever forward email to me. > >> For some other users things are different. > > > Hey, the above looks quite like my fix-forwarding draft. Has that been socialised with any of the big senders or receivers? It seems like something that could work, but the relationship maintenance and expiration of forwarding agreements over time becomes pretty unwieldy. Again, people don't generally manually fill forms. > > > What you are able to do as an individual with deep knowledge of the > > underlying tech is not scalable. Gmail, Yahoo, et al didn't do what you > > propose, and not because they're cretins who don't understand ARC. > > > > Or maybe they are cretins who don't understand ARC - I certainly am, But I > > understand regular users, and they sure aren't going to be manually adding > > a trusted ARC signer for every mailing list they sign up for. > > > One thing that mailing list subscribers can do is to pass a COI. The mailbox > provider can just run a second COI to confirm that that ARC signer is wanted > by > that recipient. (Yes, that's my fix-forwardin draft. Couldn't resist. > Sorry > for the OT.) I know there's some people working (not at IETF, at least not now/yet) on a way for the "COI" consent to be registered with the recipient mail system and given a token that is sent along with each message from the list, such that the user can also easily withdraw consent and the recipient system suppress or reject any messages from that list in future. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
