Thanks John, sounds like the nub of #4: Who did the DMARC group have in mind when creating the specification?
Your points are well-taken. -paul On Jul 8, 2012, at 9:43, "John Levine" <[email protected]> wrote: > 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)
