> ADSP was brushed off because the same folks who believed ADSP's strong 
> reject/discard policy concept will ever get used, also believed DMARC's 
> strong 
> p=reject will never be used as well, and certainly not by the likes of a 
> AOL.COM 
> and YAHOO.COM, two aged and polluted domains like millions of others who
>  would major interesting in improving the security quality and brand of their 
> domains.

Correct me if I am wrong, but I think that there are significant differences 
between now and when ADSP was being investigated:

1. DKIM has much more prevalence in 2014 than it did in 2006, so requiring it 
today isn't as big an obstacle.

2. DKIM doesn't tie the d= signature field to the 5322.From: address. So, you 
can DKIM-sign all you want and add authorized third party signatures all you 
want. But if the From: address is different than what was authenticated, then 
the end user won't understand the difference.

3. DMARC is basically an anti-phishing technology, whereas while DKIM + ADSP 
can do that, it doesn't do it as well. It's less intuitive to end users. And 
because DMARC is better for anti-phishing, I would guess that's why it has much 
better traction that ADSP ever could. Speaking for a large(ish) email provider, 
DKIM is good but stopping phishing is better.

-- Terry

-----Original Message-----
From: Hector Santos [mailto:hsan...@isdg.net] 
Sent: Thursday, April 24, 2014 10:44 AM
To: Terry Zink; Greg Colburn
Cc: Michael Storz; dmarc@ietf.org; DMARC Discuss
Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject'

On 4/24/2014 12:44 PM, Terry Zink wrote:
>>> On Apr 24, 2014, at 3:46 AM, Hector Santos <hsan...@isdg.net> wrote:
>>>
>>> change ADSP to DMARC below at the IETF RFC Status change link.
>>> Technically, it is still almost no deployment, just a few BIG guys!!
>>>
>>>
>>> Hector
>
>> I challenge your assertion that there is "almost no deployment".  In 
>> the past
>> 3 days at Return Path we're received reports from 147 unique ISPs, 
>> companies, etc.
>>
>> Greg Colburn
>
> I agree with Greg. Large ISPs like DMARC. I suspect that the smaller players 
> like mailing-list-operators (and other 
> non-compliant-yet-valid-email-scenarios) will be forced to work with, or 
> around, DMARC before DMARC is abandoned by large operators.
>
> --Terry

It was mostly tongue in cheek.

I understand DMARC has caught on. I was never against DMARC, but the fact that 
it was repeating nearly 9+ years of work in what ADSP was already doing (except 
reporting), and ADSP was indeed the IETF proposed standard track item, made 
this all issue really surreal.  It didn't need to happen.  It was coming and 
all the policy advocates were believers of it.  But before DMARC, there was SSP 
and ADSP and ADSP had to be pushed aside (made HISTORIC this year) in order to 
clear the path for DMARC.  I accept that.

We went through the many of IETF-MAN-YEARS engineering the issues DKIM 
+ POLICY layer had, namely, that middleware would need to (software)
adapt to new AUTHOR DOMAIN POLICY controls   However, the opponents of 
these new policy protocols did not support it for the most part and held it 
back from moving forward.  It was abandoned in the DKIM-WG, left unfinished.

In short, DMARC did not learn from what happen with DKIM+ADSP and as a result 
we had these "new surprises" for the IETF. It was a total lost of control of 
the IETF getting in front of this technical mail integration issue known since 
2006 with my DSAP I-D, and Murray's 2011
RFC6377 with similar guidelines when I had reminded people again of the 
potential problems!!

   DKIM Signature Authorization Protocol (DSAP)
   http://tools.ietf.org/html/draft-santos-dkim-dsap-00

   DomainKeys Identified Mail (DKIM) and Mailing Lists
   https://tools.ietf.org/html/rfc6377

And I was all ready to go a 2006 IETF meeting to push POLICY with this
presentation:

   http://www.winserver.com/public/ssp/DSAP-00.pdf

So if there was ever strong believers in a DKIM POLICY layer and framework, I 
was among them.

ADSP was brushed off because the same folks who believed ADSP's strong 
reject/discard policy concept will ever get used, also believed DMARC's strong 
p=reject will never be used as well, and certainly not by the likes of a 
AOL.COM and YAHOO.COM, two aged and polluted domains like millions of others 
who would major interesting in improving the security quality and brand of 
their domains.

As one of the strongest advocates of DKIM POLICY in the IETF, I am in full 
support of DMARC's growing adoption.  Years were spent on ADSP, but if we can 
finally get a DKIM PAYOFF with DMARC, then I'm all for it.  Its the "language 
of choice."

That said, as a total mail system developer, I must also make sure that we 
support the Mailing Listing software can properly fit into the 
DKIM+POLICY model.  We already did it with DKIM+ADSP+ATPS support -- a
list will not allow subscriptions from restrictive ADSP policies.  We will now 
add DMARC to the framework.

The only thing we need to do is add 3rd party semantics to DMARC to allow the 
mailing list system to better co-exist and its done for the most part.

You will not get an argument from me that DKIM is the finally a winner 
with a growing market of DMARC p=reject.   I hope the Crockers, 
Levines et al, all finally realize that Author Domain Policies are real and can 
co-exist with 3rd party Trust layers, and all the 3rd party trust vendors 
should be pushing hard for policy and use it as a carrot to get customers.

--
HLS


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to