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

Дилян Палаузов <dilyan.palauzov@aegee.org> Wed, 10 October 2018 09:11 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 074FB130E9E for <ietf-dkim@ietfa.amsl.com>; Wed, 10 Oct 2018 02:11:53 -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 SvOUayGhiUFY for <ietf-dkim@ietfa.amsl.com>; Wed, 10 Oct 2018 02:11:50 -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 6C989130EA2 for <ietf-dkim@ietf.org>; Wed, 10 Oct 2018 02:11:49 -0700 (PDT)
Authentication-Results: mail.aegee.org/w9A9Bjjb025730; auth=pass (LOGIN) smtp.auth=didopalauzov@AEGEE.ORG
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1539162707; i=dkim+MSA-tls@aegee.org; r=y; bh=o9zSO7TChFiRniLsharvGJBfL1ojA0zjyU1ju2GsHuw=; h=Subject:From:To:Date:In-Reply-To:References; b=nj1fykm1Sy/6qWk1QX2rEUwyDm9czUFPhc7ZaJoSpg81sA6mNyy3+E59uHq9cM+pW m2XKNjOrv9NtrwzWAQLTNf+9ZSm+3tSnGS7fBaU1j4fk0ojkqHVXbAL+hLC21IujT3 lAEIn9zQ2E9DPRxnA8w50ZUtHs9Ebj13iQY3pceg0Hoo8IJ5JmUOfrQ6h15IuGmk4+ uPYEJ+oHaLIjjZXYCiT8U2gfOKJst0BXLeYKcuEPpS8b/Nki7XJuFtz72ynqI+VZr2 gssI61iFxANXp0vVb6/1N9dw2lHIVymu7kI59uZO55jKzYayNxQnaJs+Rx5NUNTixq T2XlLvjklUvoYstsK65Cep9vq5BpKoJJurm15e/QnsLlxD7M5KSj1Elfs/T3XyG2nr jBD98CSxcJbQ6updzh2eE8tR8jDnjsxpl8PPzi5dDayXodAn6Yq8lhJgkYtbJUqQ33 BNLkKkVy3APHcUex3b3GTeh8rUoD7Cl+HaGwS+kPDIcqGPsBuAnFQzrs31Zycutepv hL1NGePW8XPJiIc1vnGvEt7eD7xp/uaZNjGVLVSEO3M8fJf95uJVpqh5XuNn6kqTmb AsPdMQdgkhjqbLMrRVWplOAhJzNheuepBAKyE4Ylb3V0NP8UfWnnDzom5g0i8zJguQ gNzGsdCvH0/Mv/CryRo9fOjk=
Authentication-Results: mail.aegee.org/w9A9Bjjb025730; dkim=none
Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id w9A9Bjjb025730 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <ietf-dkim@ietf.org>; Wed, 10 Oct 2018 09:11:46 GMT
Message-ID: <6e31890d3b63091a1d731fd70c2bfc217dc4f45b.camel@aegee.org>
From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= <dilyan.palauzov@aegee.org>
To: ietf-dkim@ietf.org
Date: Wed, 10 Oct 2018 09:11:45 +0000
In-Reply-To: <20180820193206.Horde.U24zQJh_TH-uC-4hxrcs2fw@webmail.aegee.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> <20180820193206.Horde.U24zQJh_TH-uC-4hxrcs2fw@webmail.aegee.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.31.2
Mime-Version: 1.0
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/yr3ZuDMndHXz_VNpD94y1RtVcgg>
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
X-BeenThere: ietf-dkim@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 10 Oct 2018 09:11:53 -0000

Hello,

no feedbach means either everyboby agrees, nobody understands, or
nobody cares.

I suggested introducing 
* fo=da in DMARC’s TXT [https://tools.ietf.org/html/rfc7489#section-6.3
] for sending reports on failed DKIM-Signatures, only when they align,
and
* introducing r=a in DKIM-Signature [
https://tools.ietf.org/html/rfc6651#section-3.2] that only sends
reports, when From: aligns.

Greetings
  Дилян


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.



On Mon, 2018-08-20 at 19:32 +0000, Dilyan Palauzov wrote:
> 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 mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim