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

Dave Crocker <> Sat, 10 February 2018 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F8A5128896 for <>; Sat, 10 Feb 2018 09:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=aP1+sa1W; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.b=kG6lEhwl
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wcZSuY7yd_C2 for <>; Sat, 10 Feb 2018 09:57:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DCC91200FC for <>; Sat, 10 Feb 2018 09:57:39 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1AHuk5g011713; Sat, 10 Feb 2018 09:56:46 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1518285408; bh=/T5cVokOCCi8G+TlzZBxzZvY9THFTrokAyOXRYss8Gk=; h=To:References:From:Date:In-Reply-To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=aP1+sa1W3ikGqbil50rw9WJe3s842h8iSeA8lVfURSS1Y3fNW3vB2P9wSqRKaYcvI Sg+uYSFp0Uw8jbznGuqywr0J07u8WO++kq2J3dl1Mepf1j8WttAa+/LBUfIP7OJ2yw 3IAtPLnNAJGlmF7rg0XOqd5WuZYs63iAq6Tt72BM=
Received: from [] ([]) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1AHuY9N011674 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Feb 2018 09:56:35 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1518285395; bh=S5WW2BZyE52EoT257uITmVl/Q2XpMGaUhczb5Q0MELE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kG6lEhwl6ETYsJR85QLCdE4cV/vK2CMMa2Hsf1ZatVpLyif2HQNq2mw5QdvKYggPD rt0IXXc4fZJGMLDMC0ta7+I0/EeN0lInUE39mjsFA6hhriRQe24cepxJv4bd45Qtg9 ALBbPpfSbZJbRemJ6viwsnCFKaMVYmf6LxYdz9UY=
To: John R Levine <>
References: <20180210155011.3735B1A7DD64@ary.qy> <> <alpine.OSX.2.21.1802101225020.58081@ary.qy>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Sat, 10 Feb 2018 09:55:31 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <alpine.OSX.2.21.1802101225020.58081@ary.qy>
Content-Language: en-US
Subject: Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?
X-Mailman-Version: 2.1.16
Precedence: list
List-Id: IETF DKIM Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: "ietf-dkim" <>

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:


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 

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 

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.


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