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

Dave Crocker <dcrocker@bbiw.net> Sun, 11 February 2018 19:42 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 ABC0D126B6E for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Sun, 11 Feb 2018 11:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbiw.net header.b=py2SDmwx; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=bbiw.net header.b=LGCV6WlS
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 VqFQHJYkLVBF for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Sun, 11 Feb 2018 11:41:58 -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 B98C912426E for <ietf-dkim-archive@ietf.org>; Sun, 11 Feb 2018 11:41:58 -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 w1BJelBb005594; Sun, 11 Feb 2018 11:40:48 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bbiw.net; s=default; t=1518378057; bh=Z6+jGIm+gKIojbbqsQV/bBHIMBN2MmBEBRDX8uxdjz4=; h=To:References:From:Date:In-Reply-To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=py2SDmwx/sMfIl36B4lpbeQdEcJZxvbj5ULWroJVrcay0hdkguEr43BcjSQmvhbR9 eomMKTuUQWXcGt/s30v4Idzr9WwVNtbmt4KkGwgvb5VbjRg//0kIu3Q/eL08Y9T+c7 /6uUy0j+kfeubGmQDKDi4+Ljpe5BL+jIczPOgQLw=
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1BJejs4005588 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 11 Feb 2018 11:40:45 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bbiw.net; s=default; t=1518378045; bh=tw/NFH3aeFKEzzNZa5EDkz5IUHK9AE+mYUOTtzWimjI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LGCV6WlShpXTlrH/IGWgEjTlS5WhzigimgMW+aE8WIxeCwQZhg/2qaojBGjbuDQiN k2rX4pKcb2GwiLFr1FdJejS/LVvAWABV55zyprQ1VbTVPBczlsPumqkblS7l4EqUkq axqoin894wSOClSMX42i7X1AwQv28cwfodz2Rm/M=
To: "John R. Levine" <johnl@iecc.com>
References: <20180210155011.3735B1A7DD64@ary.qy> <c116be23-0e65-a1f8-3e08-0d0470b5006b@bbiw.net> <alpine.OSX.2.21.1802101225020.58081@ary.qy> <4fed665f-75ae-b2be-7be4-1fd978528d29@bbiw.net> <alpine.OSX.2.21.1802101256580.58081@ary.qy>
From: Dave Crocker <dcrocker@bbiw.net>
Organization: Brandenburg InternetWorking
Message-ID: <9abd12a1-f467-ac9c-de60-82f6c673479b@bbiw.net>
Date: Sun, 11 Feb 2018 11:39:40 -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.1802101256580.58081@ary.qy>
Content-Language: en-US
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>

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.

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