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

"John R Levine" <> Sat, 10 February 2018 17:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20834126B72 for <>; Sat, 10 Feb 2018 09:46:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4KtdHd6BwDWN for <>; Sat, 10 Feb 2018 09:46:19 -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 E37911200FC for <>; Sat, 10 Feb 2018 09:46:18 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1AHjIFK011111; Sat, 10 Feb 2018 09:45:19 -0800
Authentication-Results:; dkim=fail reason="verification failed; unprotected key" header.b=d4bmEd4v; dkim-adsp=none (unprotected policy); dkim-atps=neutral
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1AHjEjp011077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <>; Sat, 10 Feb 2018 09:45:16 -0800
Received: (qmail 24329 invoked from network); 10 Feb 2018 17:44:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5f07.5a7f2f6f.k1802; bh=tcn2ByO0EX3xXd/Fw4RDitddlojPPT4f8OVtrj2JPi8=; b=d4bmEd4v9eYWNvglcdvZRYFI/rf6D8IrYLCj/DsVyJlg9QzKFG8dqoZjbut4WK+yN4wGsFFjQ1QGtdQ4UNEo3/SiLFVntU0JwwhcRfLdFTxiaVvhZPiPZ2Rxt/EfSUgYbAJZp+knb6R1b2ZEJa4lHNddVtezp1cEmmy0zeSOofmYufyWWdhqNW/D0f/WloCANOGZPVT6iiN6YR2SuMcwxVWMEoaUnbMFb8YMeI9pnMfDy+9ET7WwHot5guRyGZOJ
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 10 Feb 2018 17:44:15 -0000
Date: 10 Feb 2018 12:44:14 -0500
Message-ID: <alpine.OSX.2.21.1802101225020.58081@ary.qy>
From: "John R Levine" <>
To: "Dave Crocker" <>
In-Reply-To: <>
References: <20180210155011.3735B1A7DD64@ary.qy> <>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
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" <>

> 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).

If a message uses 8BITMIME, there are characters in the body that are
not ASCII.  It does not conform to RFC 822, it's a different format.
If you feed an 8BITMIME message to an RFC 822 mail system, random bad
things can happen, particularly back on PDP-10s where we stored five
7-bit characters in 36 bit words.

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

EAI adds another level of version, by redefining the address syntax so
domains can be U-labels, local parts can be any UTF-8, and most places
in mail headers that can contain text can be UTF-8.  Again, if you
feed one of these to a 5322 mail parser, even an 8BITMIME parser, it
won't work.  It's a new version of the message format.

In both cases the new versions are backward compatible with the old
versions, but so what?  They're not forward compatible, you need some
sort of version flag to avoid feeding new messages to old parsers.

John Levine,, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
NOTE WELL: This list operates according to