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

[Alessandro Vesely <[e-mail]>]

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/