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 protected]>,you <[email protected]>" 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 <[email protected]> ---------
Date: Fri, 17 Aug 2018 13:15:48 +0200
From: Alessandro Vesely <[email protected]>
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
To: Dilyan Palauzov <[email protected]>, [email protected]
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 <[email protected]> -----
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
