Subject: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject'

From: Michael Storz <[email-masked]>
Date: Wed, 23 Apr 2014 14:59:27 +0200

Just saw it in my logs. You find the announcement at

http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/

-- 
Michael

---

From: Tony Hansen <[email-masked]>
Date: Thu, 24 Apr 2014 00:37:41 -0400

> http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ 

And I saw a dmarc rejection this morning from a comcast address.

     Tony Hansen

---

From: Hector Santos <[email-masked]>
Date: Thu, 24 Apr 2014 05:46:36 -0400

> http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/

So much for the theory that DKIM ADSP-like strong policies would never 
be used by big operations!  And the irony, the IETF had just made ADSP 
historic for this theory of "special case no one will use," and for 
same interop mailing list problem.  Maybe its time to make DMARC 
historic too before it even gets a RFC!  All that needs to be done is 
change ADSP to DMARC below at the IETF RFC Status change link. 
Technically, it is still almost no deployment, just a few BIG guys!!

                              ------------------
https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/

RFC Status Change : Change the status of ADSP (RFC 5617) to Historic

ADSP has garnered almost no deployment and use in the 4 years since its
advancement to IETF Proposed Standard.  While there are 
implementations in code,
there is very little deployment and no evidence of the benefits that were
expected when the standard was written.

There is, however, evidence of harm caused by incorrect configuration 
and by
inappropriate use.  There have, for example, been real cases where a 
high-value
domain published an ADSP record of "discardable", but allowed users on
their domain to subscribe to mailing lists.  When posts from those 
users were
sent to other domains that checked ADSP, those subscriber domains 
rejected the
messages, resulting in forced unsubscribes from mailman (due to 
bounces) for the
unsuspecting subscribers.

Assurances that are provided by ADSP are generally obtained out of 
band in the
real Internet, and not through ADSP.  Current deployment of ADSP is not
recommended.
                              ------------------

-- 
HLS

---

From: Greg Colburn <[email-masked]>
Date: Thu, 24 Apr 2014 10:39:29 -0600

> 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

---

From: Terry Zink <[email-masked]>
Date: Thu, 24 Apr 2014 16:44:40 +0000

> 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

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 24 Apr 2014 18:56:46 +0200

On Thu, Apr 24, 2014 at 10:39:29AM -0600, Greg Colburn wrote:
> 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.

And of course there are only about 150 ISPs.  147 really is "a few".

Kurt

---

From: Tony Hansen <[email-masked]>
Date: Thu, 24 Apr 2014 13:34:07 -0400

> And I saw a dmarc rejection this morning from a comcast address.

Sigh

After re-reading the bounce message, it's a message going to comcast 
from a yahoo sender via a mailing list I manage.

So it's comcast applying the dmarc reject to yahoo addresses.

Sorry for the noise.

     Tony Hansen

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Apr 2014 10:24:03 -0700

> 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,…

Dear Terry,

Now that some Large ISPs (mis)apply DMARC p=reject on user accounts, perhaps it is time to update ATP to conform with DMARC rather than ADSP. ATP can enable third-party authorizations at higher rates more effectively and efficiently than by other protocols or technologies.  Once put into practice, other DMARC domains could share the authorizations necessary to avoid disrupting legitimate mailing-lists.  Doing so would lessen the burden of such policy now affecting tens of thousands of church and neighborhood organizations who depend on mailing-lists.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Thu, 24 Apr 2014 13:44:02 -0400

> 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,…

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

---

From: Terry Zink <[email-masked]>
Date: Thu, 24 Apr 2014 18:27:09 +0000

> 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:[email-masked]] 
Sent: Thursday, April 24, 2014 10:44 AM
To: Terry Zink; Greg Colburn
Cc: Michael Storz; [email-masked]; DMARC Discuss
Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject'

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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 24 Apr 2014 11:56:03 -0700

On Thu, Apr 24, 2014 at 11:27 AM, Terry Zink
<[email-masked]>wrote:

> Correct me if I am wrong, but I think that there are significant
> differences between now and when ADSP was being investigated:
>
> 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.
>

When we did ADSP (RFC 5617), the mailing list damage it could do was
considered a showstopper for the vast majority of everyone participating,
and advocates for "strong policy" were in the rough.  I note from ADSP's
author list that this included Yahoo!.  The recommended practice was to
split streams, so ADSP-protected mail was in one domain and user mail was
in another.  This is why domains like yahoo-inc.com, googlers.com,
paypal-inc.com, etc. began to appear.

It was still true when we revised DKIM a couple of years later, because the
concerns were unchanged yet yielded no relevant changes to DKIM itself, and
the working group produced RFC 6377 to document the problem in more detail
rather than take another run at trying to solve it.

What's changed since then appears to be that some operators now believe the
collateral damage is acceptable.

-MSK

---

From: Jim Fenton <[email-masked]>
Date: Thu, 24 Apr 2014 14:27:33 -0700

> 1. DKIM has much more prevalence in 2014 than it did in 2006, so requiring it today isn't as big an obstacle.
ADSP is published by the same domains that are deploying DKIM, so the
overall prevalence of DKIM isn't a factor.
> 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 differen…
But ADSP does tie the d= signature to the 5322.From domain, by virtue of
the fact that only signatures where d= matches the 5322.From domain
match are considered "author domain" signatures.
> 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'd like to understand why DMARC is "better for anti-phishing". But
let's not turn this into a DMARC-vs-ADSP argument. And in either case,
it shouldn't be intuitive to end users; it shouldn't even be visible to
them.

-Jim

---

From: "J. Gomez" <[email-masked]>
Date: Thu, 24 Apr 2014 23:39:44 +0200

On Thursday, April 24, 2014 6:44 PM [GMT+1=CET], Terry Zink wrote:

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

Large ISPs/ESPs like DMARC because they, by definition, are too-big-to-block so they can afford to offload the support costs of DMARC failure cases on the small email operators.

There where they happen not to be too-big-to-block, those ISPs/ESPs don't dare to indulge in such practices (confront yahoo.com vs yahoo.fr/yahoo.es DMARC policies).

They way for small email operators to "work with/around" that, is to not check DMARC for incoming email, to publish at most a DMARC policy of "none", and to stick to good old plain-SPF.

Regards,

J.Gomez

---

From: Franck Martin <[email-masked]>
Date: Thu, 24 Apr 2014 16:48:52 -0500 (CDT)

----- Original Message -----
> From: "Jim Fenton" <[email-masked]>
> To: [email-masked]
> Sent: Thursday, April 24, 2014 2:27:33 PM

> it shouldn't be intuitive to end users; it shouldn't even be visible to

ADSP did not provide any reporting. With failure reports and even aggregate reports the person most interested to stop the phishing (the brand), get the data to pursue the phish on a multitude of avenues.

>From  the old "a user reported a phish" to DMARC today "there has been 100k email phish caught by these providers", it changes your perspective and priorities.

---

From: Franck Martin <[email-masked]>
Date: Thu, 24 Apr 2014 16:51:48 -0500 (CDT)

----- Original Message -----

> From: "Murray S. Kucherawy" <[email-masked]>
> To: "Terry Zink" <[email-masked]>
> Cc: [email-masked], "Hector Santos" <[email-masked]>, "DMARC Discuss"
> <[email-masked]>
> Sent: Thursday, April 24, 2014 11:56:03 AM
> Subject: Re: [dmarc-discuss] [dmarc-ietf] FYI: AOL Mail updates DMARC policy
> to 'reject'

> author list that this included Yahoo!. The recommended practice was to split
> streams, so ADSP-protected mail was in one domain and user mail was in
> another. This is why domains like yahoo-inc.com , googlers.com ,
> paypal-inc.com , etc. began to appear.

> collateral damage is acceptable.

Finish the sentence... ;) 

"... in relation to the benefits while the ecosystem adapts"

---

From: Hector Santos <[email-masked]>
Date: Thu, 24 Apr 2014 18:17:02 -0400

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

I don't see this as any real point to be wrong or right, but DKIM was 
the direction then as well.

> 2. DKIM doesn't tie the d= signature field to the 5322.From: address.

This would be crux of the key philosophical debates and reason we have 
the problem you today.

First, 5322.From is the only hash binding header requirement for DKIM, 
so it is inherently technically impossible to untie or "separate" the 
two domains.

Second, what comes first the author (original message) or the signer? 
  I hope you say author. :)

Third, the tie-in was built into Domainkeys which DKIM was derived 
from with its own built-in expanded set of 1st and 3rd policies.  ADSP 
tried to reduced it to 1st party only. But since the beginning, the 
original proof of DKIM concept was the AUTHOR DOMAIN POLICY layer, the 
selling and marketing point.  That is why POLICY was also part of the 
DKIM-WG product work items, among its threat analysis and signing 
practice requirements, and also DKIM architecture.

The philosophy that the two domain are separate is exactly why we have 
the problem today.

>So, you can DKIM-sign all you want and add authorized third party 
signatures
>all you want.

No you can't just blinding resign mail. Its was always a bad idea to 
do so from a security and mail integration design standpoint.  You 
can't separate two.  Again, its why you have the DMARC problem today 
with list systems.

> But if the From: address is different than what was authenticated, then the end
>user won't understand the difference.

The goal of POLICY was to filter the obvious deterministic highly 
detectable fraud.  No subjective reason is required.  Its persistent 
and consistent. You say you do X, the receiver sees Y, there is 
something wrong. Your X says to reject.  The receiver honors it.   If 
you don't honor it, you are not compliant and are creating security 
loopholes and exploits.  Again, why DMARC was a problem with p=reject. 
  It was no surprise to anyone but those who believe that a strict 
policy was a small use case -- it was proven wrong.

> 3. DMARC is basically an anti-phishing technology, whereas while DKIM + ADSP can do that, it doesn't do it as well.

I don't see the difference.  This is a general DKIM + POLICY issue.

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Thu, 24 Apr 2014 12:33:01 -0700

Hi Terry,
At 11:27 24-04-2014, Terry Zink wrote:
>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

I don't recall the time line as it's been a long time.  ADSP tied the 
5322.From address to the "d=" tag.  ADSP was controversial (re. 
discussions about lost of mail, etc.).  Mail usage is not as 
prevalent as before.  The loss of mail might be considered as 
acceptable nowadays.  There's also the "cybersecurity" [1] angle.

Regards,
S. Moonesamy

1. 
http://www.spiegel.de/international/europe/british-spy-agency-gchq-hacked-belgian-telecoms-firm-a-923406.html