On Wed, Mar 5, 2014 at 3:23 PM, J. Gomez <[email protected]> wrote:
> We probably inhabit different universes. In mine, SPF -all "just works" > and, most importantly, it allows the receiver to outsource onto the sender > 100% of the blame arising from any non-deliveries because of SPF -all > failures; also, in my universe DMARC has not "succeeded" -- not yet, at > least. > Based on my experience, you do indeed live in a different universe. I have no first hand exposure to any installation that respects SPF "-all" above all others. Quite literally every place I have ever worked or otherwise had an inbox has used SPF's result as part of a larger message evaluation system because false negatives and spoofs are too much of a concern. I fully understand that there exist places where acting on an SPF failure with "-all" by rejecting the message "just works". I am not saying they don't exist. I am saying that they appear not to be common. For DMARC to be a viable option for receivers, it has to provide them with > a non-refutable answer/position for the cases when mail is not delivered > because of DMARC failures. If receivers are expected to build a custom, > fine-tuned, on-going maintenance-heavy local-only system to deal with DMARC > failure cases, because receivers cannot just outsource onto senders the > blame for DMARC failure cases, then most receivers WILL NOT IMPLEMENT > DMARC. My guess is many receivers will not implement DMARC after having > burned to much time and support costs dealing with DMARC failure cases. > Your shouted prediction here is countered by fact, at least in terms of number of mailboxes covered and ample anecdotal evidence. As has been repeatedly stated, DMARC is not for everyone. If it doesn't handle your use case or the exception handling you will need for your installation is too expensive, then don't use it. On the other hand, the Internet is a fertile ground for innovation, so perhaps there's room for someone to devise a system whereby the exceptions can be shared among interested parties so that they can spread the costs of identifying and handling them. For the sake of encouraging this thread to actually be constructive, I invite you to propose any text changes that you believe will actually compel receivers to honor the DMARC result irrespective of other concerns. If you can succeed where all others before you have failed, I can guarantee you'll have a new fan club. > One party's policy published for the consumption of the receivers, is a > policy expected to be treated as policy by the receivers, otherwise it > would be the first party's private-policy and not the first party's > published-policy. If what I publish as policy is to be regarded as a song, > then why do I bother publishing a policy instead of a song? > What gives you, as a sender, domain over how receivers will behave? Those are their resources and their users, not yours. They are the ones that get the support calls when your actions (or inactions) cause some kind of negative user experience. They incur the costs of your actions (or inactions). Expecting them to simply do what you command is ridiculous, and they deserve what they get if they do so. > > This is not a contradiction, nor is it ex post > > facto twisting; this is the plain English meaning of the word. > > Policy is policy. That someone opts to not follow it, makes it an ignored > policy, not a non-policy. Therefore, DMARC's policy of p=reject is best to > be ignored. Or, in other words, there is not such a thing as a workable > policy of REJECT in DMARC. > This is still flatly incorrect. Simply repeating it doesn't make it true. I asked you before if the "P" in "SPF" (which stands for "policy", I would remind you) causes you similar friction. Does it? Do you have another word you'd like to see in its place, at least in the DMARC documents? More generally, do you have alternative text to propose for the current DMARC base draft that talks about the "policy" as, effectively, a request to receivers? The base draft does go to some length to explain this already. More generally still, I would really love to see some constructive feedback here. Otherwise, I believe this reduces to little more than skeptical ranting, and we should move forward. -MSK
_______________________________________________ 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)
