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

[Dilyan Palauzov <[e-mail]>]

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 <[e-mail]>,you <[e-mail]>" 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 <[e-mail]> ---------
    Date: Fri, 17 Aug 2018 13:15:48 +0200
    From: Alessandro Vesely <[e-mail]>
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
      To: Dilyan Palauzov <[e-mail]>, [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/


----- End message from Alessandro Vesely <[e-mail]> -----