Subject: [dmarc-ietf] Thoughts on the DMARC spec

From: Steve Mays <[email-masked]>
Date: Sat, 14 Sep 2013 08:54:14 +0000

General Comments:
================
As an email sending professional and long time corporate receiver operator, I've been looking for something to help manage unauthorized sending practices.  Commonly used protocols such as SPF and DKIM are absolutely essential.  However, the challenge to the receiver is to receive clean and unequivocal information from the sender (or those that ask a sender to act on their behalf) as to what to do with mail that fails one or both of SPF/DKIM.  We have lived with the receiver having to come up with that answer and then having the unauthorized sender simply move on to the next gaming of the system.

DMARC presents a new tool in the fight against unauthorized sending that is quite welcome.  As a sender, I talked personally to major receivers about the need for the sending community to do a better job working with the receivers.  Simply put, its great to tell receivers when they can just delete unauthorized mail as it reduces their workload and the risk that a user of their system gets mail that should never have arrived.  By using DMARC, senders and receivers work together to fight unauthorized mail which is no longer just a prank or hacktivists but is instead a vehicle for real crimes to be committed using the good name of a reputable sender. I've been on the phone with receivers working through my results to learn how we can both defend against unauthorized mail.  This presents an opportunity for cooperation that was rare in previous years.

Participating DMARC data providers give senders all the information they need to understand trends in unauthorized mail; what IPs/blocks/domains/servers/providers provide havens for this activity and can assist in preventing and shutting down those operations.  I've been proud of my work with senders, receivers and the DMARC group and believe that it provides the best mechanism to prevent/slow/limit and report trends on authorized mail.

Some questions that I have been asked to consider:
=========================================

  1.  Do you feel that the overall specification is useful for the intended purpose?
     *   Absolutely and I'Ve used it in commercial practice to great effect, helping customers spot and cut out unauthorized senders.
     *   The ability to start off in monitoring/reporting only mode is a great learning opportunity.  As confidence builds, the standard provides for a greater percentage of mail to be intercepted and removed.  Combining the "mode" with "percentage" gives excellent controls to allow all parties to slowly move to enforcing 100% of all mail.
     *   URI feedback mechanisms allow for various protocols such as HTTP and SMTP.  This allows for flexible report reception.
  2.  Does support already exist for the specification?  For example, do you know of existing deployments that rely on the current specification?
     *   Yes! Message Bus has 100% of its customers on DMARC and works with dmarcian to provide real knowledge of the problem areas and how bad they are.  For example, its good to know but may not require (or may!) action if 100 out of 10MM mails came from a forwarder or unauthorized server.
     *   I did find unauthorized brand use, deliberate spoofing (thanks to NetEase from China), obvious stolen accounts, phishing and spearphishing and many other attacks in the forensic data stream
     *   DMARC really does allow us to address the fact that unauthorized mail senders attempt to make the "display name/address" actually match who is sending the mail and so gets to the heart of the attack against unsophisticated users which has worked so well for them in years past (so long as that name contains an email address)
  3.  Are there critical aspects of the specification that need to be modified prior to it being a published standard?
     *   I do not believe so.  I feel that we have worked the major issues out in the last several years of maawg.org meetings and having put it into commercial practice find it to be sufficient.
  4.  Are there aspects of the specification that can be modified (e.g. by additional extensions) to improve it after it has been published as a standard?
     *   We have discussed protecting the email receivers/DMARC reporting generators from obvious attempts to overwhelm their ability to gather and report data which would blind the entire community and allow for other types of attack and this would be great to address in a robust manner.  Allowing the email receiver/report generator some control to limit DoS of their reporting system would mean a more reliable system that stays alive during deliberate attack.
  5.  Does the specification as written provide a clear, precise, and accurate description of the steps necessary to implement the specification?
     *   Yes it does.
     *   Further, the dmarc.org team has worked diligently to provide a sendmail compliant mail filter or "milter" which gives a running code example and executable for actually checking incoming mail against the DMARC specification and DNS entries.  When combined with the excellent XML Schema and examples in the spec and that fact that the team addressed my specific concern of having no examples of multiple "rua" and "ruf" destinations (see B.2.4), I am well satisfied with the spec.
  6.  Would you feel comfortable supporting it being published as a standard, or are do you have any additional reservations you would like to see addressed before you would support it?
     *   I have no reservations with it being published.
     *   I would like to thank the DMARG.org team and all of the participating parties such as Yahoo, NetEase, AOL (who has helped me a LOT!), Tim Dragen for his dmarcian site.  The community around DMARC.org has won over the hard to please maawg.org crowd and the spec is in active use and on the way to being the de-facto standard in the email community which is a testament to the dedication and quality of the team and this spec.

--
Steve Mays
[email-masked]
cell: 415-385-4918