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

From: Dilyan Palauzov <[email-masked]>
Date: Sat, 11 Aug 2018 03:38:40 +0000

Hello,

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.

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.

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.

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?

Regards
   Dilian

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 17 Aug 2018 13:15:48 +0200

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/

---

From: Dilyan Palauzov <[email-masked]>
Date: Fri, 17 Aug 2018 21:48:34 +0000

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 <[email-masked]>,you <[email-masked]>" 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
   Дилян

----- End message from Alessandro Vesely <[email-masked]> -----

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 Aug 2018 14:45:40 -0700

On Fri, Aug 17, 2018 at 4:15 AM, Alessandro Vesely <[email-masked]> wrote:

> mails or

+1.

> now belongs to DMARC's territory.

+1.

> its format description be moved to rfc7489bis, whenever it comes about.

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.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 Aug 2018 14:56:31 -0700

>> which message triggered it.  If you also set a ruf= address, you might

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 Aug 2018 15:02:35 -0700

On Fri, Aug 10, 2018 at 8:38 PM, Dilyan Palauzov <[email-masked]>
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.
>

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

---

From: Dilyan Palauzov <[email-masked]>
Date: Sun, 19 Aug 2018 03:30:40 +0000

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
   Дилян

----- End message from "Murray S. Kucherawy" <[email-masked]> -----

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 Aug 2018 21:20:08 -0700

On Sat, Aug 18, 2018 at 8:30 PM, Dilyan Palauzov <[email-masked]>
wrote:

> 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

---

From: Dilyan Palauzov <[email-masked]>
Date: Sat, 18 Aug 2018 22:42:59 -0700

Hello,

I suggested to write in ARC to alter the existing signature.  

Anyway, propose handling on which there will be consensus.

Regards
  Дилян

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 Aug 2018 23:52:58 -0700

On Sat, Aug 18, 2018 at 10:42 PM, Dilyan Palauzov <[email-masked]

> 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

---

From: Brandon Long <[email-masked]>
Date: Sun, 19 Aug 2018 14:09:48 -0500

Dkim signatures are often removed by mailing lists.  For one, there are
receivers who reject messages with broken dkim signatures despite the rfc
saying don't do that.

And that shouldn't affect arc, mailing lists make plenty of other breaking
changes to the message, that's why arc is useful.  I'm not online to see
the argument that mailman is making there.

I don't think anyone's going to start modifying the dkim signature header
of do this, plus it seems odd, you're asking for where it's broken, and
this is where it's broken.

Brandon

On Sun, Aug 19, 2018, 1:53 AM Murray S. Kucherawy <[email-masked]>
wrote:

> On Sat, Aug 18, 2018 at 10:42 PM, Dilyan Palauzov <
> [email-masked]> wrote:
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 20 Aug 2018 11:22:59 +0200

> 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
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 20 Aug 2018 11:31:09 +0200

Hi!

> I cannot provide very useful experience:

Thank you for the overview.  Albeit low-volume, it confirms my feeling that
rfc6651 is not widely adopted.

> [...]

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.

> 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
--

---

From: Dilyan Palauzov <[email-masked]>
Date: Mon, 20 Aug 2018 19:32:06 +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
   Дилян

----- End message from Alessandro Vesely <[email-masked]> -----