[email protected] wrote in <176722007157.2374187.8571126947823683752@dt-datatracker-5656579b89-p6k4r>: ... |Name: draft-nurpmeso-dkim-access-control-diff-changes |Revision: 10 |Title: DKIM Access Control and Differential Changes |Date: 2025-12-31 |Group: dkim |Pages: 29 |URL: https://www.ietf.org/archive/id/draft-nurpmeso-dkim-access-con\ |trol-diff-changes-10.txt |Status: https://datatracker.ietf.org/doc/draft-nurpmeso-dkim-access-co\ |ntrol-diff-changes/ |HTML: https://www.ietf.org/archive/id/draft-nurpmeso-dkim-access-con\ |trol-diff-changes-10.html |HTMLized: https://datatracker.ietf.org/doc/html/draft-nurpmeso-dkim-acce\ |ss-control-diff-changes |Diff: https://author-tools.ietf.org/iddiff?url2=draft-nurpmeso-dkim-\ |access-control-diff-changes-10
My likely very last iteration of this draft. - It adds "ianarev", as posted here. - It clarifies certain patch aspects. - It changes LZMA2 algorithm to bzip2, as that has the much superior semantics for this purpose; also, for example, the heavyweight (also) FOSS IMAP server dovecot obsoleted LZMA2, but kept bzip2. In S-bsdipa tests the compressions is much faster and better, eg, for the DKIM/ACDC email purpose it is even preferred. Also the library is smaller. |Abstract: In general, compared to the approach that all the acting email specialists present on this list are pushing forward: - Does not put constraints on the base protocol (SMTP). - Does not put constraints nor does it per se mutilate any other known protocol. For example, "--hidden-recipient" as of GnuPG, or Saltpack, another "modern crypto messaging format", etc, will not get corrupted aka compromised by DKIM/ACDC. - Does not introduce administration / configuration constraints. For example, the compromisation noted last could become circumvented *a little bit* if an administrator enforces single recipient mode. She or he has to choose: compromisation, or not. - The programmatical difficulties are on the lower end. A simple implementation with minimal complexity is possible. - There is a proven FOSS implementation that generates the necessary patch format available; it uses a proven and heavily used differential algorithm, BSDiff, for generating the actual differential data. - Is easy to splice into already existing codebases, as it builds upon DKIM v1, while fixing all the security biases that are to be fixed, and introducing a cryptographically safe chain of signatures. Plus mitigations. I abbreviate, you know all that. + That is to say, DKIM/ACDC ensures Freedom and Security of the protocol, the administrators, end users, and programmers. + That is to say, it is irresponsible to follow the other road. It is simply very bad design, from a to z. (Imho.) + That does not mean that the road presented here is the only valid, wonderful, final thing. ++ One should contact mailman authors so they act smarter regarding already present MIME encoding. And minimize reencoding. | This document specifies a DKIM (RFC 6376) extension that allows | cryptographic verification of SMTP (RFC 5321) envelope data, of any | DKIM signature along the message path, even beyond IMF (RFC 5322) | message content changes. It therefore addresses security glitches, | and introduces a new world of email solutions that move complexity | away from lower network layers, where problems cannot be solved, | complying with David Wheeler's fundamental theorem of software | engineering, that "We can solve any problem by introducing an extra | level of indirection". It updates DKIM to obsolete certain aspects | that reality has proven to be superfluous, incomplete, or obsoleted. Greetings, a happy and healthy new year to everyone reading this, and Ciao! from Germany, Hasta la Victoria siempre! --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]
