Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?
"John R Levine" <johnl@iecc.com> Sat, 10 February 2018 17:46 UTC
Return-Path: <ietf-dkim-bounces@mipassoc.org>
X-Original-To: ietfarch-ietf-dkim-archive@ietfa.amsl.com
Delivered-To: ietfarch-ietf-dkim-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20834126B72 for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Sat, 10 Feb 2018 09:46:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KtdHd6BwDWN for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Sat, 10 Feb 2018 09:46:19 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37911200FC for <ietf-dkim-archive@ietf.org>; Sat, 10 Feb 2018 09:46:18 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [127.0.0.1]) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1AHjIFK011111; Sat, 10 Feb 2018 09:45:19 -0800
Authentication-Results: simon.songbird.com; dkim=fail reason="verification failed; unprotected key" header.d=iecc.com header.i=@iecc.com header.b=d4bmEd4v; dkim-adsp=none (unprotected policy); dkim-atps=neutral
Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by simon.songbird.com (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 <ietf-dkim@mipassoc.org>; 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; d=iecc.com; 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 imap.iecc.com ([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: Sat, 10 Feb 2018 12:44:14 -0500
Message-ID: <alpine.OSX.2.21.1802101225020.58081@ary.qy>
From: John R Levine <johnl@iecc.com>
To: Dave Crocker <dcrocker@bbiw.net>
In-Reply-To: <c116be23-0e65-a1f8-3e08-0d0470b5006b@bbiw.net>
References: <20180210155011.3735B1A7DD64@ary.qy> <c116be23-0e65-a1f8-3e08-0d0470b5006b@bbiw.net>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.16
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/options/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim/>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: ietf-dkim-bounces@mipassoc.org
Sender: ietf-dkim <ietf-dkim-bounces@mipassoc.org>
> 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 doesn't. 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. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
- [ietf-dkim] Where is the formal definition of DKI… Alessandro Vesely
- Re: [ietf-dkim] Where is the formal definition of… John R. Levine
- Re: [ietf-dkim] Where is the formal definition of… John R. Levine
- Re: [ietf-dkim] Where is the formal definition of… Murray S. Kucherawy
- Re: [ietf-dkim] Where is the formal definition of… Dave Crocker
- Re: [ietf-dkim] Where is the formal definition of… John R. Levine
- Re: [ietf-dkim] Where is the formal definition of… Dave Crocker
- Re: [ietf-dkim] Where is the formal definition of… Mark Delany
- Re: [ietf-dkim] Where is the formal definition of… Dave Crocker
- Re: [ietf-dkim] versions, Where is the formal def… John R. Levine
- Re: [ietf-dkim] versions, Where is the formal def… Dave Crocker
- Re: [ietf-dkim] versions, Where is the formal def… John R. Levine
- Re: [ietf-dkim] versions, Where is the formal def… Mark Delany
- Re: [ietf-dkim] versions, Where is the formal def… Dave Crocker
- Re: [ietf-dkim] Where is the formal definition of… HANSEN, TONY L
- Re: [ietf-dkim] versions, Where is the formal def… John R. Levine
- Re: [ietf-dkim] versions, Where is the formal def… Dave Crocker
- Re: [ietf-dkim] versions, Where is the formal def… John R. Levine
- Re: [ietf-dkim] versions, Where is the formal def… Dave Crocker
- Re: [ietf-dkim] versions, Where is the formal def… Dave Crocker
- Re: [ietf-dkim] versions, Where is the formal def… Mark Delany
- Re: [ietf-dkim] versions, Where is the formal def… Michael Thomas
- Re: [ietf-dkim] versions, Where is the formal def… John Levine
- Re: [ietf-dkim] versions, Where is the formal def… Dave Crocker
- Re: [ietf-dkim] versions, Where is the formal def… Michael Thomas
- Re: [ietf-dkim] versions, Where is the formal def… Mark Delany
- Re: [ietf-dkim] versions, Where is the formal def… Dave Crocker
- Re: [ietf-dkim] versions, Where is the formal def… John R. Levine
- Re: [ietf-dkim] versions, Where is the formal def… Mark Delany
- Re: [ietf-dkim] versions, Where is the formal def… Alessandro Vesely
- Re: [ietf-dkim] versions of RFC822 mail messages,… John Levine
- Re: [ietf-dkim] versions of RFC822 mail messages,… John R. Levine
- Re: [ietf-dkim] versions, Where is the formal def… Dave Crocker
- Re: [ietf-dkim] versions of RFC822 mail messages,… Dave Crocker
- Re: [ietf-dkim] versions of RFC822 mail messages,… Dave Crocker
- Re: [ietf-dkim] versions of RFC822 mail messages,… John R Levine
- Re: [ietf-dkim] versions, Where is the formal def… John R. Levine
- Re: [ietf-dkim] versions of RFC822 mail messages,… Dave Crocker
- Re: [ietf-dkim] versions of RFC822 mail messages,… Dave Crocker
- Re: [ietf-dkim] versions of RFC822 mail messages,… Michael Thomas
- Re: [ietf-dkim] versions of RFC822 mail messages,… Dave Crocker
- Re: [ietf-dkim] versions of RFC822 mail messages,… Michael Thomas
- Re: [ietf-dkim] versions of RFC822 mail messages,… Dave Crocker
- Re: [ietf-dkim] versions of RFC822 mail messages,… Dave Crocker
- Re: [ietf-dkim] versions of RFC822 mail messages,… Michael Thomas
- Re: [ietf-dkim] versions of RFC822 mail messages,… Dave Crocker
- Re: [ietf-dkim] versions of RFC822 mail messages,… Michael Thomas