> -----Original Message----- > From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Hector Santos > Sent: Tuesday, April 15, 2014 1:39 PM > To: dcrocker@xxxxxxxx; Brian E Carpenter; IETF Discussion > Subject: Re: What I've been wondering about the DMARC problem > > On 4/15/2014 11:49 AM, Dave Crocker wrote: > > On 4/14/2014 6:45 PM, Brian E Carpenter wrote: > >> I thought that standard operating procedure in the IT industry > >> was: if you roll something out and it causes serious breakage to some > >> of your users, you roll it back as soon as possible. > >> > >> Why hasn't Yahoo rolled back its 'reject' policy by now? > > > > > > As the most-recent public statement from Yahoo, this might have some > > tidbits in it that are relevant to your question: > > > > > > > > http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc- > policy > > -to-protect-our-users > > Thanks for the link. > > Yes, it does provide some insight, but it would be nice if YAHOO made an > official statement to provide vendors with planning decisions. > Just curious, what sort of statement would you like to see? How would it help with vendor planning decisions? > This is GOOD NEWS. > > What it means that POLICY has won. I believe a policy-based DKIM > framework is best and I invested in ADSP and its extensions. Many > never believed in ADSP or policy based protocols but you have changed your > position and now promote DMARC as the way to go. Thats great Dave. > I've believed in policy for quite some time (pre-dating SSP/ADSP). The only problem with ADSP was that we agreed to a compromise that left it too inflexible and crippled. Lesson learned. > But as I have been saying and largely ignored, it didn't still solve the problem > unless the MLM supported the handling of restricted policies as well -- > gracefully. It doesn't matter if its ADSP or DMARC. > > Yahoo has FORCE the issue so in that way, I am happy. > > What it means is that I will now begin exploring DMARC implementation into > our already laid out DKIM framework using ADSP. Maybe we can finally get > some payoff and value from all this DKIM work after all!! > I'm looking forward to hearing your thoughts and questions and I'm sure others do as well. Is this list the best place for this or is there somewhere else more appropriate? > I have to note the yahoo.com impact on our system was low. The few > yahoo.com accounts in our support list was down to four and this was going > on since January with no complaints. But the fact, Yahoo hasn't roll back or > relaxed its policy in over 4 months, DMARC is probably here to stay now!! > Hector, Yahoo implemented the change a week ago Friday, not 4 months ago. I'm sure they have received complaints. I'd love it if at some later point someone that was involved in the Yahoo decision process writes something about the events that started them thinking about making the change and the decision making process involved. It would be nice to have insight into how and why they decided to go ahead without giving anyone prior notice. How did it impact customer support and what kind of plan was in place (and how well did it work)? How did they deal with partners and vendors? In other words it would be a compelling case study whether one thinks their action was good or horrible. > As the Jeff says: > > "With stricter DMARC policies, users are safer, and the > bad guys will be in a tough spot. More importantly, > verified senders will unlock a massive wave of innovation > and advancement for all our inboxes." > > Its time for the IETF to support DMARC. We can do this using DMARC > Extensions. Maybe Murray can consider writing DMARC extensions like ATPS > but using DMARC as the base call. It should be a minor change to the ATPS > specs. > > I can see additional DMARC extensions for other advancements, but the > main one is about managing 3rd party authorized domain to satisfy the > "signing/sent on behalf of" design need that yahoo says is required: > On one level there already are ways for satisfying the 3rd party authorized domain issue. A domain could use SPF (either by specifying hosts/IPs or using an include in the SPF record) for a 3rd party domain. Another method would be to provide DKIM signing keys to the 3rd party. Yet a 3rd way is to delegate a subdomain so that the 3rd party can manage these things on their own. There are some best practice documents published at maawg.org that might be useful. If what you mean is a mechanism to specify random 3rd parties that an end user wishes to use, then no there is not a mechanism and I don't know of anyone who has put forth what I would consider a workable model. > "Yahoo requires external email service providers, such as > those who manage distribution lists, to cease using unsigned > “sent from” mail, and switch to a more accurate “sent on > behalf of” policy." > > What is this so called "more accurate" method? > Not sure exactly what he means. Mike