On 5/28/2025 1:50 PM, Steffen Nurpmeso wrote:
I thought the language is fantastic. But the entire thing is
a technical problem that does not solve any.
- Not talking about sequence numbers not being linked etc. ...
I have not understood which (how many) existing DKOR headers
should be included in their signature.
All of them. (Yes, that needs to be added to the draft.)
- Not talking about legal state of permanently revealing RFC 5321
SMTP envelope data in the email RFC 5322 IMF message.
Legal? Matters of law are outside the scope of the specification.
- Not talking about the still missing necessary caches to protect
against replay.
I do not know what you are referring to.
- In the current email world, DKIM-Signature often get removed aka
mitigated away. Until covered (to be also removed) dangling
DKOR headers will remain. (Unusable since not cryptographically
verifiable.)
This means that sequence numbers cannot be trusted.
Knowing there is a missing signature is a pretty clear DKOR failure.
- It does not make technical sense to include SMTP envelope data
beyond the "recipient hop".
Then changes made during transit will not be detected.
In S->A->B->R, if R expands an
alias or is a MailingList that reposts, former SMTP envelope
data has nothing whatsoever to do with the message.
DKIM links a RFC 5322 message to a domain. In S->A->B->R none
of A and B are supposed to modify the message.
If A or B are intermediaries, they are free to make whatever changes
they want.
R may cause
changes (alias expansion, ML tags and header additions), and
then send the message further on.
Those are changes made by intermediaries, not the (final) receiving site.
DKIM v1 always failed that "next" message until the DKIM
covered part remains unchanged, or until R mitigates the IMF
From: header which DKIM v1 takes special interest in.
Anyhow, except for asynchrous alias bounces (huh???), no
former SMTP envelope makes sense to be included in that "next"
message since delivery problems at recipients addressed by the
"next" message can aka must only be reported to, and dealt
with by the domain which sent the "next" message.
I do not understand any of the above.
- *If* there is desire be able to "undo" an alias expansion
"later" to redirect the "bounce", VERP ("as via SRS") is the
much better, the *only* approach, compatible to anything, and
actually in real-life use for decades (via non-standardized
SRS), today even an absolutely necessary precondition to survive
RFC 7208 SPF checks.
This specification has nothing to do with undoing anything.
- It is technically false to claim that single-recipient is
necessary.
Please provide examples that provide similar benefits with multiple
envelope addressees.
It may be so *if* a dumb software creates
a signature "out in the blue". For example, in order not to
reveal Bcc recipients to the world.
Here i want to point out one thing. DKIM v1 as it is and you
propose unchanged for DKOR will look for the IMF From: content
but/and likely start multiple happy-eyeball caused DNS lookups
for multiple DKIM-Signatures.
IMF?
...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
