Franck Martin writes: > I think we should refrain to blame anything or anyone.
I think that there is no solution attractive to email users possible without naming names. AFAIK[1], it is a fact that the problems that have made "DMARC" a four-letter word across the Internet are almost entirely due to the unilateral decisions to publish "p=reject" by *two* domains. Call that "blaming" if you like, but that fact matters because any *good* mitigation[2] involves their participation. The only alternative I can see to participation by those specific domains (and any domains producing similar mailflows that may publish p=reject in the future) is a general agreement among DMARC receivers to treat "p=reject" as purely advisory (say, -2 spam points if alignment is verified in SpamAssassin). I know you don't like that weakening of the protocol, and I don't think it's a good idea, either. DMARC is a great protocol for direct mail streams, proven in practice. Two? Yes, *two*. Bank of America? No problem, it's all direct mail. LinkedIn? Who cares? Pretty clearly linkedin.com employees have figured out that posting to MLs from that domain is not good for their ability to communicate, and LinkedIn itself primarily uses *direct* mail to collect traffic to their website. Accidental leakage from either kind of domain is no big deal and self-correcting. Why single those two out? Because they've already demonstrated that they place their own security issues over the general functionality of the mail system, so it's questionable whether they will buy in to any solutions we come up with. We already know that there may be security issues (DKIM delegation-style proposals) or significant costs (TPA via DNS-style proposals) to implementing those solutions. The best way to get an answer about what *they* want in a solution is to ask them. For that, we need to say their names. And if those two buy in, I think there will be huge pressure on any future p=reject-niks to participate in the mitigation protocols, even if not 6-sigma secure or involving additional nameservers or other costs. > It is what it is, Indeed, and what it is, is a purely private protocol whose own specification deprecates the controversial use case. Don't forget that fact. > and we should just note it, technically describe it, It had better not stay what it is! One thing that is easy to forget and to ignore is that, without a practical third-party authorization protocol, "p=reject" from even one large group of mail users has a chilling effect on all *new* third- party mail services. A large service with an established user base such as Intuit's invoicing service can weather even something like what happened in April 2014, but I wonder how many new 3rd-party services rolled out in first quarter of 2014 just died without even a whimper because of how "unreliable" they were for ordinary mail users at p=reject domains after April. I wonder how many 3rd-party services won't ever be implemented commercially for that reason. Yes, as written those stillborn services are just FUD, but economists have ample evidence that removal of apparently minor hindrances can invigorate innovation and the general business climate.[3] Don't deprecate the potential for innovation just because I'm unable to provide figures for the case of 3rd-party email offhand -- these things are essential impossible to measure in advance. > and see if better solutions can be provided. They can only be "provided" if the unblameable domains implement, because as DMARC is currently specified "p=reject" is a unilateral decision by the Author Domain. Otherwise, the solutions aren't worth the paper they won't be printed on. > This atmosphere is not conducive for group work. The deafening silence of the "p=reject" domains which originate large general-use mail streams as to how they will contribute to mitigation of the bad effects of their DMARC policies isn't conducive to group work, either. I've observed that posters here consistently categorically reject potential solutions as unworkable based on FUD about DNS costs and insecurity and inability to scale user profiles that specify per-user "trusted 3rd party" lists, despite the fact that representatives of these two domains haven't even commented on them. That fact matters because nobody who doesn't (1) originate general-use mail streams and (2) publish "p=reject" has to pay those costs, and at present they are only ones that satisfy both criteria! Footnotes: [1] If I am ignorant of relevant facts, please inform me. [2] Conforming to existing normative RFCs and meeting the requirements of *email users* as expressed to the providers of services they use. Eg, "author appears in From on mailing list posts". [3] Two cases in point. 1. Relaxation of airline regulation. Air travel in the U.S. today is much cheaper, more flexible, and (remarkably) safer than it was up to the 1970s. 2. Relaxation of postal and transport regulation, without which the amazing progress in logistics that makes Amazon.com a dominating presence in the book- selling industry could not have occurred. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
