[Top] [All Lists]

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

2018-02-11 13:41:47
On 2/10/2018 9:59 AM, John R. Levine wrote:
MIME was in significant use quite a bit before ESMTP was operational. In fact it's a non-trivial feature that MIME only requires adoption by author and recipient and not by /any/ of the infrastructure.  IE, not by SMTP.

Yes, I know, but I wish you'd read what I've said about 8BITMIME.  It's an overlay that makes an INCOMPATIBLE CHANGE TO THE MESSAGE FORMAT, which is a version change in any world I know.

The problem is that you are conflating and/or missing some basic points, relative to my thesis, which is that a distinct 'version' flag is essentially never useful.

First, 8bitmime changes what is permitted for encoding, not basic 'format' or semantics. (For this discussion, that's a nit, but still...)

Second -- and really quite fundamental -- 8bitmime is a negotiated feature during an interactive session. The SMTP server gives the SMTP client permission to use it. DKIM is a unilateral mechanism: there's no interaction; there is no 'permission' to give. There is only signaling the fact of usage.

Third, 8bitmime is not a version flag, distinct from the protocol feature changes being changed, which is the point of this thread. It is the change itself. The signalling function, that there is a new feature -- ie, a different 'version', to employ your apparent usage of the term -- is implicit and integrated, rather than distinct and explicit.

Ditto EAI.

The SMTP extensions to support MIME characteristics are value-added, beyond the basic MIME capability.  In other words, they aren't necessary.

Well, sure, neither is DKIM, you could authenticate your mail some other way.  I don't understand what point you're making here.

That's not my point. DKIM won't work without... DKIM. SMTP /will/ work without the MIME extensions.

More generally, you have fallen into using the term 'version' for every specific enhancement. While that has linguistic validity, it does not have real-world relevance, with respect to a protocol 'version' parameter.

A version parameter is distinct from other syntactic and semantic aspects of the changes that are being signaled.

Dave Crocker
Brandenburg InternetWorking
NOTE WELL: This list operates according to

<Prev in Thread] Current Thread [Next in Thread>