This recent thread has highlighted the fact that implementing anything other than p=none for a domain with human users is risking non delivery of legitimate email (I'm curious how many of you will receive this email as I presently have a p=reject policy for my domain). However, this wasn't entirely clear to me when I got involved with DMARC. Yes, you can tell me to RTFM and that would be a valid and perhaps justified response, especially since I'm not new to managing email. However, I think there is something to be learned from my experience and perhaps something good can come of any ensuing discussion.
I just want to pass along some of my experiences as a new DMARC user for consideration by this group. First, as I've pointed out before, I don't manage a domain with a high mail volume and even when I did manage a mail server moving a few GB of mail a day, it was one of many roles that I had at that time (jack of all trades for a small ISP). So, I'm far from being a mail expert, however, I consider myself reasonably well versed in basic mail administration. So, here's how I came to try out DMARC. My wife has a small business in a competitive industry where competitors often don't play fair. For an online business, email, despite it's security shortcomings, is still the corner stone of business communication, so it's very important that she has reliable delivery of mail and like every other small business owner, she wants to deal with as little inbound spam as possible. Like any business, large or small, she also wants to protect her brand. As a small business owner there is always a very delicate balance between many competing factors when dealing with technology - price, maintainability, complexity, support, etc, etc When it came time to improve upon the basic mail system we had in place, it was decided that Google Apps was probably the best we could do (free, excellent spam filtering, totally hands off for maintenance, reliable, etc). When I first learned about DMARC, I looked to see if we could use it with Google Apps and indeed we could. Here is Google's page concerning DMARC for Google Apps - http://support.google.com/a/bin/answer.py?hl=en&answer=2466580. Here is a quote from that page this is relevant to this discussion: "You might want to adjust your policy as you learn from the data in these reports. For example, you might adjust your actionable policies from “monitor” to “quarantine” to “reject” as you become more confident that your own messages will all be authenticated. " I proceeded to setup a DMARC record as per Google's instructions, choosing p=none to start, and soon found Tim's dmarcian site which helped me to translate the reports I was getting back. The reports helped highlight that there was a great deal of abuse against our domain. The abuse volume was regularly an order of magnitude greater than the legitimate volume and often times much higher than that. So, after watching for several days, I opted to put a reject policy in place. I then felt much better seeing the reports showing that all of this spoofed traffic was now no longer being delivered to receivers' mailboxes. Now, in light of the issues around forwarding and mailing lists, I'm contemplating going back to a monitor policy, but I'm not convinced that's the thing to do yet. So, here are a few things we might want to look at: First, is it really justifiable to make a blanket statement that a domain with human users should only use p=none? In our case, the volume of abuse of our domain vs the number of potentially rejected emails due to forwarding issues, is highly disproportionate. Would we not be better off to leave p=reject in place and deal with the occasional failed delivery of a legitimate email? I guess we could move to a p=quarantine at 100% and ask customers to look in their spam folders, but then we risk having spoofed email show up in that mailbox as well. Honestly, at this point, given the wide variety of anti-spam filters in place out there, I know that some legitimate email is going to wind up in quarantines anyway, so perhaps it's better to stick with the reject policy and at least try to protect our domain/brand from spoofing. Second, if we decide that losing any legitimate mail is a bad thing and thus we move to a monitor or quarantine policy, what useful actions can be taken based on DMARC reports to help protect our brand and our customers? Or taking a longer view, is it possible for DMARC reporting in conjunction with services that consume those reports to actively help guide well intentioned senders to modify their infrastructure to be DMARC compliant so that, in the future, implementing a reject policy on a domain that has human users is a feasible best practice? Certainly updating Mailman, Yahoo Groups, Google Groups, and other major mailing list implementations would go a very long way to reducing this problem to a very minor one. Finally, when I sit and think about the mailing list problem, I certainly see why this is a problem for DMARC. The problem with mail is that, because it is so incredibly maleable and has been around for so long, it gets used and abused in many different ways that aren't always obvious to someone that isn't dealing with the vagaries of managing mail day in and day out. Thus, I think it would help DMARC's adoption to be as clear as possible where the gotcha's are and to make best practices clear and easy to find. If you look closely in the DMARC FAQ, the only entry that really highlights this mailing list problem is the one titled, "Why doesn't (major mailbox provider) publish a DMARC record?" My reading of some of the other content in the DMARC FAQ, seems to suggest that we should hope to see most senders adopt DMARC and that moving to a quarantine or reject policy is desirable. In the case of the Google Apps support document listed above, given that Google's user base for Google Apps is likely composed primarily of small businesses with customers having a single domain with a mix of transactional and regular mail, wouldn't it make sense to have a stronger caveat regarding DMARC policy choice as well? -- Mason _______________________________________________ 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)
