[Top] [All Lists]

Re: [ietf-smtp] ietf-smtp(_at_)ietf(_dot_)org and DMARC with p=quarantine; pct=0

2019-01-25 17:27:07

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

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
* for the purposes of testing there must be a way only to get reports for bad 
situations, without having the bad


On Fri, 2019-01-25 at 17:12 -0500, John Levine wrote:
In article <066CEDBC-8DD0-45B0-BE9E-B06FECD6C93B(_at_)aegee(_dot_)org> you 
somebody wrote somewhere (I can search for this statement if necesssary), 
that p=quarantine; pct=0; is the way to test, whether the
DMARC setup is working correctly and get failure reports.

There are certainly people who believe that, but they are mostly wrong.

You get the same failure reports with p=none as p=reject, so that's
not it.  I have p=none on all my domains and have collected 170,000
aggregate reports and 77,000 failure reports so I speak from
experience here.

What pct=0 might or might not do is to trigger recipient filtering
rules and mailing list rewrite rules, but that is entirely up to the
people who run the lists.  They can and will do whatever they want.


ietf-smtp mailing list