Dave Crocker wrote in <[email protected]>: |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.
[This had to be removed on moderator request. It was a citation from a book that was very famous in Germany of the early 1980s, namely [the name: 1], but that is the 13th edition; my one was from 1983; the citation is about the lax handling on legal status in general at that time, with a film entry in the German Academy of Film [2], the "Seismografen politischer, kultureller und ästhetischer Strömungen" aka "seismograph of political, cultural, and aesthetic streams/trends".] By citating it i expressed my technical doubts whether it is viable to exclude matters of law in an upcoming standard, given that very influential "giant" companies started to exclude according information from their trace headers. In addition i want to point out that the moderator did block a message in the very distant past already, where i referred to the exclusion of mailing-list moderators from accessing their own list's member list on a -- by then -- very large public hoster of software (maybe it can be said, "the predecessor if github"), justifying this with the legal status of the moderators and your own country. I thought by then, and think still, that it is a matter of responsibility to take such matters into account. I think it is absolutely viable to at least express this thoughts. I think it is absolutely viable to place this in a cultural context of a time. [1] https://katalog.ub.uni-heidelberg.de/cgi-bin/titel.cgi?katkey476738 [2] https://dffb-archiv.de/dffb/legal-illegal-scheissegal |> - Not talking about the still missing necessary caches to protect |> against replay. | |I do not know what you are referring to. You leave it a quality of implementation aspect whether actual replay is detected, including what will be done about it. |> - 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. That i do not understand in turn. You either want all the world to change, like DKIM2. |> - It does not make technical sense to include SMTP envelope data |> beyond the "recipient hop". | |Then changes made during transit will not be detected. If the DKIM-Signature related to 5322.From does not cover the latest/only DKOR header, changes occurred. |> 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. If. The above means "sender domain" -> "hop 1" -> "hop 2" -> "recipient domain". In the modern email world hops do no longer exist. (That was the fun part. Of course.) |> 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. R is the recipient addressed by S. In this email, it is [email protected]. It is not an intermediary, in my case it even depends on the moderator, aka human interaction, which is quite a bit of work in today's world. Whether and how it goes on with the message, that is. |> 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. This is RFC 6377 etc etc. |> 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. I did not understand asynchronous bounces of (the version of) DKIM2 (that i read) either. DKOR does not understand the above. But ACDC uses flags to announce changes, for the SMTP envelope for example; it must, otherwise the cryptographic subsignature of the S domain must be present and verifiable. If a ML or alias expansion however changes the SMTP envelope, it has to remove the old, and create a new subsignature that covers the new envelope, and flag that situation. |> - *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. Yes. It does not address the problem at all. It cannot cryptographically verify any content change up to the original version as actually sent. That is easy, but regrettable. |> - It is technically false to claim that single-recipient is |> necessary. | |Please provide examples that provide similar benefits with multiple |envelope addressees. Not for DKOR. |> 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? RFC 5322, .. as above. [On moderator request i had to remove a personal address directed to the creator of DKOR.] .. DKOR only appears self sufficient and environment agnostic at first glance. Or, maybe, it is too "agnostic". DKIM uses DNS for its keys, is used in the 5321.SMTP protocol environment, and sits within 5322.IMF messages. And DKOR does not address the problems, at least not those i struggle with. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
