On 4/24/2014 12:44 PM, Terry Zink wrote:
On Apr 24, 2014, at 3:46 AM, Hector Santos <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
