Subject: Re: [spfbis] Too many includes!

From: S Moonesamy <[email-masked]>
Date: Tue, 01 Oct 2013 02:55:20 -0700

Hi Murray,
At 22:46 30-09-2013, Murray S. Kucherawy wrote:
>For the second time in recent memory, I'm being consulted about an 
>issue where some outsourced mail service provider has its customers 
>publish an SPF policy that has an "include:" referring to some name 
>the service provider has defined.  That include refers to a number 
>of other includes, which in turn contain as many "ip4" rules as will 
>fit in an UDP DNS reply.  This consumes most of the ten lookups the 
>overall limit allows.

Ok.

>I'm concerned that this is going to become a pervasive problem.  In 
>offlist conversations the consensus has clearly been "Yeah, don't do 
>that."  I wonder, though, if we need to say something more formal, 
>be it inside spfbis or elsewhere.  It seems to me that if we do 
>decide we want to say something someplace, we need to come up with 
>"Don't do that, do this other thing" and give at least one 
>alternative to do the same thing.
>
>Do we need to find some way to provide some advice here?

If there is a concern that this is going to be a pervasive problem my 
suggestion would be to carefully consider the matter and make the 
argument.  It is suggested that factual information be provided so 
that people can verify for themselves and form an opinion.

Regards,
S. Moonesamy (as document shepherd)

---

From: Hector Santos <[email-masked]>
Date: Tue, 01 Oct 2013 07:45:12 -0400

This was known -- stated in the group in the past for SPFBIS 
consideration  and unfortunately, ignored, skipped, went over heads, 
what have you. Too bad.

However, it is isolated to certain hosting domains only. It is not a 
pervasive thing.

The main issue is the REDUNDANT WASTE when done with SPF relaxed 
policies. So even if its just 8, 9 or limited to 10 calls,  when done 
by common domains (most of the messages arriving at your receiver), 
then its all wasteful.

It should of been added with some guideline but I don't feel its 
warrants a change at this point.  It will go to the whole idea of how 
many INCLUDES is too much and the worth (type of policies) of the the 
calls.  It could be that original receiver operations didn't have a 
limit and then added one (like us when RFC4408 was finally done).

The SPF limit is 10 and we have that as a global option for operators 
to change.  But in theory, technically, it has to be a learned process 
PER HOST and what I am pointing out it is limited to only certain 
hosting domains.  At best, what can be stated is that "SPF service 
providers"  SHOULD CONSIDER the worth of the calls.  Don't do this if 
the end results are NEUTRAL (?ALL) or even SOFTFAIL (~ALL), although 
the latter does offer some worth.

On 10/1/2013 5:55 AM, S Moonesamy wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>
>

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Oct 2013 05:11:01 -0700

On Tue, Oct 1, 2013 at 2:55 AM, S Moonesamy <[email-masked]> wrote:

> suggestion would be to carefully consider the matter and make the argument.
>  It is suggested that factual information be provided so that people can
> verify for themselves and form an opinion.
>
>
I think Scott's idea of doing a FAQ entry is the most reasonable path
forward here.  This doesn't seem to be serious enough to warrant a new
document or a modification to the bis draft at this stage.  Given the size
and popularity of the operators I've heard about, however, this is going to
be a pain point for more than just the couple of operators I've heard from.

Another issue that was suggested: If the first party's SPF record includes
two or more others others, and those in turn include others but some of
those overlap, should the redundant includes be counted against the 10?

I don't agree that this is a configurable limit.  The limit is fixed at 10;
an implementation that allows the limit to be adjusted is non-standard and
not interoperable.  Have I misunderstood something here?

-MSK

---

From: Hector Santos <[email-masked]>
Date: Tue, 01 Oct 2013 08:44:10 -0400

> not interoperable.  Have I misunderstood something here?

Early adopter like us didn't have limits. IOW, draft-mengwong-spf-00 
did not have any limits written in.   However, software stack 
recursion limits soon became apparent.  When RFC4408 was finally 
release, early adopters updated and it was added then.

So I would think these were added after the fact and as a global 
limit, and as a matter of fact,  our default is actually set at 20 
most likely it was too low for these types of spf service provider issues:

; RecursionLimit limits the number of SPF recursion calls by a domain

RecursionLimit       20

You have to consider that SOFTWARE was optimized to also not fail. 
This 20 probably covers the ones or twos SPF service providers you are 
just now hearing about. But the overall issue has been long known and 
don't be surprise if there are some remaining implementations that 
don't have a limit or have it at some level so it doesn't fail at 11 
or 12, etc.

Consider the outcomes:

     PERMERROR vs REAL SPF RESULT

-- 
HLS

---

From: Dotzero <[email-masked]>
Date: Tue, 1 Oct 2013 09:00:38 -0400

>>> Do we need to find some way to provide some advice here?

Patient: "Dr., it hurts when I do that.
Dr.: "Then don't do that."
> be a pain point for more than just the couple of operators I've heard from.

I have seen this problem as well. Shame on the operators. They should
have been testing and noticed the problem and addressed it. That's
part of what they are getting paid for.

To a certain extent I say shame on the customers but I realize that
many of them don't have the understanding, skillsets or even the
ability to figure out where to find a tool to validate their record
(including includes). I question how useful adding the FAQ will be
(even though I agree it is the correct thing to do) in this respect.
To summarize, I view it as more of a quality assurance issue for the
service provider than something we can fix through documentation.

> not interoperable.  Have I misunderstood something here?

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Oct 2013 06:36:19 -0700

> part of what they are getting paid for.

Another part of the problem is that there are implementations that don't
impose any limit, or don't stick to the specified limit, which means the
operator gets inconsistent feedback; some receivers bounce because the
limit is reached, others don't.  It gets very hard to make a choice about
how to adjust the policy record to deal with a situation like that.

-MSK

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 1 Oct 2013 09:52:43 -0400

On Oct 1, 2013, at 8:11 AM, Murray S. Kucherawy <[email-masked]> wrote:

> If there is a concern that this is going to be a pervasive problem my suggestion would be to carefully consider the matter and make the argument.  It is suggested that factual information be provided so that people can verify for themselves and form an opinion.
> 
> 
> I think Scott's idea of doing a FAQ entry is the most reasonable path forward here.  This doesn't seem to be serious enough to warrant a new document or a modification to the bis draft at this stage.  Given the size and popularity of the operators I've heard about, however, this is going to be a pain point for more than just the couple of operators I've heard from.
> 
> Another issue that was suggested: If the first party's SPF record includes two or more others others, and those in turn include others but some of those overlap, should the redundant includes be counted against the 10?
> 
> I don't agree that this is a configurable limit.  The limit is fixed at 10; an implementation that allows the limit to be adjusted is non-standard and not interoperable.  Have I misunderstood something here?
> 
> -MSK

As the SPFBIS working group is almost done with its protocol specifying milestones, 
should it recharter and add the task of generating an operational guidance/BCP document? 

A if someone has a FAQ would be a good start, no matter if the WG takes this on.

	Olafur

---

From: S Moonesamy <[email-masked]>
Date: Tue, 01 Oct 2013 08:14:23 -0700

Hi Murray,
At 05:11 01-10-2013, Murray S. Kucherawy wrote:
>I think Scott's idea of doing a FAQ entry is the most reasonable 
>path forward here.  This doesn't seem to be serious enough to 
>warrant a new document or a modification to the bis draft at this 
>stage.  Given the size and popularity of the operators I've heard 
>about, however, this is going to be a pain point for more than just 
>the couple of operators I've heard from.

Ok.

>Another issue that was suggested: If the first party's SPF record 
>includes two or more others others, and those in turn include others 
>but some of those overlap, should the redundant includes be counted 
>against the 10?
>
>I don't agree that this is a configurable limit.  The limit is fixed 
>at 10; an implementation that allows the limit to be adjusted is 
>non-standard and not interoperable.  Have I misunderstood something here?

I took a quick look at draft-ietf-spfbis-4408bis-21.  The limit is 
set to 10.  The argument for the limit is to avoid load on 
DNS.  There is some text in the Security Considerations section which 
explains why there are processing limits in the specification.  BTW, 
there would also be non-standard behavior if the limit is 
configurable.  There may also be an interoperability issue.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 01 Oct 2013 08:34:27 -0700

Hi Olafur,
>should it recharter and add the task of generating an operational 

There is a message from the SPFBIS WG Chairs at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10124.html

Regards,
S. Moonesamy

---

From: Hector Santos <[email-masked]>
Date: Tue, 01 Oct 2013 12:09:36 -0400

> Dr.: "Then don't do that."

We get the point, but its not reality:

  Patient: "Dr., it hurts when I raise my arm"
  Dr.: "Then don't raise your arm!"

is not the answer.

The answer is A) awareness and B) allow implementators do deal with 
it, figure it out, i.e., with suggested limits and insights.  But you 
have to consider that having something fail as a PERMERROR redundantly 
at the 11th call is just as illogical as the original SWAG (scientific 
wild-ass guess) of choosing 10 in the first place.

     The real problem is the WASTE with the relaxed policies.  Vendors 
that
     do this as a service but have NO BANG for the SPF Calls Bucks!

> part of what they are getting paid for.

It was only a problem from a SOFTWARE STACK standpoint and it that 
depends on the method of doing recursive or alternative 
(non-recursive) processing.

So you only saw it when the with STACK exceptions and for most systems 
10 is nothing, peanuts -- it was a SWAG limit.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 01 Oct 2013 12:16:17 -0400

On 10/1/2013 11:14 AM, S Moonesamy wrote:
> I took a quick look at draft-ietf-spfbis-4408bis-21.  The limit is set
> to 10.  The argument for the limit is to avoid load on DNS.  There is
> some text in the Security Considerations section which explains why
> there are processing limits in the specification.  BTW, there would
> also be non-standard behavior if the limit is configurable.  There may
> also be an interoperability issue.

Recursion limits is the principle reason because software breaks here, 
its real, that was an immediate symptom, even for processing the "good 
guys" publishers who just has too many includes.  So the software had 
to be fine tuned to not fail.    Remember, the 10, is just a SWAG.  As 
I see, for our implementation, we have 20 as the limit, and I'm sure 
that was to cover the extremely few good guys who total calls was 
perhaps just over the subjective 10 limit.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 01 Oct 2013 13:15:04 -0400

I agree, which tells ya, that this is material for a SPF "publishing" 
BCP that does take into account integrated concepts.  But without it, 
this is just about weighting Waste versus Policy concepts.  I 
personally don't think 10 should be labeled as a hard compliancy issue 
because as I pointed out, 10 was a SWAG, its too subjective and if we 
were to go on suggesting that if you don't follow "10" it will make 
you non-compliant, well, thats just more material to not support and 
ignore this BIS work. It was important early on so it should be 
pointed out of using limits, e.g.; 10, but the original issue, at 
least it was for us, was running into memory stack recursion limits. 
10 is nothing and failing at 11 for a common domain, well, gets into 
political, tech support issues of who is right or wrong, the big vs 
small, passing the buck, etc.   Remember, its not just about your own 
site, but a customer site who is seeing that one SPF service provider 
domain hitting their system with perhaps permerror results. After the 
more important and critical software stack design issue was first 
addressed (to address buffer overflow exploit attempts), this is most 
likely the reason we set the default of 20 as the limit, not 10.

On 10/1/2013 12:23 PM, Kurt Andersen wrote:
> On 2013-10-01 04:45 , "Hector Santos" <[email-masked]> wrote:
>
> Without any desire to provoke a flame war, relaxed policies are not
> entirely wasteful if one is using an "over the top" protocol such as
> DMARC. DMARC (and some individual receiver policies) work off of positive
> assertions, not the negative ones.
>
> --Kurt Andersen
>
>
>

-- 
HLS

---

From: Kurt Andersen <[email-masked]>
Date: Tue, 1 Oct 2013 16:23:55 +0000

--Kurt Andersen

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Oct 2013 11:50:19 -0700

On Tue, Oct 1, 2013 at 8:34 AM, S Moonesamy <[email-masked]> wrote:

> There is a message from the SPFBIS WG Chairs at http://www.ietf.org/mail-*
> *archive/web/apps-discuss/**current/msg10124.html<http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10124.html>
>
>
>
If the WG feels like this is something that needs doing, rechartering is
always an option.

That said, it's not the only option.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 1 Oct 2013 19:07:11 -0000

>should it recharter and add the task of generating an operational guidance/BCP document? 

I don't think so.

The issue of include explosions has been around as long as there has
been SPF.  Please let smoke settle, and see if there are enough
non-obvious implementation issues that it's worth a separate document.

This is hardly the only protocol with inconsistently enforced limits
(512 byte DNS packets, anyone?), and I don't think it'd be a good idea
to start publishing a document per protocol that says if you don't do
what the standard says, it often won't work.

R's,
John

---

From: Dotzero <[email-masked]>
Date: Tue, 1 Oct 2013 15:16:31 -0400

> what the standard says, it often won't work.

One of the reasons I'm not particularly sympathetic is that of the
problem records I've looked at/dug into with the publisher of the
record there has invariably been a reasonable way to do things and
stay within the limit. I'm not saying there won't potentially be some
exceptions, but that has been my experience so far.

---

From: Tim Draegen <[email-masked]>
Date: Tue, 1 Oct 2013 15:24:20 -0400

> exceptions, but that has been my experience so far.

My approach has been to make something that clearly shows that there is a problem.

Cycles:
	https://dmarcian.com/spf-survey/walmart.com

Over-limit:
	https://dmarcian.com/spf-survey/microsoft.com

I'm still trying to get the "clearly shows" part to better.  Big red blob == problem seems to work.

=- Tim

---

From: Dotzero <[email-masked]>
Date: Tue, 1 Oct 2013 15:36:44 -0400

> My approach has been to make something that clearly shows that there is a problem.

But notice the difference between the problems.

>         https://dmarcian.com/spf-survey/walmart.com

Really? They have ~99,000 IPs sending mail on their behalf? I view
their problem as more along the lines of administrative laziness. If
someone at a site which receives a lot of mail from them were to
check, I bet Walmart is actually sending mail from only a fraction of
those.

>         https://dmarcian.com/spf-survey/microsoft.com

1 over the limit and with ~79k IPs. I am more likely to believe that
MS needs lots of IPs/netblocks for mail given the services they
host/provide including for others..

> I'm still trying to get the "clearly shows" part to better.  Big red blob == problem seems to work.

I think you are doing a great job with dmarcian Tim.

Mike

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 01 Oct 2013 16:37:04 -0400

You understand correctly.

Scott K

"Murray S. Kucherawy" <[email-masked]> wrote:
>argument.
>includes
>------------------------------------------------------------------------
>

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 01 Oct 2013 16:51:01 -0400

Hector Santos <[email-masked]> wrote:
>at 10;

Permerror is the real SPF result. 

Super huge providers like Hotmail are able to (mostly) able publish compliant records.  If they can do it, I have a hard time believing it's a problem that needs more than education to solve.

This is unchanged from 4408, so it's nothing new. 

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 01 Oct 2013 17:15:18 -0400

Hector Santos <[email-masked]> wrote:
>set

Do you really mean recursion limit? The 4408/4408bis limits aren't related to recursion (unlike the pre-RFC limits which were recursion based).

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 1 Oct 2013 19:13:06 -0700

> assertions, not the negative ones.

Dear Kurt,

Disagree.  DMARC is attempting to elevate combined negative results into something providers will consider actionable.  This action is independent of private arrangement or a domain's reputation as a means to limit user exposure to spoofing attempts.  The relatively high exception rate needed for either SPF or DKIM has devolved into strategies that do not function well with normal email.  DMARC offers an action when both SPF and DKIM offer negative results.   Beyond dealing with accepted email that can not be delivered (which should not happen), most providers ignore negative results obtained from SPF despite protocol specific policy assertions.  This is also where DMARC may conflict with advice offered by SPFbis which does not align with DMARC's goal of reducing erroneous actions based on negative SPF results.  In other words, this is where there is any direct benefit, but likely only for domains limited to transactional messaging. 

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 01 Oct 2013 22:25:09 -0400

Please argue about DMARC in some DMARC related place. 

Scott K

Douglas Otis <[email-masked]> wrote:
>Disagree.  DMARC is attempting to elevate combined negative results
>into something providers will consider actionable.  This action is
>independent of private arrangement or a domain's reputation as a means
>to limit user exposure to spoofing attempts.  The relatively high
>exception rate needed for either SPF or DKIM has devolved into
>strategies that do not function well with normal email.  DMARC offers
>an action when both SPF and DKIM offer negative results.   Beyond
>dealing with accepted email that can not be delivered (which should not
>happen), most providers ignore negative results obtained from SPF
>despite protocol specific policy assertions.  This is also where DMARC
>may conflict with advice offered by SPFbis which does not align with
>DMARC's goal of reducing erroneous actions based on negative SPF
>results.  In other words, this is where there is any direct benefit,
>but likely only for domains limited to transactional messaging. 
>
>Regards,
>Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Tue, 1 Oct 2013 19:59:50 -0700

> Please argue about DMARC in some DMARC related place.

Dear Scott,

The message pointed out a conflict in how SPF views "-all" policy assertions.  It seems this might deserve some review by the SPFbis WG since some large providers have stated SPF negatives do not offer safe actions with respect to general acceptance due to SPF's high exception rate from things like forwarded email, etc.  Dealing with an accepted message that can not be delivered falls into a different set of considerations.  Acknowledging this may suggest "~all" rather than "-all" offers better advice when the domain offers a fallback scheme.  Is this consideration on-topic for this WG?

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 02 Oct 2013 01:18:34 -0400

On Tuesday, October 01, 2013 19:59:50 Douglas Otis wrote:
> The message pointed out a conflict in how SPF views "-all" policy
> assertions.  It seems this might deserve some review by the SPFbis WG since
> some large providers have stated SPF negatives do not offer safe actions
> with respect to general acceptance due to SPF's high exception rate from
> things like forwarded email, etc.  Dealing with an accepted message that
> can not be delivered falls into a different set of considerations. 
> Acknowledging this may suggest "~all" rather than "-all" offers better
> advice when the domain offers a fallback scheme.  Is this consideration
> on-topic for this WG?

What WG deliverables would it be relevant to?

There's an spf-discuss list on listbox for more general discussions about SPF.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Oct 2013 11:03:47 -0700

> What WG deliverables would it be relevant to?

SPFbis related documents of course. 

Domains attempting to protect recipients from spoofed messages find "-all" (FAIL) policy assertions in SPFbis and section G2 stating "SPF fail results can be used to reject messages during the SMTP transaction based on either "MAIL FROM" or "HELO" identity results" are generally ignored.  Such rejections are ignored because this often induces support issues caused by the loss of otherwise valid and desired messages.  There is some risk of "FAIL" being acted upon which interferes with fallback strategies aimed at reducing support costs associated with SPF handling where a "~all" SOFTFAIL offers better results.  This has been confirmed by large providers who report too many exceptions are needed to reject messages based on "-all" FAIL results.  Effective policy enforcement becomes practical when SPFbis permits a fallback strategy to reduce the number of exceptions likely encountered.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 02 Oct 2013 14:07:23 -0400

On Wednesday, October 02, 2013 11:03:47 Douglas Otis wrote:
> Domains attempting to protect recipients from spoofed messages find "-all"
> (FAIL) policy assertions in SPFbis and section G2 stating "SPF fail results
> can be used to reject messages during the SMTP transaction based on either
> "MAIL FROM" or "HELO" identity results" are generally ignored.  Such
> rejections are ignored because this often induces support issues caused by
> the loss of otherwise valid and desired messages.  There is some risk of
> "FAIL" being acted upon which interferes with fallback strategies aimed at
> reducing support costs associated with SPF handling where a "~all" SOFTFAIL
> offers better results.  This has been confirmed by large providers who
> report too many exceptions are needed to reject messages based on "-all"
> FAIL results.  Effective policy enforcement becomes practical when SPFbis
> permits a fallback strategy to reduce the number of exceptions likely
> encountered.

Since neither RFC 4408 nor RFC 4408bis specify receiver behavior in this case, 
I don't get the connection to SPFbis work.

Scott K

---

From: Dotzero <[email-masked]>
Date: Wed, 2 Oct 2013 14:30:00 -0400

> I don't get the connection to SPFbis work.

+1 I think this falls under the heading of local policy. If I were
John Levine I would invoke King Canute.

Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Oct 2013 10:30:44 -0700

> John Levine I would invoke King Canute.

Dear Mike and Scott,

This is not about dictating, but about advice offered in SPFbis.  

Please see: 
http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-21#appendix-G.2

This section offers advice regarding local policy for "-all" (FAIL).  It seems a bit disingenuous to offer advice that overlooks some hard learned lessons.  The advice offered is not well considered for many scenarios and why rejection remains an unlikely result.  It seems any future version should expand upon this section at least.  After a decade, the number of exceptions involved with SPF handling are not likely to improve substantially, which suggests there should also be a section for "~all" (SOFTFAIL).  This result offers a safer outcome when combined with fallback strategies where a resulting aggregate policy has a better chance of actually being applied (if only for transactional messages.)

Regards,
Douglas Otis