Hi Jonathan,
Your thesis is incorrect: there is no connection between your specified
policy and whether you'll receive failure reports. Very few receivers
are willing to send failure reports so, in general, you won't receive
them. There are some situations in which they are made available under
NDA, but I'd suggest that that's generally only relevant for the largest
senders in the world.
This does mean that you have imperfect information available on the
basis of which to decide whether to switch to p=(quarantine|reject).
I would point out one useful detail which is relevant if your concern is
corporate email (rather than bulk): because of the traditional handling
of discussion lists (mailing lists in which subscribers may also post,
like this one), some list providers will alter the From: header for
messages from p=(quarantine|reject) domains, which means that p=none
results will be slightly worse than they should be. To explore this, set
"p=quarantine; pct=0". This is the same policy as p=none (because the
100% that fall back will fall back to none), but is enough to trigger
the From: change in some cases, particularly Google Groups.
- Roland
------------------------------------------------------------------------
On 12/07/17 10:45, Jonathan Kamens via dmarc-discuss wrote:
We've recently started using DMARC for our domain, and we're doing our
best to get everything passing before we switch from p=none to
p=reject. Unfortunately, the information we're getting from the
aggregate reports that various domains are sending us is not always
sufficient for us to figure out DMARC failures. We thought we could
address this by putting an "ruf" field into our DMARC record, but
after doing that, we're still not getting any failure reports. After
further research, I think this is because failure reports aren't
actually generated for p=none, i.e., they're only generated for p=reject.
Is that correct? If so, that seems like a real problem that I don't
know how to get past. Here's the thing... I'm pretty sure most of the
DMARC failures we're seeing are actually legitimate email messages,
but like I said, we don't have enough information from the aggregate
reports to be able to figure out why they're failing DMARC. There's a
chicken-and-egg problem here: I can't get enough information to figure
out what's going wrong with these emails until I enable p=reject, and
because I don't want to bounce legitimate emails, I can't enable
p=reject until I've figured out what's going wrong with these emails.
So, what am I supposed to do?
Also, another thing I'm confused about from reading the available
information about DMARC is whether, once we enable p=reject, we'll get
copies of /all/ messages that are rejected due to DMARC failures, or
whether instead it's up to the discretion of each receiving MTA to
decide whether to generate a failure report. If the former, then at
least theoretically, we could enable p=reject briefly, collect some
sample DMARC failure reports to troubleshoot, then disable p=reject,
troubleshoot the failures, and forward them on to their intended
recipients, so no email ends up getting lost. But if it's up to the
discretion of the MTA whether to generate a bounce report, then even
if we only enable p=reject for a short period of time, we could end up
causing legitimate emails to be lost, and we'd really rather not have
that happen.
Thanks,
Jonathan Kamens
_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
