Hi all,
Before I dive in, I want to quickly thank everyone involved in DMARC,
from the email providers actively supporting it to the guys helping out
in the IRC (franck, smj_crash, and ScottK - you're all awesome). You're
doing a great service for those of us who want to keep our email as
clean and tidy as possible, thank you!
Please skip to paragraph six if you're not interested in the story.
I had some trouble with my initial rollout and I wanted to post here in
the hopes of improving the experience for others. However, my intention
is to help, not hinder, so if you find my comments unhelpful or not
constructive, please call me out on it and I'll do what I can to provide
suggestions or better articulate my point.
I am the operations engineer for the oasis.com family of dating
websites. When I started here we had quite poor email practices (no
address validation, poor bounce handling, login required for unsubscribe
etc) and had poor deliverability as a result. Shortly after I arrived we
were cut off by our MSP for poor reputation and were taken to task for
our bad behaviour. We have since cleaned up our act substantially and
have learned a lot about both transaction and bulk email sending in the
process.
Recently, when Gmail made a significant change to the way it handles
SPAM, we began getting marked as SPAM ourselves. This included our
welcome and validation emails, which was a major concern for us. In
addition to an unmaintained SPF record on several of our sending domains
(we have several culture-specific variants of oasis.com which we send
email from directly) we found a mistake in a common piece of markup we
use in all our emails (thanks to http://www.mail-tester.com/ for that)
which were both fixed and deliverability to Gmail inboxes returned to
normal. However, that was discovered after we'd learned of DMARC and had
decided to implement it.
We started out by reading the overview and some of the FAQ entries that
seemed relevant. There is a demo record in the overview but it was
unclear at the time how universal this record might have been. Since
most places seem to refer you to the RFC when attempting to create your
own record, I hunted for a quicker path (I understand why users are
referred to the RFC, and it's certainly helpful to have a full
understanding of DMARC, but the document is quite verbose and it seemed
unreasonable to expect anyone who wanted to implement DMARC to read the
entire RFC). It was then we stumbled upon
http://www.unlocktheinbox.com/dmarcwizard/ (I've since been shown
http://www.kitterman.com/dmarc/assistant.html which is being actively
developed as I write and already addresses several of my concerns). It
is here that I believe we made our biggest mistake (please take no
offense - like I say it was our mistake). The main problems were these:
1. We initially deployed to our QA environment, which is on a
subdomain. Since it's on a subdomain we used an address from another
domain. As you can imagine by the third day of no reports there was
some head scratching. This was solved after a quick FAQ read. As a
suggestion, I'd probably say that address auth be mentioned, even
just in passing, in the overview, and the wizard could make mention
of it when someone uses an address that doesn't match the domain and
perhaps even provide the auth record.
2. We started out with an RUF in production. We now know that this was
a big mistake, and we were very lucky that we'd done so much work on
our emails prior to deploying DMARC. We have a minor spoofing
problem for which recieve a few dozen forensic reports but on the
whole we came out unscathed. Again I'd recommend this be mentioned
in the overview (both that you may get high volume, and that it
should not deployed whatsoever from the outset) and that the wizard
both prompt you about your current deployment status and note in the
field description that you should only provide this once your
reports are coming in clean.
3. The wizard includes the default size limitation, which appears to
have poor support among the mailbox providers (we didn't receive
reports from Yahoo or Gmail until we removed it). I'd ask that
mailbox providers begin supporting that part of the spec as soon as
possible, and that the wizard make note of it (and not include it by
default), or preferably prompt the user not to include it.
Some general comments:
1. While the aggregate reports are helpful for those with the time and
resources to run dedicated processing infrastructure, they're not so
helpful for those of us that don't have the opportunity, for
whatever reason, to deploy those kinds of resources. My suggestion
here would be that there's a human-readable summary of what's in the
report in the body of the email it's attached to, perhaps simply
outlining the failures in the report. We are currently evaluating
Dmarcian for some more visibility in this area, but I'd much prefer
we didn't need a web service or dedicated infrastructure for some
easier visibility of this information.
2. Further to the point above, we've found the forensic reports to be
much more immediately helpful in identifying issues than the
aggregate reports. Providers not offering forensic reporting may I
ask that you please reconsider for the sake of those with limited
resources to process the aggregate reports.
3. The default for the forensic reporting option is that the sender is
notified only if -all- authentication mechanisms fail to pass. This
seems counter intuitive to me, so I'd recommend that there be
mention of it made in the overview, that the wizard support it, and
that it be added to the list of tags in the overview.
Sorry about the length of this, hopefully the content was helpful
though. Please point out any faults in my reasoning or oversights on my
part, and feel free to ask for elaboration or further suggestions if
you'd like.
Thanks for reading,
Gary.
_______________________________________________
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)
