Richard Clayton wrote in <[email protected]>: |-----BEGIN PGP SIGNED MESSAGE----- |Hash: SHA1
Thank you. |In message <20260106225729.I9DzboY1@steffen%sdaoden.eu>, Steffen |Nurpmeso <[email protected]> writes | |>Btw your message made me very interested, so, for whatever |>interesting reason, i actually did reread the current drafts as |>mentioned on the DKIM WG internet side, .. and it turns out there |>is no z=? (It seems to have existed in the past, there.) | |z can now be found as a "recipe" under the r= and r.fieldname= tags It surely would be beneficial if https://datatracker.ietf.org/wg/dkim/about/ would give an impression of the desired DKIM2 as such. There is no linked draft that has these fields. No no no. If a TLS working group designs a new spec, it ends up with two endpoints negotiating, and agreeing therewith, or not. If they agree, by all means but software bugs or design misses, they have "embraced themselves", and know how to communicate++. May you say "MUST go single-recipient" "for Bcc" or not; yes, my posting to art@ regarding anonymity in ~"<msg sendmail -t 1@a 2@a 1@b .." is true even if it is no longer true from your point of view (deducing this standpoint from the newly read drafts). In the end you say DKIM2 headers "should be treated as trace fields", and anonymified transport be "single-recipient", and be fine with it. For maybe decades the IETF RFCs on SMTP were incomplete regarding practicably safe real-life SMTP MTA implementations, until Dave Crocker wrote RFC 9228 (building onto draft-duklev-deliveredto-01) on the Delivered-To: header field, of which i note it is classified as "Experimental", which is absurdely ludicrous. (To note that microsoft, google etc create likely encrypted headers en masse which surely serve some similar purpose.) So sorry, and i think i said that or something similar near the very beginning of all that development, "you" have no idea at all of the millions of software infrastructures as they exist down the road, and introduce something new that includes sensitive data! Until now, and for at least 27-8 years (postfix, qmail, draft-duklev-deliveredto-01 adds courier, delivered-to), or (at least) 21 years (exim, envelope-to), or 12 years (OpenSMTPD "released", delivered-to), people can strip trace headers "Received:", plus the mentioned, and have an anonymized email; except for all the things that certain software ejaculates into messages, the IETF newly invents and (unfortunately, uselessly) injects, and then the IETF ever comes over with more. Who gives you the guarantee that any downstream consumer applies "whitelists" instead of "blacklists" when "cleaning emails"? The mentioned draft (co-authored J. Levine btw) as well as RFC 9228 itself have "Security Considerations", and the latter says: As with Received: header fields, the presence of a Delivered-To: header field discloses handling information and, possibly, personal information. ... [.] Such a disclosure is likely to be unintended and might be (highly) problematic. Note that a basic version of this unintended disclosure has long existed, by virtue of a later recipient's seeing Received: header fields, but especially any with a 'for' clause. However, a Delivered-To: header field sequence can disclose significantly more recipient-specific handling detail. In my opinion no further security breach should come from the gremium which, well, specifies the at least "outer borders" within which email is handled. And RFC 9228 already should not have talked plenty on "disclosure"s, but have standardized encryption, because then there is no "disclosure". Look around .. microsoft, google, can third parties look into these headers? (Btw, Microsoft, why does X-Microsoft-Antispam-Message-Info: use QP encoding for base64 encoded data .. 5322 header lines can be continued simply by splitting and starting the next line with whitespace?) I mean ... hello??? That is just very bad! So no, i note i always had this "encryption" in my "vision"s of "a better DKIM" (aka "a DKIM that is *it*"), however bad it was / is. But you simply inject myriads of new things into that shit that email aka RFC 5322 IMF has become in reality. You should not do that. It is wrong. *Noone* invents new stuff that is like that. And it is not even for a "philosophical greater context", but it is for only technical data not to be seen as such by users -- no! Do it on mutual agreement, and encrypt sensitive data. Or without agreement, strip down sensitive data to an absolut minimum, to get the good things of the new proposal, and encrypt all the rest. It is noone but who can decrypt who has interest in what is encrypted, and the others can consciously and sufficiently act on only the rest. It is absolutely non-understandable why anyone from security related infrastructures agrees with the WG agreed drafts. I cannot help it. --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]
