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 <ves...@tana.it> --------- > Date: Mon, 20 Aug 2018 11:31:09 +0200 > From: Alessandro Vesely <ves...@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 <ves...@tana.it> ----- > > > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim