On Saturday, July 07, 2012 02:10:18 AM Franck Martin wrote: > On 7/6/12 5:27 PM, "Scott Kitterman" <[email protected]> wrote: > >On Saturday, July 07, 2012 12:21:03 AM Franck Martin wrote: > >> On 7/6/12 4:46 PM, "Scott Kitterman" <[email protected]> wrote: > >> >On Friday, July 06, 2012 11:28:17 PM Franck Martin wrote: > >> >> May be I can clarify > >> >> > >> >> SPF tests have to pass first on their own merit, so we are not > >> > >>changing > >> > >> >> anything. It still applies to the Mail From envelope. What DMARC > >> > >>adds is > >> > >> >> alignment between the domains in the mail from: and From: combined > >> > >>with > >> > >> >> the DKIM pass and alignment we get if DMARC pass or not. > >> >> > >> >> So DMARC do use SPF. > >> > > >> >If you want to put it that way, then that makes it even clearer that > >> >DMARC is > >> >not a replacement for SPF policy. Call it what you want, just don't > >> >force > >> >people into choosing between the feedback mechanism in DMARC (which I > >> >really > >> >like) and existing policy mechanisms that might say something stronger. > >> > >> I understand SPF is doing rounds in IETF, you could suggest there a > >> feedback mechanism to the protocolŠ > > > >There is one of those defined in RFC 5598, but it's new and doesn't have > >much > >in the way of deployment (there's a similar mechanism defined for DKIM). > > > >> We don't force anyone to adopt DMARC, we are even saying it is not for > >> everyone, but point taken to may be alert more if people have a current > >> spf -all or adsp and want to move to dmarc. It could be clearer that > >> p=none in that cases may change disposition. > > > >I think that's an unbelievably poor design choice, but now that you've > >clarified it, I've removed my DMARC record. > > But also the purpose to this list is to learn from a broader audience, and > take that in consideration for the next spec review.
Certainly. I didn't saw that I quit the list and gave up, but as specified, it's currently a poor choice for me. That doesn't mean I am not open to putting it back later if I have a different view. I published the record with the understanding that all it would do is get me feedback. That turns out to be mistaken. > I understand for a receiver which does not have DMARC in its tool box > applying a SPF -all to avoid to receive fake email from a domain is a > solution, but they seem to go to great length to check the the sender SPF > record is correct, and personally, I would prefer they do DMARC, but I'm > also pragmatic, something is sometimes better than nothing. There's no reason to design DMARC is such a way that you force anyone to choose. You have your preference, but you have to consider the broader usage. > Finally, as you had reports, did you notice a difference in the way your > emails were handled (I may have missed that in the thread). There's no way to know if they were handled differently or not. I didn't notice anything, but the amount of direct email I have with the current DMARC reporters is very small. Here's another use case to consider: A large financial institution has invested a lot of effort into separating it's human and transactional domains, deployed SPF, DKIM, and ADSP (on the transactional domains) and is comfortable with it's situation. Now you tell them they should deploy DMARC. How do they evaluate DMARC and see what the impact of publishing DMARC reject policies would be without messing up the stuff they've already spent 5 years working on? By the current definition, they can't. Why not? If you want to split out monitoring from take no policy action of any kind into two separate things, that's fine, but I really think you need a monitor policy that means exactly that and no more. 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)
