Subject: [spfbis] Rejection Based On SPF

From: Scott Kitterman <[email-masked]>
Date: Fri, 09 Nov 2012 09:29:29 -0500

We've discussed off and on the question of if people reject mail based on SPF.  
I thought I'd pass on this anecdote (I know it provides no statistical insight 
into the question, but found it sufficiently amusing to pass on).

Microsoft is publishing an invalid DNS record (exceeds the DNS lookup limit).  
For reasons that are beyond me, they do this from time to time.  This morning 
I was treated to an irate email from a Microsoft employee complaining that my 
SPF record validation tool (http://www.kitterman.com/spf/validate.html) was 
causing Microsoft email to be rejected and demanding I fix the problem with my 
system.

My reply was probably not a polite as it could have been, but I did suggest 
that perhaps if Microsoft was having trouble sending mail due to SPF failures, 
they ought to look in the mirror.

So this was a case of reject on permerror, which is the default for a lot of 
the open source implementations.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 09 Nov 2012 09:48:39 -0500

I'm not seeing a natural place for this issue in the spfbis 
specification organization that Murray has proposed, other than perhaps 
some general statements in the early input/output/context section that 
should warn that spf is "merely" a component of a larger engine.

But maybe a more extended and even normative discuss in:

    Section 8: Details about Outputs, Pedagogy, Interpretation

Or perhaps a separate operational considerations document?

d/

On 11/9/2012 9:29 AM, Scott Kitterman wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Nov 2012 10:05:23 -0500

A question from a puzzled chair:

On Fri, Nov 09, 2012 at 09:48:39AM -0500, Dave Crocker wrote:
> specification organization that Murray has proposed, other than
> perhaps some general statements in the early input/output/context
> section that should warn that spf is "merely" a component of a
> larger engine.

I am inclined to think that this topic is part of the
operational/applicability statement work for which we are not
chartered, but that people have suggested as a natural thing to do
once our current work is completed.

I'd be very interested in arguments about why that is _not_ the case.  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Nov 2012 10:25:58 -0500

I agree, but I also think that if advice like this belongs outside our
single current deliverable, then we need to revisit the split topic that
received no support yesterday.

To put it another way: Why should this topic go in an external document,
while other what-to-do-with-a-given-result discussion stays in the main
draft?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Nov 2012 10:26:46 -0500

Just to clarify: I actually don't care which path we take, but we need to
be consistent.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 09 Nov 2012 10:30:53 -0500

I think this is a case of the protocol operating as designed.  It's not at all clear anything needs fixing.

Scott K

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

>------------------------------------------------------------------------
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Nov 2012 10:33:24 -0500

But if someone is confused by it operating as designed, wouldn't it be
helpful to provide some pedagogical text?

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Nov 2012 10:37:43 -0500

> received no support yesterday.

That's an interesting argument.  What about a document that was
something like "BCP for SPF reciever processing"?  That'd still be
relevant to the case in question, but clearly a difference from any
content in RFC 4408.  Thoughts?

Again, I'm just asking: I'm not trying to promote or discourage any
particular option, just understand our options.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 09 Nov 2012 10:38:51 -0500

They were confused, but they'd never read 4408.  Sorry for not being clear.  No amount of text will help cases like this.

Scott K

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

>> I think this is a case of the protocol operating as designed.  It's
>not at
>> all clear anything needs fixing.
>>
>> Scott K
>>
>> >Just to clarify: I actually don't care which path we take, but we
>need
>> >to
>> >be consistent.
>> >
>> >-MSK
>> >
>> >
>> >> single current deliverable, then we need to revisit the split
>topic
>> >that

---

From: Kurt Andersen <[email-masked]>
Date: Fri, 9 Nov 2012 07:39:11 -0800

I suspect that in this case it was an issue of team "left hand" not having
any clue what was going on with team "right hand". Having worked with
silo'd enterprise divisions for quite a while, this is far more common than
not...I doubt that all the SPF pedagogy in the world won't penetrate such
inter-departmental gaps.

--Kurt Andersen

On Fri, Nov 9, 2012 at 7:33 AM, Murray S. Kucherawy <[email-masked]>wrote:

> On Fri, Nov 9, 2012 at 10:30 AM, Scott Kitterman <[email-masked]>wrote:
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 09 Nov 2012 10:40:17 -0500

> helpful to provide some pedagogical text?

in case I needed to say it explicitly:  I am assuming that handling this 
problem does /not/ require changing the protocol.  No normative change 
at all.

I assume it's merely a matter of documenting good practices.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Nov 2012 10:47:44 -0500

I agree that no normative changes are appropriate here.

Maybe all we need to do is encourage adoption of RFC6652 by both senders
and receivers?

-MSK

On Fri, Nov 9, 2012 at 10:40 AM, Dave Crocker <[email-masked]> wrote:

> problem does /not/ require changing the protocol.  No normative change at
> all.
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Nov 2012 10:49:59 -0500

Are there operational cases besides this one that we would put in such a
document, without also moving all the receiver advice from the main
document?

If there's only this one exceptional use case, I'd lean toward saying it's
not worthwhile.  But if we revisit the splitting decision, then there's
enough meat to proceed.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Nov 2012 11:50:56 -0500

> the open source implementations.

Scott,

Issues on how to handle errors was catalogged and I had proposed the 
language be to treat an error as NONE but also monitoring it, demote 
it to a failed state:

       result = NONE
       if error count > some_error_threshold then
          result = FAIL

In other words, the receiver "SHOULD" have the right to control the 
abuse on his system even from good intention, but broken clients, by 
monitoring their frequency and burden on the system and changing a 
PASS status to REJECT.

Not saying we are doing this for SPF, but its a consideration we are 
doing for our SPF implementation. But I think if SPF people are 
already doing this, then these insights should be documented in the 
protocol standard.

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 09 Nov 2012 15:48:01 -0500

On Fri 09/Nov/2012 10:30:53 -0500 Scott Kitterman wrote:
> not at all clear anything needs fixing.

Something needs fixing, since it doesn't work as intended by the user.

The way large organizations delegate responsibility is not matched by
include mechanisms.  Include covers mailing services.  I guess domains
that use them have an agreement with one such services, possibly two if
they care about failure tolerance.  We had this discussion already:
http://www.ietf.org/mail-archive/web/spfbis/current/msg01777.html

I know no software that implements SPF publishing for such companies.

>> Just to clarify: I actually don't care which path we take, but we need
>> to be consistent.

That can be relaxed even more: it is enough that we produce a consistent
spec.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 09 Nov 2012 19:30:12 -0500

> Something needs fixing, since it doesn't work as intended by the user.

The user for SPF is the ADMD owner, not the individual mail sender/receiver so 
my anecdote offers no insight into if SPF is working as intended by the user.

> I know no software that implements SPF publishing for such companies.

There are many large organizations that have successfully implemented SPF, so 
I definitely don't understand what you're talking about here?

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 11 Nov 2012 21:18:43 +0100

On Sat 10/Nov/2012 01:30:12 +0100 Scott Kitterman wrote:
> There are many large organizations that have successfully
> implemented SPF, so I definitely don't understand what you're
> talking about here?

I meant using "exists".  That implies managing a DNS, or outsourcing
to someone who does.

I have no direct experience of how large companies structure
authorizations to send out mail directly.  Do they fully specify what
are the procedures for granting send-permissions?  Even if ISO 9000
compliance may require them to do so, by managing large blocks of
addresses in included records they can be more flexible, and sloppy.

I guess inhaus delegations are not quite comparable to RIRs
management.  Do they use specific software for that?

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 11 Nov 2012 20:07:01 -0500

> management.  Do they use specific software for that?

My understanding is that in large organizations, the actual SPF records are 
typically managed by the DNS team like any other DNS record.  The added 
complexity is that the messaging team needs to collect data on what domains 
are sent from what MTAs (including third parties) and coordinate with the DNS 
team to keep the DNS records up to date.  In some cases they'll use include: 
to allow different segments of the the sending infrastructure to be managed 
independently.

Scott K