Subject: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

From: Terry Zink <[email-masked]>
Date: Mon, 1 Apr 2013 21:15:15 +0000

Hi, everyone,

I am proposing an extension to DMARC. Whereas today DMARC requires one of a DKIM pass or SPF pass, I propose we extend DMARC so that is has the *option* to require both.

This is going to be a long post (sorry), but here's why:

My company (Microsoft Forefront) runs a shared service. Other companies like GoDaddy and MessageLabs would have similar issues. Because we are a shared service, a larger set of customers use our limited set of outbound IPs to relay email to the rest of the world. We scan this email for spam and take action appropriately if we find a company or user is sending too much of it.

Here's what it looks like with a set of fictional names if they were all our customers and were using us for outbound mail:

1. example.com ----+
                   |
2. BigBank.com ----+----> Microsoft Forefront IPs ----> Internet
                   |
3. Learning.edu ---+

Each of these customers would put the following into their SPF records:

"v=spf1 ip4:<their own IPs> ip4:<Microsoft IPs>"

This means that a message going from [email-masked] to [email-masked] would undergo two SPF checks:

1. The first is when example.com sends the message to us for relaying to the Internet. We look up the SPF record for example.com, see it is coming from example.com's IP range, and it passes the check.
2. The second is when the message arrives at [email-masked]. Hotmail looks up the SPF record for example.com, sees it is coming from Microsoft Forefront's IP range, and it passes the check.

In this scenario, everything is well and good.

We know every IP that is associated with each of our customers. However, we do not know every single domain associated with them. For example, BigBank.com might have the following sending domains:

- bigbank.com
- email.bigbank.com
- security.bigbank.com
- littlebank.com
- us.bigbank.com
- uk.bigbank.com
- cn.bigbank.com
- partner.com

And so forth. We may only know about bigbank.com (the customer goes into the admin portal and manually enters them in). Sometimes, bigbank.com will send email from [email-masked]. This is an acceptable scenario. We don't know about all their domains, but we scan the message and it is clean and so we relay it to the Internet. They've even set up their SPF record properly. This is not the only valid case when this occurs (sending mail from domains they have not told us about previously), but it is one of them.

In this scenario, everything is well and good. (As an aside, our internal data indicates that the majority of this type of "unattributed" mail is non-spam. I have to explain this to executives every time they want to shut it down every two years; this capability is very popular with customers).

Let's assume that BigBank.com has been dutiful and has published a DMARC record. The problem occurs when Learning.edu gets compromised and starts sending out spam. If a user starts sending out spam from [email-masked], we can detect this and shut it down. But what happens if they start sending out mail as [email-masked]? 

example.com ------------+
                        |
BigBank.com ------------+----> Microsoft Forefront IPs ----> Internet
                        |
Learning.edu            |
 [email-masked] --+
 
If this is a zero-day attack, when the message hits Microsoft, we may not detect it as spam and it gets relayed to the outside world (perhaps BigBank.com uses a ~all in their SPF record). What happens when it hits Hotmail? Well, Hotmail performs a DMARC check.

There's no DKIM record, so Hotmail performs an SPF check on BigBank.com. It sees that the mail came from Microsoft Forefront's IPs, and lo-and-behold, Microsoft Forefront's IPs are listed in BigBank's SPF record! Therefore, this passes a DMARC check.

But it shouldn't have passed! Not only should this have failed, it's worse than failing because Hotmail believes that this message *is* from BigBank.com but it's a spoofed message! Shared services are susceptible to this problem.

And this is why I propose an optional extension to DMARC. Rather than DMARC requiring SPF or DKIM, what if DMARC let a domain specify SPF *and* DKIM? Let's look through what would happen in my above example:

1. Hotmail performs an SPF validation on BigBank.com and it passes, even though it really came through a compromised account from learning.edu.
2. Hotmail performs a DKIM validation on BigBank.com and it fails because learning.edu does not know BigBank's private DKIM key.

However, since BigBank.com says both SPF and DKIM must pass, this will fail a DMARC validation. This is the case we want to catch - spoofing of users behind shared IP space.

I propose we extend the DMARC specification by extending the syntax. From http://dmarc.org/draft-dmarc-base-00-02.txt, section 6.2:

   adkim:  (plain-text; OPTIONAL, default is "r".)  Indicates whether or
      not strict DKIM identifier alignment is required by the Domain
      Owner.  If and only if the value of the string is "s", strict mode
      is in use.  See Section 4.2.1 for details.

   aspf:  (plain-text; OPTIONAL, default is "r".)  Indicates whether or
      not strict SPF identifier alignment is required by the Domain
      Owner.  If and only if the value of the string is "s", strict mode
      is in use.  See Section 4.2.2 for details.

We could do something like add the letter "p" which means that the mechanism *must* pass. So, if BigBank.com had the following:

adkim=p aspf=p

It would mean that the domain BigBank.com requires both DKIM and SPF to pass, and they are both in relaxed mode since it defaults to r. Or we could make this explicit:

adkim=rp aspf=rp

...where the first letter is strict vs. relaxed identifier alignment and the second is whether or not it must pass.

Extending DMARC this way lets brands/domains protect their outbound reputation behind a shared service without worrying whether or not some other customer will spoof them.

Make sense?

-- Terry Zink | Program Manager - Antispam | My Antispam Blog

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Apr 2013 14:57:47 -0700

Terry,

On 4/1/2013 2:15 PM, Terry Zink wrote:
> I am proposing an extension to DMARC. Whereas today DMARC requires
> one of a DKIM pass or SPF pass, I propose we extend DMARC so that is
> has the*option*  to require both.

The draft working group charter that Murray just circulated would make
this effort out of scope, since it explicitly prohibits protocol 
enhancement.

Are you suggesting a change to the draft charter?

An alternative might be to find a way for this example scenario to
provide the basis for some discussion, in the draft BCP, about the
proper limits of DMARC.  It wouldn't solve your protocol problem, but it 
might provide good pedagogy.

Perhaps there are other alternatives?

> Let's assume that BigBank.com has been dutiful and has published a
> DMARC record. The problem occurs when Learning.edu gets compromised
> and starts sending out spam. If a user starts sending out spam
> [email-masked], we can detect this and shut it down. But what
> happens if they start sending out mail [email-masked]?

I tend to draw a distinction between protection against internal
problems, versus protection against external ones.  Internal means that
the misbehavior is caused by an activity within the administrative scope
of the entity needing protection.  External means that the problem
behavior comes from some other administrative scope.

The usual examples of the distinction are misbehaviors by a department,
within the company owning the domain name, versus misbehavior from a
classic spammer who is using the domain name without authorization. On
the average, the tendency has been to pursue standardization that
protect against external threats rather than internal ones. Internal
ones are thought to be best handled... internally.

> 2. BigBank.com ----+----> Microsoft Forefront IPs ----> Internet

The scenario you give might be considered as internal misbehavior, since 
there is a contractual relationship between Forefront and the sources of 
messages that you list.  That is, the essence of the challenge is for 
Forefront to have mechanisms that distinguish what mail is authorized 
from what source, and what mail isn't.  Per your example, it would 
require that it enforce its /own/ dmarc-ish policy to require that mail 
it is relaying for learning.edu be attributed to learning.edu, and so on.

If I understand your note correctly, the problem that you cite with this 
is that Forefront doesn't know all of the acceptable domains for a given 
customer.  Wouldn't it make more sense to fix this issue, rather than 
change the public standard and burden all recipients with the added 
complexity in software and operations?

Without have thought about it much, I suspect that one approach to 
fixing this is for Forefront to /privately/ assert the type of dmarc-ish 
enhancement that you propose.  That is, impose the requirement on its 
customers, thereby assuring that the mail it is relaying to the public 
Internet is 'safe', at least along this one line of concern.

d/
-- 
  Dave Crocker
  bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 1 Apr 2013 22:17:02 -0000

>Extending DMARC this way lets brands/domains protect their outbound reputation behind a shared service without worrying
>whether or not some other customer will spoof them.
>
>Make sense?

Well, no.

Your problem as I understand it is that you have a shared
infrastructure accessed by untrusted clients, and you want to defend
against the threat that one client sends mail impersonating another.

The DKIM signatures are secure, a client can only sign for itself, but
there's no way to map an IP address to a particular sender.

The solution here is quite simple: adjust the SPF records to reflect
what's actually going on.  An SPF pass means, approximately, yes this
message is really from the alleged sender.  But you can't say that,
you can only say that it might be or it might not be.  So an
appropriate SPF record would be something like this (using a handful
of the of Frontbridge IP ranges as an example):

bigbank.com txt "v=spf1 ?ip4:157.55.158.0/23 ?ip4:157.55.234.0/24 ?ip4:157.56.112.0/24 ~all"

Those question marks in the record on the Frontbridge ranges make them
neutral rather than pass, which is appropriate in this case.  Since
all of the real mail the client sends through your system will have a
DKIM signature, it will still pass DMARC.

If the bank has its own private ranges for its non-bulk mail, those
could go in as SPF pass, e.g.

bigbank.comm txt "v=spf1 +ip4:22.22.22.22 ?ip4:157.55.158.0/23 ?ip4:157.55.234.0/24 ?ip4:157.56.112.0/24 ~all"

Remember that a major point of DKIM is to attach an identity to mail
that is independent of the mail's path.  DKIM currently works just
great for the usual kinds of forwarded mail.  If you insist on both
SPF and DKIM, you lose the path independence and break the forwarding
while gaining nothing, since the DKIM signature still tells you what
you need to know.  If the bank sends its own unsigned mail through its
own mail servers, the SPF record reflects that, and it'll pass DMARC,
too (give or take the known SPF forwarding issues.)

Bonus advantage of this approach: existing software supports it now,
no upgrades needed.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 1 Apr 2013 23:01:13 +0000

Comments in-line.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dave Crocker
> Sent: Monday, April 01, 2013 5:58 PM
> To: Terry Zink
> Cc: [email-masked]
> Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally
> require SPF and DKIM
> 
> Terry,
> 
> one
> > of a DKIM pass or SPF pass, I propose we extend DMARC so that is has
> > the*option*  to require both.
> 

This is a bad idea. While it solves your internal problem it potentially increases false positives for bigbank.com externally, thus trading one problem for another. I've been implementing SPF (ending with -all) and DKIM with private channel assertions since the end of 2007. One of the reasons for using the combination of SPF and DKIM ( and requiring only one to pass) is the reduction of false positives. 

Before trying to extend DMARC to account for internal problems - as Dave points out - I would look for other ways of resolving the problem. As I have said many times regarding email authentication implementation, one needs to get control of their mail flows. That is true in this case. If bigbank.com cannot control it's managers/employees and how they send mail then that is an internal problem that bigbank needs to address. There are plenty of other mechanisms for bigbank to control what it emits (in the case of spam). Perhaps MS should offer bigbank dedicated IPs - ESPs do this all the time for their customers. It may not be so critical for other customers. Sounds like a business opportunity to me.

> The draft working group charter that Murray just circulated would make this
> effort out of scope, since it explicitly prohibits protocol enhancement.
> 

I prefer to avoid relying on limitations in the charter and focusing on the merits which IMHO don't rise to a level justifying this extension. One of the key merits of DMARC is that it focuses on solving a particular problem and based on the data it does that very well.

> An alternative might be to find a way for this example scenario to provide the
> basis for some discussion, in the draft BCP, about the proper limits of
> DMARC.  It wouldn't solve your protocol problem, but it might provide good
> pedagogy.
> 

This sounds like a good idea.

> > happens if they start sending out mail [email-masked]?

It sounds like someone needs btter internal controls to prevent this.

> I tend to draw a distinction between protection against internal problems,
> versus protection against external ones.  Internal means that the
> misbehavior is caused by an activity within the administrative scope of the
> entity needing protection.  External means that the problem behavior comes
> from some other administrative scope.
> 

+1

> classic spammer who is using the domain name without authorization. On the
> average, the tendency has been to pursue standardization that protect
> against external threats rather than internal ones. Internal ones are thought
> to be best handled... internally.
> 
> > 1. example.com ----+
> >                    |
> messages that you list.  That is, the essence of the challenge is for Forefront
> to have mechanisms that distinguish what mail is authorized from what
> source, and what mail isn't.  Per your example, it would require that it
> enforce its /own/ dmarc-ish policy to require that mail it is relaying for
> learning.edu be attributed to learning.edu, and so on.
> 
> If I understand your note correctly, the problem that you cite with this is that
> Forefront doesn't know all of the acceptable domains for a given customer.
> Wouldn't it make more sense to fix this issue, rather than change the public
> standard and burden all recipients with the added complexity in software
> and operations?
> 

+1

> Without have thought about it much, I suspect that one approach to fixing
> this is for Forefront to /privately/ assert the type of dmarc-ish enhancement
> that you propose.  That is, impose the requirement on its customers, thereby
> assuring that the mail it is relaying to the public Internet is 'safe', at least
> along this one line of concern.
> 
>

---

From: "John Levine" <[email-masked]>
Date: 1 Apr 2013 23:02:14 -0000

>complexity in software and operations?

That's also a good idea.  

It'd make sense to change the SPF records now, then if they can fix
the internal systems so that they have the domains on injected mail
under control, they could change the SPF back to make stronger
assertions.

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 2 Apr 2013 01:15:02 +0200

On Monday, April 01, 2013 11:15 PM [GMT+1=CET], Terry Zink wrote:

> has the *option* to require both.  
>
> (...)
>
> and starts sending out spam. If a user starts sending out spam from
> [email-masked], we can detect this and shut it down. But what
> happens if they start sending out mail as [email-masked]?    
> 
> (...)
> Extending DMARC this way lets brands/domains protect their outbound
> reputation behind a shared service without worrying whether or not
> some other customer will spoof them.  
> 
> Make sense?

I does make sense. I also like the explanation in your blog:

http://blogs.msdn.com/b/tzink/archive/2012/10/18/how-should-large-financial-institutions-use-hosted-filtering.aspx

In a multitenant cloud environment, and/or when you are giving customers a MTA-smarthost service to gateway their mail to the Internet, you cannot be sure that they will always be signing their email with DKIM, and you usually will not have their private DKIM keys to sign their email yourself as it flows through the smarthost towards the Internet, so taking the DMARC oportunity to close this hole in SPF is golden.

When we will all be on IPv6, and sharing IPs will be a thing of the past, this will be a non issue. But it is an issue now, and will be even a bigger issue as we remain in IPv4 and more and more things move to the cloud. Your proposal for DMARC would solve this problem scenario of SPF just fine.

Also, your proposal has more benefits:

-- makes DMARC more resilient in case any of its underliying authentications mechanisms becomes compromised/broken/moot in the future.
-- future is hard to predict, this would build into the DMARC specification an optional more strict authentication threshold which may be useful in the future.

As to how to fit your suggestion in the syntax of the DMARC record, I would add an additional (and optional) tag to the specification, "m=" (mechanisms required to pass) with the possible values of "all" and "any", where "all" would require all the mechanisms of DMARC to pass for a DMARC pass itself to be gotten, and where "any" would be the default.

Regards,

J. Gomez

---

From: Franck Martin <[email-masked]>
Date: Mon, 1 Apr 2013 23:28:03 +0000

On 4/1/13 4:15 PM, "J. Gomez" <[email-masked]> wrote:

>In a multitenant cloud environment, and/or when you are giving customers
>a MTA-smarthost service to gateway their mail to the Internet, you cannot
>be sure that they will always be signing their email with DKIM, and you
>usually will not have their private DKIM keys to sign their email
>yourself as it flows through the smarthost towards the Internet, so
>taking the DMARC oportunity to close this hole in SPF is golden.

Google apps, send grid, messagebus, (and many other ESPs) do not have
problem to create a DKIM key for each customer, to sign the emails that
pass through them. We used to have open-relays because they were easy to
setup/manage, but we moved away from them because they were insecure.

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 2 Apr 2013 02:26:01 +0200

On Tuesday, April 02, 2013 1:28 AM [GMT+1=CET], Franck Martin wrote:

>>> BigBank.com ------------+----> Microsoft Forefront IPs ---->
>>>                         Internet |
>>> Learning.edu            |
>>>  [email-masked] --+
>>> 
>>> (...)
>>> 
>> In a multitenant cloud environment, and/or when you are giving
>> customers a MTA-smarthost service to gateway their mail to the
>> Internet, you cannot be sure that they will always be signing their
>> email with DKIM, and you usually will not have their private DKIM
>> keys to sign their email yourself as it flows through the smarthost
>> towards the Internet, so taking the DMARC oportunity to close this
>> hole in SPF is golden. 
> 
> problem to create a DKIM key for each customer, to sign the emails
> that pass through them. We used to have open-relays because they were
> easy to setup/manage, but we moved away from them because they were
> insecure. 

If your worry is moving away from insecure, then Terry Zink's proposal is just making DMARC more secure, as it is raising the bar on the mechanisms that have (optionally) to concur to obtain a DMARC-pass.

Apart from that, you would need to control your client's DNS to sign their DKIM in their behalf, and that only works with very small clients which lack in-house technical people and outsource the whole thing to you. But if you want to have clients of medium size which gateway their mail to the Internet through your cloud service, good luck getting their technical people to surrender their administrative control of their DNS to you.

I would like to hear, instead of suggestions for Terry to "fix" his infrastructure and his business model, some contributions as to why his proposal is detrimental to the goals of DMARC.

Regards,

J. Gomez

---

From: Franck Martin <[email-masked]>
Date: Tue, 2 Apr 2013 00:31:30 +0000

On 4/1/13 5:26 PM, "J. Gomez" <[email-masked]> wrote:

>>>http://blogs.msdn.com/b/tzink/archive/2012/10/18/how-should-large-financ
>>>ia
>>> l-institutions-use-hosted-filtering.aspx
>>> 
>If your worry is moving away from insecure, then Terry Zink's proposal is
>just making DMARC more secure, as it is raising the bar on the mechanisms
>that have (optionally) to concur to obtain a DMARC-pass.
>
>Apart from that, you would need to control your client's DNS to sign
>their DKIM in their behalf, and that only works with very small clients
>which lack in-house technical people and outsource the whole thing to
>you. But if you want to have clients of medium size which gateway their
>mail to the Internet through your cloud service, good luck getting their
>technical people to surrender their administrative control of their DNS
>to you.
>

We do that all the time with sub domains. Don't see where is the issue.

---

From: Terry Zink <[email-masked]>
Date: Tue, 2 Apr 2013 00:31:40 +0000

Thanks for the responses, everyone. I am going to respond to them one at a time but combine multiple email responses.

John Levine:

> Those question marks in the record on the Frontbridge ranges make them neutral rather than pass, 
> which is appropriate in this case.  Since all of the real mail the client sends through your 
> system will have a DKIM signature, it will still pass DMARC.
> 
> If the bank has its own private ranges for its non-bulk mail, those could go in as SPF pass, e.g.
> 

BigBank.com puts both Frontbridge/Forefront's IPs into its SPF records as well as its own IPs. We validate BigBank.com's IPs when it hits us the first time, and then 3rd parties validate our IPs when it hits them. 

But yes, I think you understand our issue (I think).

> If you insist on both SPF and DKIM, you lose the path independence and break the forwarding 
> while > gaining nothing, since the DKIM signature still tells you what you need to know.  
> If the bank sends its own unsigned mail through its own mail servers, the SPF record reflects 
> that, and it'll pass DMARC, too (give or take the known SPF forwarding issues.)

You are correct that you lose the path independence. But it is incorrect to say you gain nothing - you gain the ability to say "Nobody else can spoof me." Shouldn't it be the choice of the sender whether or not they want to make this assertion and subsequent trade-off?

-- Terry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
Sent: Monday, April 01, 2013 4:02 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

>If I understand your note correctly, the problem that you cite with 
>this is that Forefront doesn't know all of the acceptable domains for a 
>given customer.  Wouldn't it make more sense to fix this issue, rather 
>than change the public standard and burden all recipients with the 
>added complexity in software and operations?

That's also a good idea.  

It'd make sense to change the SPF records now, then if they can fix the internal systems so that they have the domains on injected mail under control, they could change the SPF back to make stronger assertions.

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Franck Martin <[email-masked]>
Date: Tue, 2 Apr 2013 00:37:19 +0000

On 4/1/13 5:31 PM, "Terry Zink" <[email-masked]> wrote:

>Thanks for the responses, everyone. I am going to respond to them one at
>a time but combine multiple email responses.
>
>John Levine:
>
>>neutral rather than pass,
>> bigbank.comm txt "v=spf1 +ip4:22.22.22.22 ?ip4:157.55.158.0/23
>>?ip4:157.55.234.0/24
>> ?ip4:157.56.112.0/24 ~all"
>
>BigBank.com puts both Frontbridge/Forefront's IPs into its SPF records as
>well as its own IPs. We validate BigBank.com's IPs when it hits us the
>first time, and then 3rd parties validate our IPs when it hits them.
>
>You are correct that you lose the path independence. But it is incorrect
>to say you gain nothing - you gain the ability to say "Nobody else can
>spoof me." Shouldn't it be the choice of the sender whether or not they
>want to make this assertion and subsequent trade-off?
>

We did SPF or DKIM because both were not solving the problem on their own.
So both combined together has all the advantages less the inconveniences.

If you want to say, nobody else can spoof me, then you can do SPF -all,
but then no large receiver never really trusted this policy assertion.
Also, you can put a DMARC record and SPF and not DKIM sign, you will get
the same benefits.

---

From: Terry Zink <[email-masked]>
Date: Tue, 2 Apr 2013 00:45:36 +0000

Hi, Mike.

> This is a bad idea. While it solves your internal problem it potentially increases false 
> positives for bigbank.com externally, thus trading one problem for another

I agree that there is the potential for false positives. But shouldn't this choice be given to the sender? If they understand the risks then they should be able to say "Yes, this can cause false positives. But we can get those under control (or delegate sub-domains for third parties, or some other workaround like using DMARC to collect feedback on where the unsigned mail originates). The bottom line is we don't want anyone spoofing our domain."

> If bigbank.com cannot control it's managers/employees and how they send mail then that 
> is an internal problem that bigbank needs to address. There are plenty of other 
> mechanisms for bigbank to control what it emits (in the case of spam). 

True enough. But it happens with regularity. At a large company, people move on all the time. Groups change and people retire, change jobs, or otherwise move on. The people in charge of maintaining all this IT stuff do not keep pace with the scope of change. This is especially true in a large organization (it is one of our own challenges).

But even beyond that, it's not the only legitimate case we have to deal with. We have companies like real estate companies (e.g., Remax -- if they were a customer) that have independent sales agents. The inbound mail is [email-masked]. The independent agent gets the mail forwarded to their personal email account and then they send outbound mail through us [email-masked]. Remax does not own yahoo.com, but this is a legitimate case where a user "spoofs" a legitimate domain that they do not own.

Thus, shutting down this case is not going to work. The majority of the mail from "legitimately spoofed" senders is non-spam. But the cases of spoofing a domain maliciously is what I want to target.

> Perhaps MS should offer bigbank dedicated IPs - ESPs do this all the time for their customers. 
> It may not be so critical for other customers. Sounds like a business opportunity to me.

This would solve one problem but introduces other:

a) We have plenty of small businesses that sign up for our service. They may all want their own IPs. Microsoft has plenty of IPs but we don't have an near-infinite amount (the ones Microsoft has, we share them with the rest of the company; they don't all belong to our division).

b) Even if we did give customers their own IPs, they each would get at least two IPs - one in two different data centers for redundancy. This reduces the available pool of IPs.

c) The networking challenge of maintaining IPs-to-customers mapping is painful. Running a service with as much redundancy, failover, cross-datacenter routing as ours is difficult and maintaining all these network mappings adds too much complexity. We can barely keep track of our own IPs.

Thus, the cost/benefit tradeoff of giving everyone (or even some customers) their own IP skews heavier towards the costs compared the benefits.

-- Terry

-----Original Message-----
From: MH Michael Hammer (5304) [mailto:[email-masked]] 
Sent: Monday, April 01, 2013 4:01 PM
To: Dave Crocker; Terry Zink
Cc: [email-masked]
Subject: RE: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

Comments in-line.

> this effort out of scope, since it explicitly prohibits protocol enhancement.
> 

> proper limits of DMARC.  It wouldn't solve your protocol problem, but 
> it might provide good pedagogy.
> 

> problems, versus protection against external ones.  Internal means 
> that the misbehavior is caused by an activity within the 
> administrative scope of the entity needing protection.  External means 
> that the problem behavior comes from some other administrative scope.
> 

+1

> The usual examples of the distinction are misbehaviors by a 
> department, within the company owning the domain name, versus 
> misbehavior from a classic spammer who is using the domain name 
> without authorization. On the average, the tendency has been to pursue 
> standardization that protect against external threats rather than 
> internal ones. Internal ones are thought to be best handled... internally.
> 
> > 1. example.com ----+
> >                    |
> The scenario you give might be considered as internal misbehavior, 
> since there is a contractual relationship between Forefront and the 
> sources of messages that you list.  That is, the essence of the 
> challenge is for Forefront to have mechanisms that distinguish what 
> mail is authorized from what source, and what mail isn't.  Per your 
> example, it would require that it enforce its /own/ dmarc-ish policy 
> to require that mail it is relaying for learning.edu be attributed to learning.edu, and so on.
> 
> this is that Forefront doesn't know all of the acceptable domains for a given customer.
> Wouldn't it make more sense to fix this issue, rather than change the 
> public standard and burden all recipients with the added complexity in 
> software and operations?
> 

+1

> fixing this is for Forefront to /privately/ assert the type of 
> dmarc-ish enhancement that you propose.  That is, impose the 
> requirement on its customers, thereby assuring that the mail it is 
> relaying to the public Internet is 'safe', at least along this one line of concern.
> 
>

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2013 00:45:28 -0000

> You are correct that you lose the path independence. But it is
> incorrect to say you gain nothing - you gain the ability to say
> "Nobody else can spoof me." 

Nope.  As I said, Terry's proposal adds nothing beyond the
configuration I described.  Please reread the message to which you
were responding more carefully, paying particular attention to the
difference between SPF pass and neutral.  Really, you gain nothing.

>Shouldn't it be the choice of the sender whether or not they want to make this assertion and subsequent
>trade-off?

The sender can make any assertion it wants, but it better not assume
that anyone is paying attention.  The more complicated the assertions,
the less likely that receivers will think it's worth the effort to
interpret them.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2013 00:48:13 -0000

>If you want to say, nobody else can spoof me, then you can do SPF -all,

Or you can sign all your mail with DKIM, publish no SPF at all, and
use DMARC p=reject.  (If anyone used ADSP, you could use ADSP
discardable.  too.)

One of the strengths of DMARC is that SPF and DKIM are each optional,
and senders can use them in whatever combination best describes their
mail setup.

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 2 Apr 2013 02:53:30 +0200

On Tuesday, April 02, 2013 2:37 AM [GMT+1=CET], Franck Martin wrote:
> We did SPF or DKIM because both were not solving the problem on their
> own. So both combined together has all the advantages less the
> inconveniences. 
> 
> If you want to say, nobody else can spoof me, then you can do SPF
> -all, but then no large receiver never really trusted this policy
> assertion. Also, you can put a DMARC record and SPF and not DKIM
> sign, you will get the same benefits.

Hmm, are you missing the part where several independent clients send to the Internet through the same cloud-based email gateway, and therefore "-all" in SPF still allows for spoofing if any of those clients is trojanized, and DMARC in its current form does nothing to solve this problem?

Ok, DMARC has been devised by brand-companies (Facebook, Linkedin, Big-Bank-X) and mailbox-providers (Hotmail, Yahoo, Gmail), I see that and I understand their needs to reliably exchange email policies. But there is more people in the email ecosystem, like for example cloud-services providers, who also happen to do email.

I think the needs of everyone (exchanging email policies, and securing authentication in a multitenant cloud service) can be met easily with DMARC, without harm for any of those camps.

Regards,

J. Gomez

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2013 00:52:31 -0000

>I agree that there is the potential for false positives. But shouldn't this choice be given to the sender?

No, of course not.  You don't get the complaints when my users lose
mail due to false positives.

If the sender can make any choice he wants, I choose to charge $5 to
everyone who reads this message.  Pay up, please.

More seriously, receivers are not going to implement complex stuff
that offers no useful extra function, particularly if they make their
lives harder and the extra stuff is to work around problems that are
better fixed at the sender's end.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2013 00:57:12 -0000

> Hmm, are you missing the part where several independent clients send
> to the Internet through the same cloud-based email gateway, and
> therefore "-all" in SPF still allows for spoofing if any of those
> clients is trojanized, and DMARC in its current form does nothing to
> solve this problem?

DMARC works fine if the senders behind the cloud each have different
DKIM signatures, which I gather is what Terry was describing, and the
SPF correctly describes the outgoing mail policy.

If you believe that DKIM signatures do not adequately identify a mail
stream, I'd appreciate it if you could explain in detail why not.

R's,
John

---

From: Terry Zink <[email-masked]>
Date: Tue, 2 Apr 2013 00:59:19 +0000

John,

I'm going to combine your responses. Please bear with me to ensure I understand what you are saying.

> Nope.  As I said, Terry's proposal adds nothing beyond the configuration I described.
> Please reread the message to which you were responding more carefully, paying particular 
> attention to the difference between SPF pass and neutral.  Really, you gain nothing.
> 
> bigbank.com txt "v=spf1 +ip4:22.22.22.22 ?ip4:157.55.158.0/23 
> ?ip4:157.55.234.0/24 ?ip4:157.56.112.0/24 ~all"

Case 1 - Mail comes from 22.22.22.22 -> Forefront scans it and it SPF passes -> Relays to Internet (e.g., Hotmail) who scans it and it is Neutral (since it came from Forefront IP range)
Case 2 - Mail comes from 1.2.3.4 (Learning.edu malicious spoof) -> Forefront scans it and it SPF fails -> Relays to Internet (e.g., Hotmail) who scans it and it is Neutral

But real mail from BigBank.com would have a DKIM header and so therefore it would DMARC pass at the Hotmail side.

Is that right?

But wouldn't it mean that a 3rd party who didn't validate DKIM or DMARC would always get SPF Neutral in the case of a legitimate message?

> Or you can sign all your mail with DKIM, publish no SPF at all, and use DMARC p=reject.

I've thought of that, too. I think that would be a good solution if DMARC compliance was more widespread than it is (it's pretty good now but there's still a very long tail of receivers who just use SPF and don't validate DKIM... I don't want to mention any names but there's at least one large MTA that still doesn't validate DKIM natively). Thus, if you don't publish SPF records, for the long tail of receivers that don't do DKIM or DMARC, they are even more prone to spoofing since they wouldn't pass SPF.

> (If anyone used ADSP, you could use ADSP discardable.  too.)

I've thought of that, too. But I heard ADSP was basically dead and superseded by DMARC.

-- Terry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
Sent: Monday, April 01, 2013 5:48 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

>If you want to say, nobody else can spoof me, then you can do SPF -all,

Or you can sign all your mail with DKIM, publish no SPF at all, and use DMARC p=reject.  (If anyone used ADSP, you could use ADSP discardable.  too.)

One of the strengths of DMARC is that SPF and DKIM are each optional, and senders can use them in whatever combination best describes their mail setup.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 01 Apr 2013 21:08:42 -0400

On Tuesday, April 02, 2013 02:26:01 AM J. Gomez wrote:
> >> http://blogs.msdn.com/b/tzink/archive/2012/10/18/how-should-large-financi
> >> a
> Apart from that, you would need to control your client's DNS to sign their
> DKIM in their behalf, and that only works with very small clients which
> lack in-house technical people and outsource the whole thing to you. But if
> you want to have clients of medium size which gateway their mail to the
> Internet through your cloud service, good luck getting their technical
> people to surrender their administrative control of their DNS to you.

Not true at all.  I've done this many times where the domain owner publishes a 
CNAME to the relevant DNS entry in the provider's DNS.  That way the provider 
can manage the specifics/use their own private key (for DKIM) without any zone 
delegation being required.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 01 Apr 2013 21:14:50 -0400

On Tuesday, April 02, 2013 02:53:30 AM J. Gomez wrote:
> Hmm, are you missing the part where several independent clients send to the
> Internet through the same cloud-based email gateway, and therefore "-all"
> in SPF still allows for spoofing if any of those clients is trojanized, and
> DMARC in its current form does nothing to solve this problem?

There's no way a internet facing protocol can fix local validation failures.  
This is not news.

http://tools.ietf.org/html/rfc4408#section-10.4

https://tools.ietf.org/html/rfc4871#page-53

If you're telling your customer's they can trust you not to let your other 
customers spoof them, then you actually have to do that.  No one else can do 
it for you.

Scott K

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 2 Apr 2013 03:19:22 +0200

> the less likely that receivers will think it's worth the effort to

While true for non-standarized "things", it would be reasonably expected that if you make an assertion backed by a "official" standard, it should be accepted by others, at least, as "yeah you did make that assertion" and perhaps even as "yeah you did make that assertion and we believe you meant to assert it so we will follow through".

The point remains: in what form or shape Terry's optional DMARC extension hinders DMARC's goals?

After all, that "complication" will be dealt with by a code library, just painlessly.

Regards,

J. Gomez

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 2 Apr 2013 01:20:37 +0000

> Of Terry Zink
> Sent: Monday, April 01, 2013 8:46 PM
> To: [email-masked]
> > This is a bad idea. While it solves your internal problem it
> > potentially increases false positives for bigbank.com externally, thus
> > trading one problem for another
> 
> I agree that there is the potential for false positives. But shouldn't this choice
> be given to the sender? If they understand the risks then they should be
> able to say "Yes, this can cause false positives. But we can get those under
> control (or delegate sub-domains for third parties, or some other
> workaround like using DMARC to collect feedback on where the unsigned
> mail originates). The bottom line is we don't want anyone spoofing our
> domain."
> 

Then don't let people "spoof" your domain. You have another problem with shared IPs that hasn't been brought into the discussion. By sharing IPs you are sharing reputation across customers. If one of those customers starts spewing abusive mail then the other customers suffer as a consequence. I'd really like to hear you explain to the other customers when their mail is being rejected because the shared IP is on a blocklist. DMARC doesn't help your customers in this case.

> > If bigbank.com cannot control it's managers/employees and how they
> > send mail then that is an internal problem that bigbank needs to
> > address. There are plenty of other mechanisms for bigbank to control what
> it emits (in the case of spam).
> 
> True enough. But it happens with regularity. At a large company, people
> move on all the time. Groups change and people retire, change jobs, or
> otherwise move on. The people in charge of maintaining all this IT stuff do
> not keep pace with the scope of change. This is especially true in a large
> organization (it is one of our own challenges).
> 

I'm not sympathetic. My company has multiple divisions, brands and operating units around the globe, 10s of thousands of employees and yet we seem to be able to manage it. Other large organizations manage it as well. What I'm hearing is "we are out of control and want to modify DMARC to account for this". 

> But even beyond that, it's not the only legitimate case we have to deal with.
> We have companies like real estate companies (e.g., Remax -- if they were a
> customer) that have independent sales agents. The inbound mail is
> [email-masked]. The independent agent gets the mail forwarded to their
> personal email account and then they send outbound mail through us
> [email-masked]. Remax does not own yahoo.com, but this is a legitimate
> case where a user "spoofs" a legitimate domain that they do not own.
> 

Again, DMARC is not intended for organizations that do this. It's not a question of "legitimate case of spoofing". It's a question of whether a domain/brand owner wishes to prevent direct domain abuse using DMARC. The reason that large (and small) mailbox providers - including your own - got on board with DMARC and the private channel assertions that preceded it is because it works. DMARC only works to the extent that mailbox providers are willing to buy into it. I'd also point out that domains with end users such as the example you use above are simply not good candidates for implementing DMARC policy. Ask John Levine to explain the mailing list issue with regard to DMARC policy assertions.

> Thus, shutting down this case is not going to work. The majority of the mail
> from "legitimately spoofed" senders is non-spam. But the cases of spoofing a
> domain maliciously is what I want to target.
> 

And this is only relevant to the extent that this legitimate mail is originating from domains subject to direct domain abuse and which do not have uncontrolled end users sending mail.

> a) We have plenty of small businesses that sign up for our service. They may
> all want their own IPs. Microsoft has plenty of IPs but we don't have an near-
> infinite amount (the ones Microsoft has, we share them with the rest of the
> company; they don't all belong to our division).
> 

Not all businesses (with domains) are candidates for having their own IPs or implementing DMARC. This includes most small businesses.

> b) Even if we did give customers their own IPs, they each would get at least
> two IPs - one in two different data centers for redundancy. This reduces the
> available pool of IPs.
> 

There is this very new standard called IPv6. I hear this provides a couple of extra IPs to the mix. Someone on this list even brought up NIST working on requirements for IPv6 only mail sending hosts. I would argue that the case you are putting forward is an unwillingness to address internal implementation/business structure issues.

> c) The networking challenge of maintaining IPs-to-customers mapping is
> painful. Running a service with as much redundancy, failover, cross-
> datacenter routing as ours is difficult and maintaining all these network
> mappings adds too much complexity. We can barely keep track of our own
> IPs.
> 

A lot of ESPs do this on some scale with much more limited resources. Other large providers are dealing with the issue.

> Thus, the cost/benefit tradeoff of giving everyone (or even some customers)
> their own IP skews heavier towards the costs compared the benefits.
> 

The other option is to propose to externalize those costs to everyone else.

Mike

---

From: Terry Zink <[email-masked]>
Date: Tue, 2 Apr 2013 01:51:51 +0000

Hi, Mike, thanks for your response.

> I'd really like to hear you explain to the other customers when their mail is being 
> rejected because the shared IP is on a blocklist. DMARC doesn't help your customers 
> in this case.

I'm not sure where this comment comes from, protecting and monitoring our outbound IP
reputation is something I have spent many years working on but is orthogonal to this 
discussion (you don't need one for the other, although they help). 

Please let me know if you believe otherwise.

> Not all businesses (with domains) are candidates for having their own IPs or implementing 
> DMARC. This includes most small businesses.

I disagree. I think that small businesses are great candidates for DMARC. As an industry we should help them move there.

> There is this very new standard called IPv6. I hear this provides a couple of extra IPs 
> to the mix. Someone on this list even brought up NIST working on requirements for IPv6 
> only mail sending hosts. I would argue that the case you are putting forward is an 
> unwillingness to address internal implementation/business structure issues.

IPv6 adoption is still in its infancy. Are you really proposing that simply giving each sender its own IPv6 address is the solution, when there are many email receivers who don't receive any mail over IPv6 (e.g., Hotmail)?

I agree that there are things that can be done in parallel. But at the same time, some of these implementations do not have critical mass. 

>> datacenter routing as ours is difficult and maintaining all these 
>> network mappings adds too much complexity. We can barely keep track of 
>> our own IPs.
>>

> A lot of ESPs do this on some scale with much more limited resources. Other 
> large providers are dealing with the issue.

Without knowing the implementation details of various ESPs, I don't think it's useful to say Company A does this and therefore so should Company Y. Organizations have varying needs and have their own reasons for pursuing the things they do.

>> Thus, the cost/benefit tradeoff of giving everyone (or even some 
>> customers) their own IP skews heavier towards the costs compared the benefits.
>

I understand your point. My goal in this discussion is to bring the problem of shared IP space and how to authenticate. DMARC seems like a natural place to do it since it is still a new protocol.

-- Terry

-----Original Message-----
From: MH Michael Hammer (5304) [mailto:[email-masked]] 
Sent: Monday, April 01, 2013 6:21 PM
To: Terry Zink; [email-masked]
Subject: RE: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

> > potentially increases false positives for bigbank.com externally, 
> > thus trading one problem for another
> 
> I agree that there is the potential for false positives. But shouldn't 
> this choice be given to the sender? If they understand the risks then 
> they should be able to say "Yes, this can cause false positives. But 
> we can get those under control (or delegate sub-domains for third 
> parties, or some other workaround like using DMARC to collect feedback 
> on where the unsigned mail originates). The bottom line is we don't 
> want anyone spoofing our domain."
> 

> True enough. But it happens with regularity. At a large company, 
> people move on all the time. Groups change and people retire, change 
> jobs, or otherwise move on. The people in charge of maintaining all 
> this IT stuff do not keep pace with the scope of change. This is 
> especially true in a large organization (it is one of our own challenges).
> 

> [email-masked]. The independent agent gets the mail forwarded to 
> their personal email account and then they send outbound mail through 
> us [email-masked]. Remax does not own yahoo.com, but this is a 
> legitimate case where a user "spoofs" a legitimate domain that they do not own.
> 

> Thus, shutting down this case is not going to work. The majority of 
> the mail from "legitimately spoofed" senders is non-spam. But the 
> cases of spoofing a domain maliciously is what I want to target.
> 

> > Perhaps MS should offer bigbank dedicated IPs - ESPs do this all the 
> > time
> for their customers.
> > It may not be so critical for other customers. Sounds like a 
> > business
> opportunity to me.
> 
> a) We have plenty of small businesses that sign up for our service. 
> They may all want their own IPs. Microsoft has plenty of IPs but we 
> don't have an near- infinite amount (the ones Microsoft has, we share 
> them with the rest of the company; they don't all belong to our division).
> 

> b) Even if we did give customers their own IPs, they each would get at 
> least two IPs - one in two different data centers for redundancy. This 
> reduces the available pool of IPs.
> 

> datacenter routing as ours is difficult and maintaining all these 
> network mappings adds too much complexity. We can barely keep track of 
> our own IPs.
> 

> Thus, the cost/benefit tradeoff of giving everyone (or even some 
> customers) their own IP skews heavier towards the costs compared the benefits.
> 

Mike

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2013 01:53:19 -0000

>Case 1 - Mail comes from 22.22.22.22 -> Forefront scans it

Oh, no, I had in mind customers who send mail through Forefront, but
also send some of their own mail directly from 22.22.22.22.  If it all
goes through Forefront, it all gets Forefront's ?ip SPF rules.

>But real mail from BigBank.com would have a DKIM header and so therefore it would DMARC pass at the Hotmail side.

Right.

>But wouldn't it mean that a 3rd party who didn't validate DKIM or DMARC would always get SPF Neutral in the case of a legitimate message?

Right.  Since we know the same IP can emit both real and bogus
messages and SPF can't tell the difference, what other result could
you honestly provide?  Is it really a good idea to return an SPF pass
for a message that might be a phish?

>I've thought of that, too. I think that would be a good solution if DMARC compliance was more widespread than it is

>From a security point of view, it's really the same as what you have
now, since you can't count on the bounce address as an identifier nor
SPF to tell you whether a message is authorized.

>I've thought of that, too. But I heard ADSP was basically dead and superseded by DMARC.

ADSP is kaput.  No great loss.

It seems to me that you have an opportunity here for some client
behavior modification that can be applied incrementally.

If you don't know what domains a client uses, you can't make any
meaningful path authorization assertions.  (I don't want to think
about who gets the blame when you send those SPF approved phishes.)

But when a client gives you their list of domains, you can then filter
their mail to only allow those domains in their mailstream, and more
important, filter all your other clients' mail to forbid them.  Now
you have your paths back under control, and you can publish SPF
records for that client that provide pass results.  That's a feature
that adds customer value or whatever it's called these days.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2013 01:56:46 -0000

>The point remains: in what form or shape Terry's optional DMARC extension hinders DMARC's goals?

As I've said several times already, it causes DMARC failures on valid
mail, provoking complaints to the recipient mail system.

Beyond that, as a general rule, the more complicated a spec is, the
less likely it is to be implemented consistently and the less likely
different implementations are to interoperate.  As Russ Housely said
as he finished his term as IETF chair last month, a standard is done
not when there is nothing left to add, but when there is nothing left
to take away.

R's,
John

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 2 Apr 2013 04:16:14 +0200

> for a message that might be a phish?

Yes, it would be a good idea to return an SPF pass, if and only if a standardized layer above SPF would require also a DKIM pass to build a final result of PASS.

Why? Because the probability of a trojanized AND spoofing client hosted in the same sending IP address is close to zero, but not equal to zero. To clear that marginal doubt, DKIM is needed. And to assert that policy requirement to others unaware of the particularities of that infraestructure, DMARC is need.

So the idea is this: if DMARC is in a layer above SPF and DKIM, lets plug in DMARC the holes anyone of those under it may have left open.

Yes, things could have been born perfect at once, but here we are and these issues we have. Why not patch them, if the solution is both within reach and cheap?

Regards,

J. Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 2 Apr 2013 04:22:45 +0200

> mail, provoking complaints to the recipient mail system.

Only if the sender has explicitly "opted in" into Terry's proposed optional extension to DMARC. So there will be no innocent bystanders hurt.

Terry's idea, as I read it, is that his extension is non-default behaviour to accomodate marginal cases. So you would have to explicitly choose to shoot yourself in your feet to receive any potential pain.

Regards,

J. Gomez

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 2 Apr 2013 02:22:31 +0000

> Sent: Monday, April 01, 2013 9:52 PM
> To: [email-masked]
> > I'd really like to hear you explain to the other customers when their
> > mail is being rejected because the shared IP is on a blocklist. DMARC
> > doesn't help your customers in this case.
> 
> I'm not sure where this comment comes from, protecting and monitoring our
> outbound IP reputation is something I have spent many years working on but
> is orthogonal to this discussion (you don't need one for the other, although
> they help).
> 

The original case for a DMARC extension of requiring DKIM only was predicated on one customer on shared IPs sending spam and another part of your organization (Hotmail) having difficulties because DMARC will pass on either SPF or DKIM. The issue of a sender on shared IPs emitting spam is certainly relevant to this discussion. Either spam is being emitted or it is not. Neutering (fixing) DMARC doesn't solve the wider problem of spam being emitted even if it solves the internal DMARC issue for Forefront/Hotmail.
> 
> 
> > Not all businesses (with domains) are candidates for having their own
> > IPs or implementing DMARC. This includes most small businesses.
> 
> I disagree. I think that small businesses are great candidates for DMARC. As
> an industry we should help them move there.
> 
> 
> > There is this very new standard called IPv6. I hear this provides a
> > couple of extra IPs to the mix. Someone on this list even brought up
> > NIST working on requirements for IPv6 only mail sending hosts. I would
> > argue that the case you are putting forward is an unwillingness to address
> internal implementation/business structure issues.
> 
> IPv6 adoption is still in its infancy. Are you really proposing that simply giving
> each sender its own IPv6 address is the solution, when there are many email
> receivers who don't receive any mail over IPv6 (e.g., Hotmail)?
> 

You can provide an IPv6 to IPv4 gateway..... You'll break SPF but if you do it right you won't break DKIM. Implementing aligned DKIM and SPF in 2007 was a significant effort for us, yet we did it.

> I agree that there are things that can be done in parallel. But at the same
> time, some of these implementations do not have critical mass.
> 
> 
> >> c) The networking challenge of maintaining IPs-to-customers mapping
> >> is painful. Running a service with as much redundancy, failover,
> >> cross- datacenter routing as ours is difficult and maintaining all
> >> these network mappings adds too much complexity. We can barely keep
> >> track of our own IPs.
> >>
> 
> > A lot of ESPs do this on some scale with much more limited resources.
> > Other large providers are dealing with the issue.
> 
> Without knowing the implementation details of various ESPs, I don't think it's
> useful to say Company A does this and therefore so should Company Y.
> Organizations have varying needs and have their own reasons for pursuing
> the things they do.
> 

And organizations choose to implement standards or they choose not to. You pointed to the difficulty level and I pointed out that others are managing these things. I like to tell a joke about this space. Q: How many Psychiatrists does it take to change a light bulb?  Answer: One, but the bulb has to want to change. What I'm hearing is that in this case the bulb doesn't want to change (for whatever reason).

> I understand your point. My goal in this discussion is to bring the problem of
> shared IP space and how to authenticate. DMARC seems like a natural place
> to do it since it is still a new protocol.
> 
> -- Terry
> 

DMARC is not particularly new. The private implementations date back to the 2007 timeframe. The goal of creating a public standard based on the successes seen in the private channel implementations was intended to open it up from a private club with limited membership to something that anyone could implement. Trying to overload other design parameters to attempt to solve something that DMARC intentionally did not try to solve is a dangerous path to go down.

There are lots of problems DMARC doesn't address. For example, DMARC doesn't address cousin domains, the display (friendly ) name issue or the use of other character sets to present a look alike domain name. Shared IP space is shared IP space. Sharing IP space across organizations reduces the granularity and utility of SPF. If you don't want to use SPF then sign with DKIM. You can still use DMARC if you are only using DKIM and not SPF. I use shared IPs across domains but I DKIM sign those domains and each of the domains has similar security implementations. So from my perspective it is possible to do.... I've been doing it for years.

Mike

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 2 Apr 2013 04:44:27 +0200

On Tuesday, April 02, 2013 4:22 AM [GMT+1=CET], MH Michael Hammer (5304) wrote:
> DMARC is not particularly new. The private implementations date back
> to the 2007 timeframe. The goal of creating a public standard based
> on the successes seen in the private channel implementations was
> intended to open it up from a private club with limited membership to
> something that anyone could implement.

So, you want the public to aknowledge a private practice as a public standard, and at the same time you don't want input from the public but blind adhesion, because, you know, it has been working fine in our private club?

> Trying to overload other
> design parameters to attempt to solve something that DMARC
> intentionally did not try to solve is a dangerous path to go down.   

Terry's proposed extension is:

1. Optional,
2. Non-default, and
3. Not more relaxed but more strict.

Where is the danger? You don't have the need?, well then go with the more relaxed default.

> I use shared IPs across domains
> but I DKIM sign those domains and each of the domains has similar
> security implementations. So from my perspective it is possible to
> do.... I've been doing it for years.

So what? Good for you. The world is wide. One size does not fit all, yada yada...

Again, is the proposed optional extension damaging to DMARC's goals? Are DMARC's goals those of a private club, or those of the non-spoofing email community at large?

Regards,

J. Gomez

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 01 Apr 2013 23:34:49 -0400

On Tuesday, April 02, 2013 04:44:27 AM J. Gomez wrote:
> So, you want the public to aknowledge a private practice as a public
> standard, and at the same time you don't want input from the public but
> blind adhesion, because, you know, it has been working fine in our private
> club?

It was private in 2007.  It's been public for quite some time.  There is, in 
fact, already an open source, high quality C library and milter that supports 
DMARC:

http://www.trusteddomain.org/opendmarc.html

I'm running it in production (and I was not part of that private club) and I 
know others are too.  This may be new to you, but there's an experience base 
built around the current spec and some momentum towards deployment.  

Considering that many of the largest mail providers in the world are among the 
implementers, it's more than just a small private club.

> Again, is the proposed optional extension damaging to DMARC's goals? Are
> DMARC's goals those of a private club, or those of the non-spoofing email
> community at large?

First, consider that DMARC itself is optional.  Now you have an optional add 
on that receivers have to consider.  By complicating the deployment decision 
making process, more choices and options slow things down.  That doesn't mean 
they are always to be avoided, but they have a cost.

Second, consider what the deployed receiver base of this option to an option 
is likely to be?  It's zero now.  What sender would rely on it when no 
receiver processes it?  The other way around too.  Getting past this 
chicken/egg problem is hard.  The DMARC folks have spent years working on it.

Third, if an extension like the one you propose has value, it can be added 
later.  There's no need for it to be included in the initial round of 
discussions/standardization of DMARC.  As long as the DMARC record structure 
is extensible to support new policy types (I haven't checked and I don't 
remember) then this can be done later.

If you want to get this to work, focus on making sure the base protocol is 
extensible to do what you want and then work on developing interest and 
momentem around code and deployment to support it.

If you want to change things, that's how to get it done.  It's WAY harder than 
writing emails to IETF lists.

Scott K

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 2 Apr 2013 04:24:14 +0000

> Of J. Gomez
> Sent: Monday, April 01, 2013 10:44 PM
> To: [email-masked]
> > to the 2007 timeframe. The goal of creating a public standard based on
> > the successes seen in the private channel implementations was intended
> > to open it up from a private club with limited membership to something
> > that anyone could implement.
> 
> So, you want the public to aknowledge a private practice as a public standard,
> and at the same time you don't want input from the public but blind
> adhesion, because, you know, it has been working fine in our private club?
> 

Not at all. What I'm saying is that DMARC is something that has been working for some time - both in private channels AND as a public standard ( but not an IETF standard). I'm not asking for blind adherence but that proposed additions, extensions and changes should be looked at very carefully as to whether they are generally useful or a corner case which are currently addressed in other ways. In this case I would argue that the proposed change is intended to mitigate architectural and implementation choices that have long been known within the email authentication and reputation community to be problematical.  Shared IPs = shared consequences for the entities sharing those IPs. If you don't want the shared consequences then don't publish SPF and DKIM sign only. When it comes to entities emitting spam, the "we're good people who oopsie, did a bad thing" is what I call the Jessica Rabbit theory of responsibility - "I'm not bad, I'm just drawn that way." 

> Where is the danger? You don't have the need?, well then go with the more
For example, you are asking existing implementers (validators) to make changes to their code base to accommodate this. The current mailbox coverage of existing validators is 60%+. That is certainly a non-trivial amount of implementation. You ignore the issue of whether validators feel the juice is worth the squeeze for this change. If you make this optional for validators then senders (that implement this extension) will get inconsistent outcomes across mailbox providers. One of the design parameters for DMARC was to minimize this risk. Or are you arguing it should be optional for senders but mandatory for validators? Getting mailbox providers to buy into DMARC and agree to things like reporting (for example) was non-trivial. Be careful of the demands you put on them or you may find DMARC as dead as ADSP.

If you want a DKIM pass only then the simple solution is to DKIM sign (DMARC aligned) and don't publish an SPF record. Done. You are DMARC compliant, no architectural changes are required in the spec and all you have to do is remove your SPF record(s). DMARC validators don't have to do a thing and your stated need is accommodated.

> So what? Good for you. The world is wide. One size does not fit all, yada

Is yada yada a technical term or simply your way of indicating you watch Seinfeld? There are lots of sizes of implementers that have addressed this issue. You obviously have no interest in existing working implementations (multiple alternatives have been offered by others as well as myself) in this problem space so why would you expect people to give credence to something which has no implementation track record? What I'm hearing is "Shiny new thing I want". These issues have been presented on at any number of venues including MAAWG, RSA, INTERACT, OTA and INTERACT to name a few.

Shared IPs are choice.
Open Relays are a choice.
People make choices and those choices have tradeoffs.

> DMARC's goals those of a private club, or those of the non-spoofing email

I view it as damaging because it requires validators to work to accommodate the change when the same (desired by you) outcome can be achieved without requiring code changes. I view it s not fully baked because the individuals supporting it have not presented data points based on real traffic as to a) the incremental cases and benefits vs additional overhead. For example, what impact, if any, does this have on reporting?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 1 Apr 2013 22:49:38 -0700

> blind adhesion, because, you know, it has been working fine in our private

In contrast, you're expecting that any suggestion made in this more public
venue automatically has to be accepted?  But either way we're getting ahead
of ourselves; there isn't even a working group yet.

As has already been pointed out, DMARC hasn't been private for quite some
time.  The point here is indeed to subject the specification to even more
open and rigorous review that it's already received.  There's been a public
(albeit external to the IETF) mailing list for a long while now.  The fact
that a proposed change doesn't receive favourable response doesn't mean it
didn't get considered, does it?

As for actual technical arguments, I find John's and Scott's points
compelling.  Neither DKIM nor SPF are useful defenses if you can't control
the content they authorize or authenticate.  In effect, in the attack
scenario Terry provided, SPF is giving what the victim domain perceives as
false positives.  Sticking with that scenario, the solution appears to be
to remove SPF from the equation by neutralizing its "pass" response when
coming from those IP addresses.  I keep coming back to a Venn Diagram
showing SPF pass and DKIM pass plus their overlap, which is the DMARC pass
space; if you don't want DMARC to pass for the case where SPF passed but
DKIM failed, then DMARC pass is now logically equivalent to DKIM pass.  To
enact that, just turn off SPF and sign all your mail.

On the flipside, if the victim domain's signing keys were compromised, one
could generate spam signed as them from any IP address, rendering DKIM
meaningless but SPF effective (probably).

I don't find the argument that delegating DKIM is hard to be believable.
If in Terry's application "require both" is an acceptable outcome, then his
customer base was either prepared to delegate DKIM or do it themselves
anyway.

Where is the danger? You don't have the need?, well then go with the more
> relaxed default.

I don't believe anyone's calling the proposal "dangerous", but the reasons
for the resistance have already been laid out.

> So what? Good for you. The world is wide. One size does not fit all, yada

That doesn't mean this is the right place for all solutions to all
configurations, does it?

> DMARC's goals those of a private club, or those of the non-spoofing email

The latter, but don't conflate that goal with a requirement to be
all-inclusive either.  We couldn't alter DKIM to make it work seamlessly
with all mailing list configurations, so we stopped trying.  That doesn't
mean DKIM had a private set of requirements; rather, it had realistic ones.

-MSK

---

From: Terry Zink <[email-masked]>
Date: Tue, 2 Apr 2013 16:18:27 +0000

> The fact that a proposed change doesn't receive favourable response 
> doesn't mean it didn't get considered, does it?

While I don't really agree with the reasons for the unfavorable response, I do acknowledge that this proposal has met with strong resistance. There's probably a better way to solve this. For example, if an organization behind a cloud-based service wants to prevent spoofing, it could say "The domain example.com always DKIM signs its mail" and then any unsigned mail would be rejected (or rerouted). This is a private ADSP.

> If in Terry's application "require both" is an acceptable outcome, 
> then his customer base was either prepared to delegate DKIM or do it 
> themselves anyway.

I did use myself and the company I work for as an example, but the scenario extends to many cloud-based providers of email.

A better forum may be a working-group session at MAAWG, or a set of Best-Practices. 

-- Terry

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Monday, April 01, 2013 10:50 PM
To: J. Gomez
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

In contrast, you're expecting that any suggestion made in this more public venue automatically has to be accepted?  But either way we're getting ahead of ourselves; there isn't even a working group yet.

As has already been pointed out, DMARC hasn't been private for quite some time.  The point here is indeed to subject the specification to even more open and rigorous review that it's already received.  There's been a public (albeit external to the IETF) mailing list for a long while now.  The fact that a proposed change doesn't receive favourable response doesn't mean it didn't get considered, does it?
As for actual technical arguments, I find John's and Scott's points compelling.  Neither DKIM nor SPF are useful defenses if you can't control the content they authorize or authenticate.  In effect, in the attack scenario Terry provided, SPF is giving what the victim domain perceives as false positives.  Sticking with that scenario, the solution appears to be to remove SPF from the equation by neutralizing its "pass" response when coming from those IP addresses.  I keep coming back to a Venn Diagram showing SPF pass and DKIM pass plus their overlap, which is the DMARC pass space; if you don't want DMARC to pass for the case where SPF passed but DKIM failed, then DMARC pass is now logically equivalent to DKIM pass.  To enact that, just turn off SPF and sign all your mail.

On the flipside, if the victim domain's signing keys were compromised, one could generate spam signed as them from any IP address, rendering DKIM meaningless but SPF effective (probably).

I don't find the argument that delegating DKIM is hard to be believable.  If in Terry's application "require both" is an acceptable outcome, then his customer base was either prepared to delegate DKIM or do it themselves anyway.
Where is the danger? You don't have the need?, well then go with the more relaxed default.

I don't believe anyone's calling the proposal "dangerous", but the reasons for the resistance have already been laid out.

That doesn't mean this is the right place for all solutions to all configurations, does it?

The latter, but don't conflate that goal with a requirement to be all-inclusive either.  We couldn't alter DKIM to make it work seamlessly with all mailing list configurations, so we stopped trying.  That doesn't mean DKIM had a private set of requirements; rather, it had realistic ones.

-MSK

---

From: Elizabeth Zwicky <[email-masked]>
Date: Tue, 2 Apr 2013 10:53:44 -0700

> -- makes DMARC more resilient in case any of its underliying authentications mechanisms becomes compromised/broken/moot in the future.

It's not clear to me that this is usefully true.

Let us pretend that DKIM is broken -- you can forge a DKIM signature for anybody you like.

Anybody who needed a DMARC 'both' option before is now out of luck -- DMARC can always pass, so they are vulnerable to whatever problem they would have been vulnerable to without it.

Anybody who actually needed the current DMARC 'any' option is also out of luck, because they can't go to 'both'. 

Only the tiny minority of people who can use 'both' but don't actually need to remain protected, and the net result is that the standard is unusable. There is some benefit, but it is not enough to be worth any significant cost, and adding a new option is a big implementation cost.

	Elizabeth

---

From: Elizabeth Zwicky <[email-masked]>
Date: Tue, 2 Apr 2013 11:12:25 -0700

> Ok, DMARC has been devised by brand-companies (Facebook, Linkedin, Big-Bank-X) and mailbox-providers (Hotmail, Yahoo, Gmail), I see that and I understand their needs to reliably exchange email poli…

I note that Yahoo!, Google, and Microsoft are all, in fact, cloud-service providers in some form.  You can make the argument that Hotmail is not, it's only other parts of Microsoft, but Gmail and Yahoo! Mail both are. 

There are edge cases where a both option might be helpful -- I've talked to an Amazon customer who said that he had a case where his client required SPF to pass, which left him stuck configuring SPF so all of Amazon's cloud passed. This is a more compelling case than Terry's, since it can't be handled just by SPF configuration. It still could be handled by enforcement within Amazon.

The question is, "Which serves the community better, handling this within DMARC or forcing cloud providers to handle it internally?" and that's not a question where the answer is immediately clear. We know from private-channel experience that almost nobody uses this kind of option, and that people who try to often discover belatedly that they don't consistently get a double-pass everywhere they care about and back off. So there is some reason to believe that it is marginally useful and noticeably dangerous.

If it's really cheap to implement, or it's more useful than previously believed, because there's some large class of people who don't use private channel but have a phishing problem, then maybe it's worth giving people more chances to get things wrong. But accidentally blocking mail is the main failure mode of this kind of standard, so that's pretty intimidating. And not getting widespread, interoperable implementation is another big failure mode, and anything that complicates implementation also risks that. 

So there's a pretty high barrier to surmount in adding this kind of option. 

	Elizabeth

---

From: Tim Draegen <[email-masked]>
Date: Wed, 3 Apr 2013 02:04:41 -0400

Hi Terry,

I like your proposal, but see problems:

- SPF and DKIM don't always work in production.

	By themselves, both SPF and DKIM sometimes fail to yield correct results, even when they *should*.  Be this because of transient DNS errors, DKIM canonicalization errors (its a real thing, and "relaxed" unintuitively breaks more), or bad luck, the error rate introduced by requiring both SPF and DKIM to pass 100% of the time is just too high to be useful.  Keep in mind that this is not about Domain-A sending just to Receiver-B; the problem space is every domain sending to every possible receiver/stack/environment.

- Requiring both DKIM and SPF to yield aligned domain identifiers overshoots the goal.

	The Receiver side of the coin (the "receiving function" if you'll allow me to talk about all and everything that processes incoming email) needs a basic, reliable way to link a domain to a piece of email.. when processing trillions of emails from across millions of domains on top of thousands of software environments.  Even if the reality of imperfect implementations didn't matter (see #1), the receiving function is hunting for an assertion of "this email really does come from X domain".  By requiring both DKIM and SPF to "pass", you're asking the receiving function to consider an extra assertion of "does this email really *really* come from X domain?".

- Complexity is an adoption barrier.

	Because email is used everywhere by everyone all the time and dwarfs everything else, trying to change it is really hard.  The installed base is "yes", everyone has their customized way to squeeze it, Mars lost its water when it tried to upgrade its email.  Any bell, whistle, or tiny piece of extra functionality equates to a real-life adoption barrier.  If said bell, whistle, or tiny piece of extra functionality *significantly* increases the ability to adopt DMARC everywhere, then OK, let's all talk about it and do it.

- DMARC cannot fix the shared IP problem.

	If a company:
		- is activity managing its security envelope,
		- determines that it needs DMARC, and
		- is using a service provider that allows any of its clients to send email pretending to be any other client..
	..then the company needs to think in terms of risk management.  I won't break this down any further unless someone asks.

- There is a work-around to address your proposal:

	What the company can do in this situation is: use a different domain or a sub-domain for the traffic coming out of the service provider, and require "strict" identifier alignment as needed.  Problem solved without changing DMARC.

Lastly, I hope the above does not read like it contains any hostility.  The tone of email-related IETF lists are sometimes hard to modulate, so I just want to be clear: I like your idea, but for the above reasons I think it asks DMARC to do too much for too little (esp 'cause there's a viable way to work-around your scenario).

=- Tim