On 4/8/2015 9:47 PM, Steve Atkins wrote:
On Apr 8, 2015, at 5:32 PM, John R Levine <jo...@taugh.com> wrote:
So why is DMARC any more useful than these "hacks"?
Good question. As originally intended, DMARC was for mail from sources where a
failure reliably meant phish. Then AOL and Yahoo repurposed it to push their
support costs onto other people, and its value has been under debate ever since.
Also a major reason that people who were dubious about SPF policy and extremely
dubious about ADSP supported DMARC was that it has reporting and dry run
functionality. Run it in p=none mode; use the reports to make sure that nothing
breaks; if nothing breaks switch to p=reject.
I didn't think that anyone significant would skip the testing, reporting and
decision making steps and leap directly to intentionally breaking email for
their users their users' correspondents.
I don't think this is a fair assessment. Obviously for many, it was
expected for a DKIM+POLICY to prevail in the market place where
publishers will expose strong rejection policies and receivers will
begin to honor it. DKIM+POLICY (ADSP) was a standard track IETF WG
work item with many RFC documents produced. Investments were done.
APIs were written. After all, Yahoo invented the idea with Domainkeys
with its built-in "o=" policy tag, so we should not be surprise Yahoo
was also the first to finally enable it abeit after 10 years evolution
to DKIM+DMARC. What ADSP did not have was a reporting feature. It
might had changed its fate. DMARC is fundamentally no different than
ADSP otherwise.
DKIM+ATPS should not be a problem for most domains. Not everyone is a
YAHOO and even then, I don't think they should have a problem managing
"50,000" list domain records, if that is their maximum exposure to this.
If you look at the ideas, ATPS is the least expensive. All the others
have the same scale issue for the domain needing to authorize a larger
list of domains. And they also have a higher change requirement at
three locations; signers, receivers and middle ware. In Levine's
idea, the middle ware MUST NOT remove the weak 1st party signature.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
