The way I see it personally is do not affect the policy component of the underlying authentication schemes if any when in monitoring mode, when in other modes override the policies of the underlying authentication schemes. You adopt DMARC or you don't but I don't think there should be an in-between except in monitoring mode.
As for whitelisting and other things, well the receiver is free to do what he wants of the email he receives and the spec provides several reason he/she can use to override the DMARC policy, but he/she is on his/her own there. As noted before we should avoid uncertainty. On Jul 8, 2012, at 3:13 PM, Scott Kitterman wrote: > On Sunday, July 08, 2012 04:43:22 PM John Levine wrote: >>> 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. > > I think this makes a lot of sense. I think it's how this will likely work in > practice for most receivers anyway. Having the spec be aligned to reality is > an important aspect of the increased reliability in the email ecosystem that > DMARC is trying to foster. > > Scott K > _______________________________________________ > 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) _______________________________________________ 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)
