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

[Dave Crocker <[e-mail]>]

On 2/10/2018 9:44 AM, John R Levine wrote:
>> Well, that's simply and completely false.
>>
>> The message format specification(s) have no dependency on the email 
>> transport mechanism.
> 
> Huh.  When I look at RFC 822, section 3.1 says:
> 
>       The  body  is simply a sequence of lines containing ASCII charac-
>       ters.  It is separated from the headers by a null line  (i.e.,  a
>       line with nothing preceding the CRLF).

MIME is an overlay, flagged by the presence of the either/both of:

    MIME-Version:
    Content-Type:

The fact that the first of these says 'version' is distracting, for the 
current discussion.  It's significance is to say that MIME is used for 
the body, but really that's redundant with the mere presence of 
Content-type.


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.

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


> By the time we get to RFC 5322, there is a paragraph of waffle in
> section 2.1 that says that non-ASCII stuff is described somewhere else
> and "Discussion of those mechanisms is not within the scope of this
> specification."  I suppose we can have a metaphysical argument about
> what you call something that exists but we pretend for now that it
> doesn't.

So?  Some non-normative text notes that there is some other 
specification(s) that you might want to look for.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html