Frankly, the primary problem I am trying to solve is that hackers in our
HackerOne bug-bounty program and random white-hat hackers on the
internet keep breathlessly reporting to us that it's a security problem
that we don't have DMARC configured on our domain and expecting us to be
overwhelmed with gratitude that they've revealed their amazing discovery
to us and in gratitude shower them with rose petals and bug-bounty cash.
I'm not an email newbie. When I started maintaining mail servers, I was
writing sendmail.cf files by hand because the m4 cf templates didn't
exist yet. I've submitted patches to both sendmail and postfix. I
maintain several open-source milters. My personal email has been hosted
on a mail server I maintain for 28 years, and my personal email domain
has both SPF and DKIM. In short, I have a pretty good idea about how all
this stuff hangs together.
I have always been skeptical about the value and design details of
DMARC. I am hoping that this is just because I misunderstand it, and,
indeed, I've learned a thing or two from the advice I've received on
this list and from the experience of trying to deploy it. But at the
same time, some of what I've learned seems to confirm my impression that
DMARC is unreliable because of problematic elements scattered throughout
its design and implementation.
So, what am I trying to accomplish, aside from the trivial goal of
making hackers stop emailing me?
Simply put, I want to make it more likely that legitimate emails from
our domain will be delivered, and more likely that forged emails
purporting to be from our domain will be rejected.
We do not have enough of a problem with forged emails that I am willing
to do anything that will cause legitimate emails that have been accepted
in the past to start being bounced because of DMARC. It is more
important to me for legitimate emails to get through than for forged
emails to be bounced.
Furthermore, we can't afford to use DMARC if that means actively
maintaining our email reputation on a near-daily basis. We're a small
company, and we have way bigger fish to fry. If it's not possible to
roll out DMARC for our domain without making a commitment to spending
time on a regular basis reviewing DMARC reports, either directly or
through something like dmarcian, then it's probably not feasible for us
to use DMARC.
Here's some of what I feel like I've learned so far:
* Reviewing DMARC aggregate reports by hand -- i.e., just loading the
XML files into a text editor and searching them for potential
problems -- on an ongoing basis is far too time-consuming to be
sustainable. Instead, you can skip getting the reports; or you can
file the reports in a separate folder and only look at them when
you're investigating a known delivery issue; or you can feed the
reports through a service like dmarcian and review them there.
* Not everybody who pays attention to DMARC records generates
aggregate reports. Not everybody who pays attention to DMARC records
generates failure reports. It's entirely possible that some
legitimate emails from us will be rejected due to DMARC failures
without my finding out that's happening until much later, if at all.
* There is no on-ramp for DMARC that will allow me to know with
certainty what the impact of DMARC will be before it starts causing
some legitimate emails to be bounced. Though the DMARC spec tries to
create such an on-ramp, the way email providers interpret DMARC in
real life is quirky and highly variable from provider to provider.
o One example of this is the fact that although one would think
that "p=none pct=100" and "p=reject pct=0" would have exactly
the same practical effect, in fact they behave differently at
some sites.
o Another example is, as Roland wrote, the fact that "you can't
reliably infer that a failure report received at p=none (or 0%
quarantine) will mean a reject at p=reject."
* There are currently several known issues with entirely legitimate
messages sent through major email providers being bounced due to
p=reject, most notably the Microsoft issue that Terry mentioned.
It feels to me like my unease about DMARC stems from the fact that the
folks who wrote the spec and the sites that are enforcing DMARC have a
markedly different philosophy than I do about email. This difference was
highlighted by a comment in Roland's email, when he asked "how much
collateral damage [I'm] willing to accept." This approach -- that some
"collateral damage" to legitimate email delivery is acceptable when
trying to stop forgeries -- was entirely foreign to how email was
thought about when I started working it, and it's still extraordinarily
difficult for me to come to grips with.
So, where do I go from here?
a) Give up on DMARC entirely, at least until things improve to the point
where the major providers are no longer suffering from issues such as
the Microsoft issue.
b) Set our DMARC record to "p=none; pct=0" and unset "rua" and "ruf".
But then if we start doing something different from email delivery at
some point in the future, e.g., we start using a new third-party service
provider that is sending emails on our behalf and forget to configure
SPF or DKIM properly for them, we won't know about it.
c) Like (b), but use an "rua" that sends the emails to somebody like
dmarcian that will process them for us in a way that makes them more
useful and less time-consuming.
I'm not really sure yet where I'm headed with this.
jik
On 07/13/2017 12:49 PM, John Levine wrote:
> In article <[email protected]> you write:
>> Can we do anything to prevent messages such as this one from bouncing
>> when we turn on p=reject?
> Probably not.
>
> Perhaps you could back up and tell us what problem you expect to solve
> by turning on p=reject. Unless you are a target of an unusual amount
> of phishing or malicious forgery, p=reject often causes more problems
> than it solves.
>
> R's,
> John
_______________________________________________
dmarc-discuss mailing list
[email protected]
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)
