Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On 10/24/2018 4:53 PM, Дилян Палаузов wrote: PS: Please describe the handling, of the above message by the MLM, if the original message contained in addition DKIM-Signature: v=1; d=isdg.net; r=y; … ... or something different than r=y, that permits finding faulty DKIM implementations. Our DKIM implementation does not support this "r=y" tag. In general, per DKIM specification, all unknown DKIM-signature tags are ignored. <<< 554 REJECTED BY SYSTEM POLICY FILTER Last-Attempt-Date: Wed, 24 Oct 2018 20:32:15 GMT Off hand, it appears your IP address was filtered by a Geo IP Location database. This is done immediately at the connection level so we have limited SMTP session logs to look at. I'm contacting you off list. -- HLS ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
PS: > For example, the ietf.org mailing list has begun to rewrite and it > replaces the 5322.From with a dmarc.ietf.org domain, adds a new > X-Original-From header and resigns the message using an ietf.org > signer domain: > >DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; > s=ietf1; > t=1537415189; bh=TJWGUVdPL8OTY+HJnUzpBRd52OaKfWjFqS68Cby0s/M=; > h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: > List-Archive:List-Post:List-Help:List-Subscribe:From; > b=. > X-Original-From: Hector Santos > From: Hector Santos > > What it should do is: > >1) It should use a 1st party signature using d=dmarc.ietf.org to > match the new author domain dmarc.ietf.org. > >2) It should has hash bind the X-Original-From header to the > signature. Since DKIM recommends not to bind "X-" headers, > a non "X-" header should be used, i.e. "Original-From:". This > means adding the header to the 'h=" field to avoid potential > mail resend exploits using different unprotected Original-from: > fields. > >3) and finally, the dmarc.ietf.org domain should have its own > DMARC p=reject policy to effectively replace the one it > circumvented with the submission. > Please describe the handling, of the above message by the MLM, if the original message contained in addition DKIM-Signature: v=1; d=isdg.net; r=y; … ... or something different than r=y, that permits finding faulty DKIM implementations. Apart from this, on the last email I sent “To: Hector Santos < hsan...@isdg.net>, ietf-dkim@ietf.org” , I got: Date: Wed, 24 Oct 2018 20:32:15 GMT From: Mail Delivery Subsystem Message-Id: <201810242032.w9okwfsc027...@mail.aegee.org> Content-Type: multipart/report; report-type=delivery-status; boundary="w9OKWFSc027376.1540413135/mail.aegee.org" Content-Transfer-Encoding: 8bit Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --w9OKWFSc027376.1540413135/mail.aegee.org The original message was received at Wed, 24 Oct 2018 20:32:10 GMT from ipbcc2def0.dynamic.kabel-deutschland.de [188.194.222.240] - The following addresses had permanent fatal errors - (reason: 554 REJECTED BY SYSTEM POLICY FILTER) - Transcript of session follows - ... while talking to mail.isdg.net.: <<< 554 REJECTED BY SYSTEM POLICY FILTER 554 5.0.0 Service unavailable --w9OKWFSc027376.1540413135/mail.aegee.org Content-Type: message/delivery-status Reporting-MTA: dns; mail.aegee.org Received-From-MTA: DNS; ipbcc2def0.dynamic.kabel-deutschland.de Arrival-Date: Wed, 24 Oct 2018 20:32:10 GMT Final-Recipient: RFC822; hsan...@isdg.net Action: failed Status: 5.5.0 Diagnostic-Code: SMTP; 554 REJECTED BY SYSTEM POLICY FILTER Last-Attempt-Date: Wed, 24 Oct 2018 20:32:15 GMT ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On 10/10/2018 5:11 AM, Дилян Палаузов wrote: Hello, no feedbach means either everyboby agrees, nobody understands, or nobody cares. Generally, a bit of everything. I'm providing some comments because I am currently updating my DKIM ADSP/ATPS/DMARC implementation and need to take into account the MLM rewrite issue. 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. 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. I don't think we need a new DKIM-BASE DKIM-signature tag for what you want. This all starts with DKIM Policy (ADSP/DMARC) restrictive policies and receivers finally honoring them. This could be better done as a DMARC tag extension where it provides the MLM more DMARC mail handling information. For example, new DMARC tag extensions "rewrite=" and "fo=" rewrite=no default, rewriting SHOULD be avoided. rewrite=allow allow rewriting by domain with a p=none or no policy rewrite=strict allow rewriting by domain with a p=reject|quarantine policy fo=da send reports when rewriting is done Keep in mind that not every system will send reports. It is considered a high overhead with a high redundancy. Our implementation does not generate reports. Reporting adds a high barrier and technical implementation requirement. Reporting should be optional for implementation. Also keep in mind that the idea of "Rewriting" is not a "standard" concept. It is actually a long time mail engineering taboo to be destroying the originating author field for any mail platform, including RFC5322. Its a very sensitive design idea. Our MLM package does not rewrite. However, I am considering it now as a means to resolve the problem of errant DMARC/ADSP domains submitting public mailings using restrictive policies. I personally believe the DMARC/ADSP receiver can implement ATPS "Authorized Third-Party Signers" (RFC6541) but that didn't gain traction, so rewrite appears to be the only recourse.With more receivers now honoring the policies, it can cause a major havoc in a list subscription group. Since there are more MLM systems performing DMARC-based rewrites, I believe a better way to deal with this is for the MLM to reject the restrictive domain submission with an email response: "Sorry, your submission was prohibited due to a protected domain restrictive DMARC|ADSP policy." In fact, the MLM should stop all new subscriptions from domains using a restrictive policy. The rewrite should be the last thing to consider, and if it does rewrite, it should replace the original author domain strong policy with its own strong policy. For example, the ietf.org mailing list has begun to rewrite and it replaces the 5322.From with a dmarc.ietf.org domain, adds a new X-Original-From header and resigns the message using an ietf.org signer domain: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1537415189; bh=TJWGUVdPL8OTY+HJnUzpBRd52OaKfWjFqS68Cby0s/M=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From; b=. X-Original-From: Hector Santos From: Hector Santos What it should do is: 1) It should use a 1st party signature using d=dmarc.ietf.org to match the new author domain dmarc.ietf.org. 2) It should has hash bind the X-Original-From header to the signature. Since DKIM recommends not to bind "X-" headers, a non "X-" header should be used, i.e. "Original-From:". This means adding the header to the 'h=" field to avoid potential mail resend exploits using different unprotected Original-from: fields. 3) and finally, the dmarc.ietf.org domain should have its own DMARC p=reject policy to effectively replace the one it circumvented with the submission. With these measures, the original author domain will still be protected with a DMARC policy when the MLM rewrites. That's my idea of a better approach to it as oppose to a blind, unprotected rewrite. 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. Remember, not all systems will send a report. I personally think a MLM should be playing an more active role to protect against DMARC -- who can subscribe, who can submit mail. If the domain is restrictive, it is possible to maybe only allow READ-ONLY mode and/or add a user subscriber option that says: [_] Rewrite the From
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 +, 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 - > Date: Mon, 20 Aug 2018 11:31:09 +0200 > From: Alessandro Vesely > 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 y
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
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 - Date: Mon, 20 Aug 2018 11:31:09 +0200 From: Alessandro Vesely 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 - ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
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
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
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
--
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On Sat, Aug 18, 2018 at 10:42 PM, Dilyan Palauzov wrote: > I suggested to write in ARC to alter the existing signature. > As I said before, I suspect you will have a hard time selling an "alter the existing signature" idea no matter what document you propose to create or update. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On Sat, Aug 18, 2018 at 8:30 PM, Dilyan Palauzov wrote: > Two out of two responders were against removing r=y from the > DKIM-Signature. > > I am fine with removing the invalidated DKIM-Signatures, but mailman > developers are not (https://gitlab.com/mailman/mailman/issues/500) as > this were incompable with ARC. > > What about writing in ARC, which I have not read, to remove r=y, before > handling DKIM-Signature:s? > Do you mean for ARC to ignore "r=y"? Otherwise, isn't this again altering an existing signature, which consensus (so far) disagrees with? -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
Hello, let's first agree on how to technically approach this and only afterwards concentrate on the target specification that needs adjustments. What to do? Two out of two responders were against removing r=y from the DKIM-Signature. I am fine with removing the invalidated DKIM-Signatures, but mailman developers are not (https://gitlab.com/mailman/mailman/issues/500) as this were incompable with ARC. What about writing in ARC, which I have not read, to remove r=y, before handling DKIM-Signature:s? Regards Дилян - Message from "Murray S. Kucherawy" - Date: Sat, 18 Aug 2018 15:02:35 -0700 From: "Murray S. Kucherawy" Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM To: Dilyan Palauzov Cc: Ietf-dkim@ietf.org On Fri, Aug 10, 2018 at 8:38 PM, Dilyan Palauzov wrote: I suggest here in to suggest in a more formal manner, that MLMs modifying a message are supposed to remove the r=y part of just invalidated DKIM-Signature and this logic is also applied for ARC, if relevant (I don't know ARC). Fixing only ARC will not help, as there is software that follows DKIM, but has no idea about ARC. Is such a recommendation a good idea? How to make the recomentation? Amendment to RFC6377, amendment to RFC 6651, something else, that is very short to compose? I think advising anyone to alter a signature on a message irrespective of the signature's validity will be hard to sell. It would be simpler to just remove the signature entirely if there's a good reason not to want it there anymore. This unfortunately seems a rather small thing for which to spin up an update to either RFC6377 or RFC6651. Are there any other things that have evolved since those documents were published that might make revisions worth doing? -MSK - End message from "Murray S. Kucherawy" - ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On Fri, Aug 10, 2018 at 8:38 PM, Dilyan Palauzov wrote: > I suggest here in to suggest in a more formal manner, that MLMs modifying > a message are supposed to remove the r=y part of just invalidated > DKIM-Signature and this logic is also applied for ARC, if relevant (I don't > know ARC). Fixing only ARC will not help, as there is software that > follows DKIM, but has no idea about ARC. > > Is such a recommendation a good idea? > > How to make the recomentation? Amendment to RFC6377, amendment to RFC > 6651, something else, that is very short to compose? > I think advising anyone to alter a signature on a message irrespective of the signature's validity will be hard to sell. It would be simpler to just remove the signature entirely if there's a good reason not to want it there anymore. This unfortunately seems a rather small thing for which to spin up an update to either RFC6377 or RFC6651. Are there any other things that have evolved since those documents were published that might make revisions worth doing? -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
On Sat, Aug 18, 2018 at 2:45 PM, Murray S. Kucherawy wrote: > On Fri, Aug 17, 2018 at 4:15 AM, Alessandro Vesely wrote: > >> > The DKIM aggregate reports show whether a server signs correctly all >> mails or >> > not. If the aggregate reports show that this is sometimes (let's say >> in 1%) >> > not done correctly, the signer has no way to find for which email the >> signing >> > has not worked and cannot fix the signing software, unless a report for >> the >> > failing mail is sent with r=y. >> >> Well, nope. Aggregate reports belong to DMARC. Consider adding a rua= >> address >> to your DMARC record. Sometimes aggregate reports allow a postmaster to >> pin >> which message triggered it. If you also set a ruf= address, you might >> receive >> ARF reports as well. >> > > +1. > Actually, Dilyan is correct; RFC6651 introduced a reporting stream independent of DMARC. I've no data about how widely it's used outside of OpenDKIM, however, but it's not strictly a DMARC or ARC mechanism. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
Hello, I cannot provide very useful experience: - On r=y almost nobody sends such reports, except very tiny one-man-and-for-fun providers. - The server I run is used primary for incoming emails, users send mails From: the managed domain using other servers, and these emails do not have DKIM-Signature: r=y from my domain. So my conslusions are mainly about emails I send myself. It is about 3-10 emails per month. - The reports I get are sent either because the report-evaluator has bugs, because some MTA does illegal rewritings (like inserting newline in "From: me <1...@example.org>,you <2...@example.int>" between >, and you) , or because the mail was modified by a MLM. But checking each single report for the failure reason is too much time, and I prefer not get such reports, when the mails were intentionally modified. - The server manages mailing lists in a sub-domain, where all emails are signed, but it turns out that email addresses subscribed to a mailing list are not mailing list on their own hosted somewhere else. Emails running over the mailing lists, do not generate reports on r=y, partially because the signatures are not broken and partially because almost all providers ignore r=y. I repeat my self, but the problem was, that I used software for attaching DKIM-Signature to the emails, and the aggregate reports showed that this does not work 100% reliably. I started inserting r=y with the hope, that I will get reports on broken emails, but nearly nobody sends such reports, so r=y has not helped to fix the software i use. fo=d is independent of r=y. The reason to raise the topic, is that mailman developers will not remove r=y, unless there is a formal recommentation. I wanted to deploy DMARC policy reject (or quarantine) once I am sure, that the DKIM signature are 100% correct. I thought there is only one way to get report per failed DKIM signature and this way was to use r=y. I do not sign all emails that come from my domain, as users can use any servers, to send mail from the domain. But if an email is signed by me, I want to be notified when the signature is considered for some reason invalid, in order to ensure that the signing software works correct. fo=d would generate reports for all emails without DKIM-Signature, that is not what I want. ARC. ARF, DMARC, DKIM, Mailing lists... this thread it about DKIM, ARF-reports and recommendations about mailing lists. For this reason I have not contacted the DMARC WG, most of the subscribers are anyway likely to be the same of both ietf mailing lists. Rewriting From: by the MLM does not help with r=y. If r=y / RFC6651 is moved to historic, then RFC6652 is also historic. Do you suggest to: - ignore r=y, move RFC6651 to historic - state explicitly that providers who want reports about mismatched DKIM-Signature have to use p=reject;pct=0;fo=d;ruf=... - hint that fo=1 is not superset of fo=d - do something similar with RFC6652 and SPF 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? Greetings Дилян - Message from Alessandro Vesely - Date: Fri, 17 Aug 2018 13:15:48 +0200 From: Alessandro Vesely Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM To: Dilyan Palauzov , Ietf-dkim@ietf.org Hi all! On Sat 11/Aug/2018 05:38:40 +0200 Dilyan Palauzov wrote: RFC6651 (Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting) adds to DKIM-Signature the couple r=y - when an existing DKIM-Signature does not validate, the signing server is notified that something went (unintentionally) wrong. Interesting. I knew about rfc6651, but never cared to implement it. Would you write for those like me a short overview of your experience with your arf+dkim-report mailbox, mentioning e.g. how long have you implemented it for, the rough amount of reports / reporting domains that hit it, and the like, please? The DKIM aggregate reports show whether a server signs correctly all mails or not. If the aggregate reports show that this is sometimes (let's say in 1%) not done correctly, the signer has no way to find for which email the signing has not worked and cannot fix the signing software, unless a report for the failing mail is sent with r=y. Well, nope. Aggregate reports belong to DMARC. Consider adding a rua= address to your DMARC record. Sometimes aggregate reports allow a postmaster to pin which message triggered it. If you also set a ruf= address, you might receive ARF reports as well. Perhaps, rfc7489 is not very clear in the explanation of dmarc-fo. Does fo=d provide for sending a report irrespectively of r=y? MDaemon's implementation, for one, interprets the reference to rfc6651 as a requirement for requesters
Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
Hi all! On Sat 11/Aug/2018 05:38:40 +0200 Dilyan Palauzov wrote: > > RFC6651 (Extensions to DomainKeys Identified Mail (DKIM) for Failure > Reporting) > adds to DKIM-Signature the couple r=y - when an existing DKIM-Signature does > not validate, the signing server is notified that something went > (unintentionally) wrong. Interesting. I knew about rfc6651, but never cared to implement it. Would you write for those like me a short overview of your experience with your arf+dkim-report mailbox, mentioning e.g. how long have you implemented it for, the rough amount of reports / reporting domains that hit it, and the like, please? > The DKIM aggregate reports show whether a server signs correctly all mails or > not. If the aggregate reports show that this is sometimes (let's say in 1%) > not done correctly, the signer has no way to find for which email the signing > has not worked and cannot fix the signing software, unless a report for the > failing mail is sent with r=y. Well, nope. Aggregate reports belong to DMARC. Consider adding a rua= address to your DMARC record. Sometimes aggregate reports allow a postmaster to pin which message triggered it. If you also set a ruf= address, you might receive ARF reports as well. Perhaps, rfc7489 is not very clear in the explanation of dmarc-fo. Does fo=d provide for sending a report irrespectively of r=y? MDaemon's implementation, for one, interprets the reference to rfc6651 as a requirement for requesters to set r=y in their DKIM signatures: When the DMARC "fo=" tag requests reporting of DKIM related failures, MDaemon sends DKIM failure reports according to RFC 6651. Therefore, that specification's extensions must be present in the DKIM-Signature header field, and the domain must publish a valid DKIM reporting TXT record in DNS. DKIM failure reports are not sent independent of DMARC processing or in the absence of RFC 6651 extensions. http://help.altn.com/mdaemon/en/security--dmarc_reporting.htm > RFC6377 (DomainKeys Identified Mail (DKIM) and Mailing Lists) suggests in > section 5.7 to remove the invalidated DKIM-Signagures, if the mailing list > software has changed the email. > > I have not read ARC, but I have the impression that it says to keep the > invalidated DKIM-Signatures. > > When an email with DKIM-Signagure: r=y is sent to a mailing list, the email is > modified, and a final recipient following r=y sends a report. The problem is > that this report is useless and distracting - it does not indicate, that the > signer-MTA or validator-MTA are implemented in wrong way. Correct. MLMs affect DMARC too. > I suggest here in to suggest in a more formal manner, that MLMs modifying a > message are supposed to remove the r=y part of just invalidated DKIM-Signature > and this logic is also applied for ARC, if relevant (I don't know ARC). > Fixing > only ARC will not help, as there is software that follows DKIM, but has no > idea > about ARC. AFAIK, ARC is not involved in reporting. My feeling is that the whole topic now belongs to DMARC's territory. Let me skip the long winded story of the ideas for solving the MLMs problem of DMARC. Suffice it to say that there is a dmarc WG[*], which is where ARC comes from. Meanwhile, the MLMs problem is being solved by rewriting From:. This doesn't help r=y. However, I'm reluctant to elect to rewrite DKIM signatures. A broken signature can still be recovered by manually undoing the obvious modifications applied by MLMs, see attached screenshot. As for rfc6651, it also specifies how to obtain reports for ADSP, which was moved to Historical status. Unless your experience testifies to a relevant community traction, I'd propose rfc6651 be moved to Historical status too, and its format description be moved to rfc7489bis, whenever it comes about. Best Ale -- [*] https://datatracker.ietf.org/wg/dmarc/about/ ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
