Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

Dilyan Palauzov <> Sun, 19 August 2018 03:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6969B130F2C for <>; Sat, 18 Aug 2018 20:30:44 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (4096-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jbNRobP3xVFW for <>; Sat, 18 Aug 2018 20:30:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52AE9130EE4 for <>; Sat, 18 Aug 2018 20:30:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=k4096; t=1534649440;; r=y; bh=020HDxM8SiN/jcREwDK9myFtVn7xMK6RYS/5f+Jgcrg=; h=Date:From:To:Subject:References:In-Reply-To; b=IwwTCgnPF8bS6WYI7jGzZs73Nv7X7XMYRCKK6JQ8XCusJWvAubBsVjsT+/VqUPSQF J+JQPzsFuojlBfKuuAj6kJPREhhJsgeXkQxfEWgUv/nQ0QdHEo5XeEzJVKfviB6krz Gs2PLekVu2oRo9FprcauzuwX5yCdhZuPtf+jKcbaUXbtzpYv6/eiilhdFUzCrYcM/U 1wGhxWKoG7fr2v865LQMqCbQDLKkSQNnaB8U3wwH6CLqsfzziQzd7VBLVw8Rp5tkW3 7esK0MSSxTcaF/R3kBgu/cYfInvFb75UnaeVeLH/kvNfZ2d74wWE7QyzHfU6UO4DiG Xb467wmy27mu0WrhvGpSrmmUrCeLiWPKW83aSN/G2s+S4Dy0LXNHyduGWSnD7KX8hk 2Ipt/Y7dARG8GC1mPwif5vPqUaTpQdSOqReZhRtwB0c8fexLINhnPe+DmA7n2eiEIm uEwBwSKvdi0fjIVnJme3WNL3Zkt03Ncp8rSgkC2CSN76if2+EwQIusxqXUVXMq050N IVZZg6hX1T1MH5SzwQ3Dlu/o9A6mJEXwTf6WMOBHCqrk6Us4Gd9kvBYlzmLZPS29v4 ffjyO4b3vmnL2hDh9BayeRSHu4rPAwtPGgEFO+Q0m5LZfRfrGLSloDEsll474+UIZu 4HzvlLj4uWVsfZy70WPMhf5Q=
Authentication-Results:; dkim=none
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id w7J3Ue7U003711 for <>; Sun, 19 Aug 2018 03:30:40 GMT
Received: from ( []) by (Horde Framework) with HTTPS; Sun, 19 Aug 2018 03:30:40 +0000
Date: Sun, 19 Aug 2018 03:30:40 +0000
Message-ID: <>
From: Dilyan Palauzov <>
References: <> <>
In-Reply-To: <>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.100.1 at
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DKIM List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 Aug 2018 03:30:45 -0000


let's first agree on how to technically approach this and only  
afterwards concentrate on the target specification that needs  

What to do?

Two out of two responders were against removing r=y from the DKIM-Signature.

I am fine with removing the invalidated DKIM-Signatures, but mailman  
developers are not ( as  
this were incompable with ARC.

What about writing in ARC, which I have not read, to remove r=y,  
before handling DKIM-Signature:s?


----- Message from "Murray S. Kucherawy" <> ---------
    Date: Sat, 18 Aug 2018 15:02:35 -0700
    From: "Murray S. Kucherawy" <>
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
      To: Dilyan Palauzov <>

> On Fri, Aug 10, 2018 at 8:38 PM, Dilyan Palauzov <>
> wrote:
>> I suggest here in to suggest in a more formal manner, that MLMs modifying
>> a message are supposed to remove the r=y part of just invalidated
>> DKIM-Signature and this logic is also applied for ARC, if relevant (I don't
>> know ARC).  Fixing only ARC will not help, as there is software that
>> follows DKIM, but has no idea about ARC.
>> Is such a recommendation a good idea?
>> How to make the recomentation?  Amendment to RFC6377, amendment to RFC
>> 6651, something else, that is very short to compose?
> I think advising anyone to alter a signature on a message irrespective of
> the signature's validity will be hard to sell.  It would be simpler to just
> remove the signature entirely if there's a good reason not to want it there
> anymore.
> This unfortunately seems a rather small thing for which to spin up an
> update to either RFC6377 or RFC6651.  Are there any other things that have
> evolved since those documents were published that might make revisions
> worth doing?
> -MSK

----- End message from "Murray S. Kucherawy" <> -----