IETF Logo Mail Archive

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

Alessandro Vesely <vesely@tana.it> Mon, 20 August 2018 09:23 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 E586F130F33 for <ietf-dkim@ietfa.amsl.com>; Mon, 20 Aug 2018 02:23:03 -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 Iks7f9x7q_oU for <ietf-dkim@ietfa.amsl.com>; Mon, 20 Aug 2018 02:23:03 -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 D8E5E130F32 for <Ietf-dkim@ietf.org>; Mon, 20 Aug 2018 02:23:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=gamma; t=1534756980; bh=3mFsRUNOhwHdAkZOuEouDLph2YPVO5Oys1QavhQhT4c=; l=771; h=To:Cc:References:From:Date:In-Reply-To; b=ArjMEK+ks/oKT8JKxmGEFTagR9KAC4vZT/lrvJXlKsAvZ/fvRdPBVeopzNRsJ0duu rbR9JaYoa7emXRbQN+f8MMy5syRXJ5Fj/9ytaz0l6F4mx8VodusrIFR8aTcDgzHqZm iXwjfebA9YMAXdXkd0HkaWcVliR4WZbUUxGAHjCyimE8nIznPI2Ct+idmtlW+
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:23:00 +0200 id 00000000005DC079.000000005B7A8874.0000719E
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: Ietf-dkim@ietf.org, Dilyan Palauzov <Dilyan.Palauzov@aegee.org>
References: <20180811033840.Horde.i6llD-AtvgzyNIjbhTs-nkS@webmail.aegee.org> <98aff90a-2198-854f-f1e6-85fd704cb7d1@tana.it> <CAL0qLwYBqUGT=xJQzBvHodJdAN1Z4_dPk0toeYHsJ_T-hMzghA@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: id=0A5B4BB141A53F7F55FC8CBCB6ACF44490D17C00
Message-ID: <fcf680bc-290b-ab3d-21e9-57e5a4ba8abc@tana.it>
Date: Mon, 20 Aug 2018 11:22:59 +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: <CAL0qLwYBqUGT=xJQzBvHodJdAN1Z4_dPk0toeYHsJ_T-hMzghA@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/sN7KReGPTVpym5eE4UK-pX3XKzs>
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:23:04 -0000

On Sat 18/Aug/2018 23:45:40 +0200 Murray S. Kucherawy wrote:
> 
> OpenDKIM still implements RFC6651 and finds it useful for debugging
> problems with new implementations, so at least from that perspective I
> don't think historical status for it is warranted.  If an update is needed
> to cover the issues raised here, that's possibly worth pursuing.

The difference w.r.t. DMARC is that it is the signer, not necessarily the
author's domain owner, who gets the report.  So, yes, rfc6651 has its own
worthiness.  The part related to ADSP, however, deserves to be demoted to Historic.

IMHO, updating rfc665{1,2} should be done after rfc7489bis, moving the format
definitions to the latter spec, for the reasons explained in my previous message.

Best
Ale
--

v2.23.0 | Report a Bug | By Email