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

Dave Crocker <> Sat, 10 February 2018 18:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D028012426E for <>; Sat, 10 Feb 2018 10:06:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=JnB4c1O/; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.b=o9UtzDKJ
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WOawYwuxStLt for <>; Sat, 10 Feb 2018 10:06:31 -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 3E4301200FC for <>; Sat, 10 Feb 2018 10:06:31 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1AI5tu9013106; Sat, 10 Feb 2018 10:05:56 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1518285958; bh=v2HN0o8fGSQmKDcgCsKVClvxbJ5QtliJfm9oxsqeAuI=; h=To:References:From:Date:In-Reply-To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=JnB4c1O/LZBfga7jGF8IF4ghgRNb1ik1lgYRgCSCcotXeZkSuBn0QmPQvwFi7Rtze Z8ftPkSYlgdw0WBxHdZQRp/X5k2SpyLonIV0yX6IhSX+nTJyja05WFnXgTx6PUxBax 1Ucig6coZkyGNYwun6UBvW2Ew4PcFRVX6RuATYA4=
Received: from [] ([]) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w1AI5qQt013083 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Feb 2018 10:05:53 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1518285953; bh=0xIwKIXNwZgpkfY2SROmocoN3FrR4E+UU2AGwFVk9LQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=o9UtzDKJ46mZFwnLH4cqjgAID6x4+bP+HLyFaxxmG1o46gQiuIxPCs1x+6Gllrzjb FMQ01c/AUiVV4LZ0U2O9ILMn3hhpNfp3dPS/SS+X3xSjC7W8IFDd9uJTA6h68nkPQv YI0E+iReUrsXYZmtIDdbMoEhFlDJvOI/Ol5Pjtko=
To: John R Levine <>
References: <20180210155011.3735B1A7DD64@ary.qy> <> <alpine.OSX.2.21.1802101244340.58081@ary.qy>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Sat, 10 Feb 2018 10:04:49 -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.1802101244340.58081@ary.qy>
Content-Language: en-US
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" <>

On 2/10/2018 9:47 AM, John R Levine wrote:
>>>     v= word (, word)*
>>>  where each word describes a semantic feature.  Feature tag "1" is all
>>>  the stuff in RFC6376.  My feature is mandatory to understand tags,
>>>  feature name "mandatory", so the signatures start
>> The listing of 'authorized' features ...
> Sorry, stop there.  This isn't "authorized" features, this is "used" 

fine, but that doesn't change any of the rest of my commentary about 
unilateral vs. 'negotiated'.

> features, as in if you don't support this feature, don't use this 
> signature.
>> In a unilateral activity like DKIM, the mere presence of the usage 
>> "featurex=..." serves to flag that featurex is used.  There is no 
>> incremental benefit into moving the flag elsehwere.
> Well, OK, other than DKIM-Improved-Signature how would you do 
> conditional signatures, where the signature has to fail if the semantics 
> of the re-sign tag aren't satisified?  Remember that the current rule is 
> that verifiers ignore tags they don't understand.

The current point of departure into DKIM is by the header field name. 
So I'm not sure why 'other than' is being queried, since it's the 
natural, existing point for going to a different protocol.

Different protocol?  Yes.  Current DKIM does not require support for 
unrecognized tags, beyond the initial set.  You want to require support 
for additional tags.  That's a fundamental change; so it isn't 'DKIM'. 
It's something different.


Dave Crocker
Brandenburg InternetWorking
NOTE WELL: This list operates according to