IETF Logo Mail Archive

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

Michael Thomas <mike@mtcc.com> Mon, 12 February 2018 01:56 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 B62671270FC for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Sun, 11 Feb 2018 17:56:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level:
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 eCbN84ILsFyb for <ietfarch-ietf-dkim-archive@ietfa.amsl.com>; Sun, 11 Feb 2018 17:56:39 -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 D2D36126E64 for <ietf-dkim-archive@ietf.org>; Sun, 11 Feb 2018 17:56:38 -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 w1C1tjrb030024; Sun, 11 Feb 2018 17:55:45 -0800
Authentication-Results: simon.songbird.com; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral
Received: from takifugu.mtcc.com (mtcc.com [50.0.18.224]) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1C1tfZp030017 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <ietf-dkim@mipassoc.org>; Sun, 11 Feb 2018 17:55:43 -0800
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by takifugu.mtcc.com (8.15.2/8.14.7) with ESMTPSA id w1C1scXP008481 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 11 Feb 2018 17:54:38 -0800
To: Dave Crocker <dcrocker@bbiw.net>, ietf-dkim@mipassoc.org
References: <20180210155011.3735B1A7DD64@ary.qy> <47dd136e-e122-9bd2-8cf1-7a712770d930@bbiw.net> <alpine.OSX.2.21.1802101244340.58081@ary.qy> <151740cf-796e-16eb-2ef5-ca296b5d4af0@bbiw.net> <84d515c0-7c76-232d-464f-3215db00d14d@mtcc.com> <e561d00e-d313-e700-77ff-6ead65a37bc9@bbiw.net> <3912f0ba-0b17-24f5-75ec-38f7465a45b6@mtcc.com> <ff024002-0f7b-8987-fad2-408adb31d8e4@bbiw.net>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <e7612811-e876-ea21-f072-46d200e89159@mtcc.com>
Date: Sun, 11 Feb 2018 17:54:38 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <ff024002-0f7b-8987-fad2-408adb31d8e4@bbiw.net>
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 02/11/2018 05:46 PM, Dave Crocker wrote:
> On 2/10/2018 10:47 AM, Michael Thomas wrote:
>> But I still think this entire conversation is silly in its 
>> theoreticality.
>
>
> Extra design complexity and consuming development resources -- 
> programming, bench testing, interoperability testing -- for something 
> that is not essential, nevermind offers no actual value, is about as 
> practical as any standards issue can get.
>
> Protocol complexity matters, especially for features that have no 
> immediate use.
>
> d/
>
You guys have already spent 10 times the amount of effort prattling on 
about these theoretical differences than any amount
of supposed savings for us poor, poor programming types. You clearly 
have no idea what you are talking about.

Mike

_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

v2.23.0 | Report a Bug | By Email