Oh. This was now automatically going to here.. So, my last mail...
[email protected] wrote in <175380366215.85995.2552626881067414879@dt-datatracker-5bd446d5fd-c47nq>: |Internet-Draft draft-nurpmeso-dkim-access-control-diff-changes-07.txt \ |is now |available. It is a work item of the Domain Keys Identified Mail (DKIM) \ |WG of |the IETF. | | Title: DKIM Access Control and Differential Changes | Author: Steffen Nurpmeso | Name: draft-nurpmeso-dkim-access-control-diff-changes-07.txt | Pages: 26 | Dates: 2025-07-29 ...and only to remark several things related to this draft, as i had edited it once more compared to what i had posted on the 21st. . Since it then likely will be "DKIM3", we could do some things differently, like abbreviating certain standard header names. (Unfortunately i had forgotten to include NAME/NUMBER syntax;) . It includes the "hash adaptivity" ("hash-alg" is only used to produce the "body-hash", whereas the input formerly used to create the "data-hash" is fed in full into "sig-alg", instead of to "hash-alg"), as a draft expiry notice flew by and then the change is only a single line, anyway. . As i had a little time to think i had to change the way DKIM-AC: is used in non-mutual-agreement situations. I for one cannot take the responsibility to reveal SMTP envelope data beyond the direct sender->recipient message path. (Not to talk about beyond what RFC 3461 calls "final delivery", and Mr. Crocker described -- as i now seem to know, this was not ironic, however -- as "stark indication".) Therefore in such situations only the recipient host (which is incapable to do anything with the header anyway) is in clear text, but the MAIL FROM and all the recipients reside in an encrypted storage. It is mostly for bouncing thus. And to protect a little bit against replay, as any other recipient is capable to at least detect it is not the indicated recipient domain. This is TODO (i added a few of those). But, and also as all other parts of the IETF i know try to hide practically "all socket connection information", adding what can definitely be seen as an active tracking capability (especially for anything beyond what RFC 3461 calls "final delivery" -- why never a discussion arose around that reality and on this list plain escapes me!) is totally beyond what i personally can accept. And since this draft will now rot in the IETF archives, until *maybe* someone stumbles upon it, she or he stumbling should not think that i revealed more than absolutely necessary. . Btw alongside this i discovered the noticed "Bcc" and adjusted the sentence accordingly. Thanks! So that it is for me. Ciao! and greetings from (pretty gray, but, as Gwildis from the North sang, "Nur hier Zuhause gibt es dieses wunderschöne Grau", only here at home there is this beautiful gray) Germany, --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) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
