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
- [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