Murray S. Kucherawy wrote: > 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?
DMARC has a prominent failure case with mailing lists; also, such failure cases are not readily obvious to prospect would-be DMARC adopters as Senders. SPF does not have those problems. Therefore, DMARC is much more hairy to properly implement as a receiver that SPF. If you don't want to acknowledge that, but prefer to misrepresent my position and to posit it as ridiculous or inconsistent, then I feel very much dismayed. > > > > 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. Please, explain why the internally-agreed-upon practices of the oligopolistic big four mailbox providers need to be sanctioned as an Internet-wide official standard disregarding the operational problems such an standard in its current formulation would bring to the smaller players in the email arena. > > > 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. I don't have time to "defend" it if the usefulness of my proposal happens to not be directly obvious to other email players. I also don't have a lobby group to defend it for me. But I will try just again, succinctly: the "l=" tag would allow Senders who implement p=reject and then discover false positives in the email they send, to declare a posteriori (after they discover the trouble) to the Receivers that their users do indeed use mailing lists, so that the Receivers could bring that additional data point into their local "secret-sauce" DMARC evaluation system. You, on the other hand, think that in that case the Sender should just not use p=reject, therefore you don't see the need for the "l=" tag. Well, I guess then you also think the world is a Cartesian universe and its inhabitants are Kantian people. It must be nice to live in such a clear cut world. Also, I guess nobody at linkedin.com with it's nice DMARC policy of p=reject ever participates with such an address in mailing lists, right? > 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. DMARC's reject policy is unreliable because it has obvious failure cases. By that same logic, SPF -all does not have those failure cases, so it is much more reliable. I don't know how do I have to say that to be understood, what part of that you don't understand? > (*) 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. Sigh. I think I give up. > > 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. If you think it would be normal for a third party to open a bug report with Gmail about a problem a Gmail user has with a Gmail product, then... OK, yeah, you are right. Regards, J.Gomez _______________________________________________ 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)
