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

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