This is worthwhile, if aspirational, input to a future phase of the DMARC
WG (added to the distro and moving SMTP to BCC). It is, as you observe, not
the current state of the spec.
One further complication is that relatively few receivers generate forensic
report (ruf), in part due to privacy concerns. As a result, even if the
process worked the way you advocate, you won't get much if any information.
--Kurt
On Fri, Jan 25, 2019 at 1:27 PM Дилян Палаузов
<dilyan(_dot_)palauzov(_at_)aegee(_dot_)org>
wrote:
Hello,
at a high level the common interest is to reach a state, where deployed
DMARC works in practice reliably:
- verifiers and signers are compatible
- signature are not broken on their way to the recipients, so no bad
delivery
- the path from sender to recipient always works reliably and whenever
something does not work as expected an individual
failure report is sent
…
Receiving aggregate report, stating 0,1% of mails do not verify DKIM,
shows that signers and verifiers in that
combination are not compatible. The aggregate report does not say whether
the the signer or the verifier does bad job,
it just proves that DMARC is not going to work 100% reliably. This is bad
for both parties, as it just means that DMARC
shall not be trusted as it in practice does not work as expected (and
therefore deploying it is…)
The individual failure reports provide the means to find exactly what is
going wrong, on which system. To tackle a
failure report I want to be sure that something wrong happened. A failure
report for p=none cannot mean, that something
wrong happened, in particular it does not mean that DMARC is violated. So
sending a report on p=none makes no sense.
Shall a failure report be sent for p=quarantine; pct=0?
https://mailarchive.ietf.org/arch/msg/ietf-dkim/fUGKyF0iE6DmKPJj-qH4XHz4_Lg
says “p=reject;pct=0; is to force MLMs to
rewrite From:, so as to
avoid useless reports”.
This is discussable but the common aim is to have a state, where reports
get very seldom and every report has an added
value — indicates a problem that is investigated. Sending too much
reports, on real and unreal troubles, makes tracking
manually all reports impossible and does not help to make DMARC reliable.
Keep in mind that not every person deploying
DMARC or mailing lists understands DMARC or acknowledges that its MLM
modifies messages but does not change the From:
sender.
The current discussion does not lead in the direction of reaching the
state, where reports are sent seldom and indicate
troubles, which troubles shall and can be handled in a way, that prevents
happening them again in the future. That
said, the current setups in general do not permit to improve the accuracy
of DKIM/DMARC evaluations.
There are not only theoretical, but also practical concerns. Having
DKIM-Signature: r=y; … in a message, sent over a
mailing list, the From: is changed and DKIM invalidated. Per RFC 6651 a
report is sent. But this report is useless, as
the MLM broke the intentionally the DKIM-Signature, so there is no
information to extract from the report and there is
no approprite handling.
In summary, the specifications shall be read in such a way, that:
* reports shall only be sent, when the recipient of the report can and
shall take actions to improve the accuracy of
DMARC/DKIM, and
* for the purposes of testing there must be a way only to get reports for
bad situations, without having the bad
consequences.
Regards
Дилян
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp