Alessandro Vesely wrote in <3aba29a1-e13c-4493-a71e-feb3f5b4c...@tana.it>: |On Mon 18/Nov/2024 18:53:11 +0100 Jim Fenton wrote: |> On 18 Nov 2024, at 9:23, Dave Crocker wrote: |>> On 11/17/2024 2:19 PM, Bron Gondwana wrote: |>>> Regarding the question of "is this DKIMbis or something bigger"? \ |>>> It's something bigger than just tweaks to DKIM. |>>> |>>> The choice of the name "DKIM2" is partially branding, and partially \ |>>> because it re-uses the existing DNS entries for DKIM keys and large \ |>>> parts of the signing infrastructure. |>> |>> |>> DKIM is not called DomainKeys2. |>> |>> "Using bits of" is not the same as "adding bits to". The new protocol \ |>> is not compatible with the old protocol, in spite of reusing some bits. |> |> I have been musing to myself that there might be ways to add fields \ |> to DKIM-Signature header fields in a way that would still be verifiable \ |> for existing DKIM verifiers but would provide additional functionality \ |> for DKIM2/DKIMbis/whatever. It isn’t clear to me that it can’t be \ |> backwards compatible. Whether it is desirable to just add another \ |> header field is a separate question. | |Some features a totally non-compatible (e.g. bounces), and difficult to |implement in a classical mail filter. (Dave's forecast of decades \
Hm, but /* $Id: milter-protocol.txt,v 1.6 2004/08/04 16:27:50 tvierling Exp $ (and surely even before that; .. wait ..; libmilter upon import of sendmail 8.11.0 to FreeBSD in Y2K, for example) already had built-in support for 4xx (SMFIR_TEMPFAIL), 5xx (SMFIR_REJECT) or free-form (?xx) via SMFIR_REPLYCODE; the RFC 3463 X(5).7.7 Message integrity failure i personally would like to see is extension, but SMFIR_REPLYCODE can be used by starting the "text" argument with an extended code and a space separator. It is unfortunate that SMTP, please let me add emailcore@, has several codes for disk full etc, but no possibility for a 5xx regarding failed authorization etc, so that people have to use "554" for *anything*. It is a real lack in a standard which now even seems to define that any MTA must have "deep disk redundance". But reject results in what i call "a bounce". So only regarding my personal usage of the word "bounce" i apologise for being misunderstood shall anyone have misinterpreted it in any other way than "rejected via SMTP status plus 5.7.7 RFC 3463 addition. |is optimistic.) | |How about DKOM? DKIM explicitly says "Unrecognized tags MUST be ignored." and ditto for flags, so it should be possible -- talking about my thing about DKIM -- to embed the additional flags as well as a possible base64 encoded diff blob (trailer) without affecting existing verification. They just possibly verify too many signatures as before, and are incapable to unfold the blob. (I personally am all in favour of per-domain Subsignatures which are only created if the target domain announces a public key which can be used to encrypt the list of per-domain receivers.) --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) | |And in Fall, feel "The Dropbear Bard"s ball(s). | |The banded bear |without a care, |Banged on himself fore'er and e'er | |Farewell, dear collar bear _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
