Message from: Murray S. Kucherawy, who wrote: > 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.
I plain reject on SPF -all, and my clients are fine with it, in several different installations. Exceptions are added to a whitelist on a case by case basis, and only if the sender is some automatic system whose administrator is not easily reachable. Otherwise, the sender is told they are spoofing the domain against the domain owner's policy, and the case is closed. It works, because it's the sender's fault, and because it is plain easy to see it and to check it, AND BECAUSE IT IS PLAIN EASY FOR THE SENDER TO FIX IT. So far, my clients are happy. I also reject on SPF softfail for some heavily spoofed domains -- and, again, so far my clients are happy with their spam free inboxes. The case will not be so easy for DMARC's p=reject false positives. It is going to be hard for the sender to fix them, because they are going to keep publishing p=reject AND having users subscribing to mailing lists (so is human nature -- senders are not going to go through the all trouble of learning about DMARC, setting it up, just to end up not using p=reject to "protect" their "precious" email domain/brand). Yes, I know your answer: that the receiver has to build a custom, fine-tuned, on-going maintenance-heavy local-only system to deal with those DMARC failure cases, as the DMARC standard so aptly suggests. Therefore, the conclusion is clear: DMARC has NOT a workable policy of reject for receivers to implement. But I guess if someone is hired full time to deal with the support tickets for DMARC failure cases, then his definition of "workable" would be different. >> 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. My stated prediction is exactly correct, at least in terms of the number of mailbox providers currently covered by DMARC. > 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. I won't, as a receiver. I will, as a sender, with p=none and just to get feedback reports on my email streams. > 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. That could work: a Spamhaus.org-like service for sharing known-good DMARC whitelisting of DMARC p=reject failure cases, based on the sending domain or, perhaps better, on known-good mailing-lists/forwarders. > 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. I already did. It was summarily dismissed, though. So I tried, I did not just complained. http://www.ietf.org/mail-archive/web/dmarc/current/msg00167.html >> 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. Sorry, but it IS reasonable to expect that someone who goes through the effort of using his resources and time to find out about your published policy, will then follow it -- specially when the onerous part is the first one, finding about the policy, and not the second one, following it (ie., just dumping failures on p=reject). If the receiver was not interested on the sender's policy, why did he bothered to check it at all? Was he bored? Was he just doing field research and collating statistics? What is going on here? --> What is going on here is the reality that DMARC's reject policy is UNRELIABLE, and therefore unworkable.(*) (*) Unless, of course, the receiver wants to build a custom, fine-tuned, on-going maintenance-heavy local-only system to deal with DMARC failure cases. >> 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. OK then, policy is not policy. You are right. > More generally still, I would really love to see some constructive > feedback here. I am sorry you do not like my feedback. It must is destructive. Regards, J.Gomez PS: I would love it if your posts to the list would keep the proper quotation marks in their plain-text alternative version, so that quoting them would not longer be an exercise in acrobatics. _______________________________________________ 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)
