-----Original Message-----
From: ietf [mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Hector
Santos
Sent: Tuesday, April 15, 2014 1:39 PM
To: dcrocker(_at_)bbiw(_dot_)net; 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