Hector Santos writes: > You (speaking in general) either support a policy concept or you > don't. Thats been the dilemma all these years.
If "policy" means that destinations "must" or "should" (in the RFC 2119 sense) *do* what the Author Domain publishes as policy, both as an MLM developer and as a user of the Internet I can't support a "policy concept". Of course, this is what "policy" means in most everyday contexts, so it's easy to get confused. If "policy" means that Author Domains can publish information about their particular circumstances vis-a-vis various threats that exist, associated with recommendations (BCP) for disposition of messages that meet (or fail to meet) various criteria in those particular circumstances, along with discussion of how blindly following rules can hork the whole 'net, of course I'm all for it. > However, I find it hard to understand how the advocates of DMARC > are not pushing for 3rd party solutions. Thats the odd thing about > it. Most advocates of DMARC have no need for 3rd party solutions. They are concentrating on transactional, direct mailflows, and where they need indirect mailflows, it seems that they have little trouble establishing sister domains with appropriate DMARC policies for those exceptional mailflows. AFAIK even the "we know better than DMARC" services like Gmail *reject* when these domains publish "p=reject". The heavy DMARC users whose use of p=reject are causing problems for third parties aren't really experiencing much pain themselves, or at least the concentrated attacks in April were *much* more painful. A few users complain, but the services have plausible deniability and their users' hate for spam to protect them from mass revulsion, let alone revolution. I doubt they consider it their business to develop such solutions, especially since they say they are still under attack, and presumably are experiencing new forms of attack all the time. The third parties who *do* have an interest in "real" solutions didn't have time to develop one in April, let alone persuade the many DMARC participants to implement it. Most MLM users, for example, are quite nontechnical, and have little experience with the issues that the IETF has to grapple with in creating a viable *standard* solution. Nor do we trust, specifically, Yahoo! and AOL to adopt one if it existed. At least at Mailman we have a long history of users suffering from their arbitrary decisions and inflexible policies, and we don't believe that they will adopt a standard solution even if one were created. The Mailman community has little incentive and less optimism for pushing for standardized "third-party solutions". (Not to mention that IETF standardization processes are considered arcane and slow.) Note: Above in referring to "Mailman", I'm reporting the general opinion of the Mailman community. I am personally hopeful, after interacting with technical staff at Yahoo!, that Yahoo! will play along (but I'm sure it will take time). I don't have the same confidence about AOL (no similar interaction), but I suppose that they won't want to be odd man out if Yahoo! participates. (As for IETF standardization, I'm here, OK? :-) And I'm saying those things to the Mailman folks, too. But it's going to take time to convince them. > If the new DMARC advocates and DKIM Policy Marketing was as strong > during SSP/ADSP, the original proof of concept with DKIM, we > probably would of solved this problem long ago and MLM/MLS systems, > including our own MLS product, would be better off without the > radical rewriting hacks suggestions. They're not "suggestions". They're de facto BCP. You need to wrap your head around that fact. No, they're not good. In fact, they suck badly in my opinion, and as you know I've argued against suggestions like "List-Original-Author" that encourage and enable them. But they *are* in wide use and nobody has come up with a better idea we can use *now* -- they are indeed *best* *currently*. Denying that just confuses the heck out of the rest of us. Sincere regards, Steve _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
