On Tue, Mar 11, 2014 at 3:19 PM, J. Gomez <[email protected]> wrote:
> 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. So having an exception system for SPF is acceptable and SPF is useful to you. At the same time, the thought of doing so for DMARC makes the entire concept undeployable. Is that correct? It's fine that rejecting on SPF -all works for you. It doesn't work for a lot of other operators. Your situation does not generalize to the deployed Internet. 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. > "For some heavily spoofed domains" means you're maintaining an exception list for that case as well, unless you've found a published list of those someplace. > 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. > That is not the only solution that has been presented here. > >> 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. > Please explain why that is a more important consideration than the number of users being protected. > > 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. > Excellent. > > > 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. > Precisely. And the publication and query methods already exist. > > > 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 > Criticism of your proposal was presented (and linked from that page) by several people that you were not able or willing to refute. Labeling that as "summarily dismissed" is plainly invalid. You even admitted that one obvious criticism is that your proposal is ultimately useless. Part of your counter-argument was that your proposal merely conveys additional information from the sender to the receiver, and the latter is free to consume it as he wishes or disregard it altogether. This seems awfully familiar to things we've been saying, yet if we say them, they are bogus to you. > > > 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.(*) > Your "field research" quip is closest to reality. Your conclusion that DMARC's reject policy is unreliable suggests you only consider a sender policy to be reliable if all receivers are assured (or perhaps are compelled) to obey it. By that logic, you must also admit that SPF's "-all" is unreliable, because the majority of receivers out there today don't honor it, largely for the same reasons that DMARC's reject policy is not blindly followed. > > (*) 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. > Sounds like you have one for SPF already. I don't understand why it's different for DMARC. > >> 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. > I have invited you on more than one occasion to explain why the "P" in SPF is okay with you given it is rarely directly enforced, or to offer alternative terminology or text for the DMARC base specification to resolve this dissonance you have around the word "policy". The latter would certainly be constructive. You have done neither. > > 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. > Similarly, I'm sorry that DMARC will not work for you. I'm also sorry that your aforementioned suggestion did not survive some basic criticisms (one of which you yourself offered, in fact). That doesn't mean DMARC won't work for anyone, or that it is harmful, or that this work should not proceed. However, I would hope you can appreciate that "This won't work for me, therefore it's bad" is breathtakingly faulty logic. > 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. > > You are welcome to open a bug report with Gmail. Given that this thread isn't going in any sort of constructive direction anymore, I recommend it be allowed to die. -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)
