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.
[... 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.
[...]
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.
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.
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.
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.
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.)
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
