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

Alessandro Vesely <vesely@tana.it> Mon, 20 August 2018 09:31 UTC

Return-Path: <vesely@tana.it>
X-Original-To: ietf-dkim@ietfa.amsl.com
Delivered-To: ietf-dkim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0865130F3F for <ietf-dkim@ietfa.amsl.com>; Mon, 20 Aug 2018 02:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 Sy5mYIFiIjSa for <ietf-dkim@ietfa.amsl.com>; Mon, 20 Aug 2018 02:31:12 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF10130DDE for <ietf-dkim@ietf.org>; Mon, 20 Aug 2018 02:31:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1534757470; bh=5qkH9JXk71fjGatiPOFUJ0x/By4i4XQlcUsE0/o/JPU=; l=1524; h=To:References:From:Date:In-Reply-To; b=B/F/rjLeGiiHfQEtGSUIDWxA/+KxM4uT/TC+DvUB8JCBSavesmubpnIkgnq1hAUvd wK2Pz2pJVnyKJFan2fhn1TI1BLzLRNrljrOaN25Os+84DXZFABKDISYl3Kv5fX4guT xQnbpBnuAFru5VmlbdkjU8cFlxVznag/J8B2+dTCP2jaW9jWXbsa34JeTJB8b
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 20 Aug 2018 11:31:10 +0200 id 00000000005DC086.000000005B7A8A5E.0000729F
To: ietf-dkim@ietf.org
References: <20180811033840.Horde.i6llD-AtvgzyNIjbhTs-nkS@webmail.aegee.org> <98aff90a-2198-854f-f1e6-85fd704cb7d1@tana.it> <20180817214834.Horde.DNYi60aPTo_sOKr7o3ilPra@webmail.aegee.org>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <2c60b8bf-fec7-3a72-4bcc-3f2416e6f8b1@tana.it>
Date: Mon, 20 Aug 2018 11:31:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180817214834.Horde.DNYi60aPTo_sOKr7o3ilPra@webmail.aegee.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/fUGKyF0iE6DmKPJj-qH4XHz4_Lg>
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
X-BeenThere: ietf-dkim@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DKIM List <ietf-dkim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-dkim>, <mailto:ietf-dkim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-dkim/>
List-Post: <mailto:ietf-dkim@ietf.org>
List-Help: <mailto:ietf-dkim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Aug 2018 09:31:13 -0000

Hi!

On Fri 17/Aug/2018 23:48:34 +0200 Dilyan Palauzov wrote:
> 
> I cannot provide very useful experience:

Thank you for the overview.  Albeit low-volume, it confirms my feeling that
rfc6651 is not widely adopted.

> [...]
>   - state explicitly that providers who want reports about mismatched
>     DKIM-Signature have to use p=reject;pct=0;fo=d;ruf=...

ruf= suffices.  p=reject;pct=0; is to force MLMs to rewrite From:, so as to
avoid useless reports.  However, what one deems useless could be interesting
for another; for example, one might use aggregate reports triggered by MLM
sending as a sort of delivery notification, thereby achieving a partial list of
subscribers' domains.  One-man-and-for-fun provider's subscription is easily
betrayed that way.


> Why shall software that knows r=y is old-fashion not remove it from
> DKIM-Signature:, in order to ensure that r=y is not interepreted later by
> software, that doesn't know r=y was moved to historic?

Let me recall that the DKIM-Signature header field is implicitly signed; that
is, if you alter it any way, it won't verify any more.  Removal of r=y would be
nearly impossible to undo, unless you know r=y was present and where exactly it
was placed.  Remove the whole field or rename it to, say, Old-DKIM-Signature.

BTW, some signatures are weak enough to survive boilerplate changes.  In that
case, the signer might be interested in verification failures even after MLM
changes.  How would you treat that instance?

Best
Ale
--