This all sounds perfectly reasonable, but I worry that the DMARC group suffers from self selection, that is, everyone in it plans a full implemenation of DMARC, so you may not have considered issues of interoperation with people who implement it only partly or not at all. (I don't know that you haven't, I can't tell either way, but ...)
I think that DMARC's reporting is swell, but I am unlikely to implement the policy parts any time in the forseeable future. Partly that's because I don't have the level of attacks that large mail systems do, partly it's that my MTA (mailfront) doesn't currently do SPF and DKIM checks in the SMTP session, so it would take some major surgery to implement p=reject. So I'll publish p=none, and collect the results, but I'm not going to change what my MTA does any time soon. I expect a lot of small and medium sized mail systems will do this. >1. Why a DMARC policy should override all other policy and the role of >"local policy". This is a bad idea because it builds heisenbugs into the spec. All I want to do is to collect stats so I publish p=none, but now I hear that this means that some MTAs will interpret my SPF and DKIM signatures differently. Blech. I'm also sure that no matter what DMARC says, lots of people will do what I do, publish p=none to get the stats, and continue to interpret SPF and DKIM in the usual way. There is an element of urinating upwind here. My suggestion would be to describe the process as three layers. A. Do what you already do for SPF and DKIM. If this results in rejecting mail (e.g., SPF -all) or whitelisting mail (e.g., DKIM signature from a known friendly sender), you're done. B. For all the rest of the mail, do the DMARC stuff. If the policy says to quarantine or reject a message, you're done. C. Apply existing secret sauce to filter the rest of the mail. I don't think this is very different from what DMARC says to do now, but it doesn't break people who implement DMARC partially or not at all. To the argument that this might accept some mail that DMARC would say to quarantine or reject, that's not a bug. At worst it means that I have poor taste in whitelists, at best it means that I do competent filtering of mail from mailing lists. >2. Background on why we elected not to try and "solve" mailing lists in >DMARC. This is a tough question, because there's no good way to decide whether the answer is "because it's not a problem" or "because no matter what we say, it won't make any difference." Keep in mind that list operators will not change what they do. We didn't change for SPF, we didn't change for DKIM, we won't change for DMARC. The most you can hope for is that they'll publish SPF and sign witn DKIM (neither of which requires changes to list software or to the way that lists work for the subscribers) so recipients can recognize them. >3. Why DMARC does not contain support for policy matrices. You're on your own there. 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)
