Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
Dilyan Palauzov <Dilyan.Palauzov@aegee.org> Mon, 20 August 2018 19:32 UTC
Return-Path: <Dilyan.Palauzov@aegee.org>
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 E31BA12F1A5 for <ietf-dkim@ietfa.amsl.com>; Mon, 20 Aug 2018 12:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org
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 FUiF3RpC6_12 for <ietf-dkim@ietfa.amsl.com>; Mon, 20 Aug 2018 12:32:09 -0700 (PDT)
Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 2816F128CF3 for <ietf-dkim@ietf.org>; Mon, 20 Aug 2018 12:32:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1534793527; i=dkim+sm-localhost@aegee.org; r=y; bh=P5nez5VY2S2B6WWDsSMir1c56hsqY4ydbwa9ZXC3npo=; h=Date:From:To:Subject:References:In-Reply-To; b=FUAzEWk4qNmN1YbFblWKJdNn9FRU84sIS8YNTQsgjMZ6JMWQ96k2KSgL8dXx3P10/ rZn2LAjYfMflyqAq8PdzSh/uSIfZx2+gfwKI+F52Qj+/pFsxZSgyRXt2GBdEjYkvER gFHr+q3nbftU7QIleqm3Viyu86UbLcR4b+JTF6Affos05Db1KKrDrCgMLb//oudifY FxlEUlErhsuCK24dfgrCicR4W5dAgDoHgTKei78qIvFqV6GH5dOz6t6RE0msviTDgV lJsRXaZAuucEqpAKRrk69aUDOnW814BFhieX67FlvYBEDxwOif5VlbTzJqCbV77hlw uobGjsoMYi3/9Rqu1ooDlQdg5+LjM2t2cwwnOSBZO4u49tCjoVm1BAqXvD+/OuKOKV 5zCX++1dTqnhwU04To+5Bv20YKabrSNqkcHh/jkNEW4lJ3eEfaCHnBX/UWgS19q6CP yIV9SbdMRntzPDVUgjtqlFWZx9IGXE625qIp/EnXEO8MAlDMWSI9eQ0i3RzlFqthry Hy99Zokah1TnHdF7fQXs6/OUwanyt/GUNTbyycYyjexv36X/96QkME6+5HVo3pytMm WRZaOjvGLjIf5YvRosJYxVe5/dCz3s1zQ4OZPVS/9U8zFwc0xKCHgQ7ehLk7dWA0E+ 16XxzWV1dF2+fVdnmo0AMRA8=
Authentication-Results: mail.aegee.org/w7KJW6PE009854; dkim=none
Received: from mail.aegee.org (localhost [127.0.0.1]) by mail.aegee.org (8.15.2/8.15.2) with ESMTP id w7KJW6PE009854 for <ietf-dkim@ietf.org>; Mon, 20 Aug 2018 19:32:06 GMT
Received: from c-76-102-151-26.hsd1.ca.comcast.net (c-76-102-151-26.hsd1.ca.comcast.net [76.102.151.26]) by webmail.aegee.org (Horde Framework) with HTTPS; Mon, 20 Aug 2018 19:32:06 +0000
Date: Mon, 20 Aug 2018 19:32:06 +0000
Message-ID: <20180820193206.Horde.U24zQJh_TH-uC-4hxrcs2fw@webmail.aegee.org>
From: Dilyan Palauzov <Dilyan.Palauzov@aegee.org>
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> <2c60b8bf-fec7-3a72-4bcc-3f2416e6f8b1@tana.it>
In-Reply-To: <2c60b8bf-fec7-3a72-4bcc-3f2416e6f8b1@tana.it>
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 mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-dkim/n1hUEGTdQGGsmPE-cz2t0TCrZ7k>
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 19:32:12 -0000
Hello, for fo=d is written: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment. DKIM- specific reporting is described in [AFRF-DKIM]. Once From: is rewritten by MLM, DKIM-Signature is preserved and does not align anymore, fo=d;ruf=mailto: will generate a report. How is fo=d different than having r=y? I want to get repors about failed DKIM validation only when the email was unintentionally modified, or sender and verifier are not implemented correct and use different logic to calculate the hashes. Do you suggest to include in RFC 7489bis (DMARC) everything from RFC 6651, except r=y and ADSP? Removing r=y from DKIM-Signature is indeed untrackable operation, but why should it be? DKIM-Signatures are partially self-signed, however I proposed to remove r=y only when DKIM-Signature is intentionally invalidated and in this case the signature is not damaged additionally by removing r=y. I do not insist on removing r=y from DKIM-Signature. I am looking for a way to get reports only when somebody unintentionally modifies an email. The reason for this is to have a system without unexplainable failures that makes it easy to fix broken DKIM signing/validating software. Repeating myself, when the aggregate reports show that 1% of the emails are signed wrongly, there is no way to debug the problem and fix. Before this fixed DMARC cannot be introduced, neither for incoming nor for outgoing mails. Some suggest to remove DKIM-Signature when the mail is modified intentionally (by MLM), mailman logic is to keep the invalidated DKIM-Signatures on their path to implement ARC I don't like the idea of sending reports about unaligned DKIM-Signatures (rewritten From: by MLM), as this allow a mailing list subscriber posting to the list to get a list of all subscribers, but the list of subscribers might be private. How about introducing fo=da for sending reports on failed DKIM-Signatures, only when they align? This is much like having r=a in DKIM-Signature that only sends reports, when From: aligns. This way, once an email is intenionally modifed, the modifying software is aware that DMARC will trigger and rewrite From: so no distracting reports will be sent. Greetings Дилян ----- Message from Alessandro Vesely <vesely@tana.it> --------- Date: Mon, 20 Aug 2018 11:31:09 +0200 From: Alessandro Vesely <vesely@tana.it> Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM To: ietf-dkim@ietf.org > 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 > -- > > > > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim ----- End message from Alessandro Vesely <vesely@tana.it> -----
- [Ietf-dkim] DKIM-Signature: r=y and MLM Dilyan Palauzov
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Alessandro Vesely
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Dilyan Palauzov
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Murray S. Kucherawy
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Murray S. Kucherawy
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Murray S. Kucherawy
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Dilyan Palauzov
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Murray S. Kucherawy
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Dilyan Palauzov
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Murray S. Kucherawy
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Brandon Long
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Alessandro Vesely
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Alessandro Vesely
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Dilyan Palauzov
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Дилян Палаузов
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Hector Santos
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Дилян Палаузов
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Дилян Палаузов
- Re: [Ietf-dkim] [dmarc-ietf] DKIM-Signature: r=y … Hector Santos
- Re: [Ietf-dkim] DKIM-Signature: r=y and MLM Hector Santos