Re: What I've been wondering about the DMARC problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hector Santos wrote:
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.

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.

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 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!!

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:

   "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?

And more to the point - what is a standard for representing "sent-on-behalf-of" that software developers can rely on when making changes to list software and user agents. (Or even better, a way to represent it that allows standard reply and address functions to continue working tranparently).

--
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]