Subject: Re: [spfbis] #13: RFC 4408: Best-Guess SPF

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Aug 2012 12:17:16 -0700

Hello,

Issue #13 ( http://trac.tools.ietf.org/wg/spfbis/trac/ticket/13 ) is 
about Best-Guess SPF.  Please see the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00398.html and 
comment on the issue.

Regards,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Aug 2012 12:32:20 -0700

On 8/22/2012 12:17 PM, S Moonesamy wrote:
> http://www.ietf.org/mail-archive/web/spfbis/current/msg00398.html
> and comment on the issue.
...
> I’d like to have a section, or at least an appendix, that talks about
> best-guess SPF: What it is, why/when it is or isn’t a good idea,
> etc.

my fingers always start quivering, and I seem to start stuttering, when
anyone uses the word 'guess' as part of a discussion about a protocol
specification.

so... what do you have in mind?

d/

-- 
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Aug 2012 12:43:12 -0700

> so... what do you have in mind?

Best Guess SPF is a well-documented "default" to use when there's no
SPF policy published for a given domain.  It's in use, among other
places, at Gmail.

Since we're basically undertaking the work of formal documentation of
SPF for the standards track, it seems prudent to me to give this a
formal definition and then comment on whether we think it's a good or
bad idea.  No normative text at all.  Stick it in an appendix,
perhaps.

It looks like the OpenSPF web site has the material we need here in
terms of both definition and pedagogy, so what I have in mind isn't
much in the way of new work for us.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Aug 2012 15:49:33 -0400

-1 on Best-Guess SPF.  Write a separate I-D in SPF Add-on Technology.

S Moonesamy wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
> 
> 

-- 
HLS

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Aug 2012 12:51:38 -0700

> bad idea.  No normative text at all.  Stick it in an appendix,

Hmmm.  SPF in the Absence of SPF...

With the terms and placement you suggest, given the history, it makes
sense (possibly unfortunately...)

The most clean distinction is usually a separate document that discusses
operations procedures and best practices, distinct from the formal
protocol specification, but this is the IETF and we allow flexibility
about such things... as long as the distinction is kept clear.

d/

---

From: John Leslie <[email-masked]>
Date: Wed, 22 Aug 2012 16:15:55 -0400

> SPF policy published for a given domain.  It's in use, among other

   Whatever Gmail may do today has limited correlation with what they
may do next year, least of all five years from now.

   But regardless, "best-guess" _isn't_ _Sender_ Policy Framework; so
I object to calling it "Best Guess SPF". Call it "BGPF" if you must
refer to it at all.

   (There might evolve services which put together very-good-guesses
of the appropriate policy -- but that still wouldn't be _sender_
policy framework.)

> bad idea.  No normative text at all.  Stick it in an appendix,

   I'm hesitant to even try to define it. The _only_ thing I think it
appropriate to say would be it MUST NOT replace the "none" SPF result.

   (We can't forbid the practice of applying check_host to some random
string; but anyone doing it is outside this protocol, however helpful
the result might be in some situations.)

--
John Leslie <[email-masked]>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Aug 2012 13:34:03 -0700

> of the appropriate policy -- but that still wouldn't be _sender_

I understand, and I'm not trying to make any claim that it's even a
good idea.  What I'm wondering about is what a reader looking for
guidance will do with the fact that we don't talk about it at all, but
there's non-trivial usage of it today.  We're writing a proposed
standard for a specific environment that's already deployed, and it
seems to me omitting this entirely would leave some readers wondering
why.

I'd even be fine with us saying that "Best-Guess SPF" is a total
misnomer and a bad idea, as you've done.  I just feel that omitting it
entirely might be a worse idea.  We have an opportunity to provide
guidance here, and I think we should.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 22 Aug 2012 17:22:30 -0400

No hat.

On Wed, Aug 22, 2012 at 12:43:12PM -0700, Murray S. Kucherawy wrote:

> SPF policy published for a given domain.

If I put "best guess spf" into google, the first real hit I got was
from http://www.openspf.org/FAQ/Best_guess_record, which says this:

> Best-guess processing is a crude, non-standard attempt at guessing the
> IP address range of a domain's outgoing mailservers.  "Non-standard"
> means it is not standardized and specific to the implementation.

[…]

> The practice is deprecated and should generally be avoided. While it
> may be useful in certain specific circumstances it's not part of the
> SPF protocol and results of guessing SPF like records should not be
> referred to as SPF results.

That doesn't sound to me like something I'd like to add to the formal
SPF protocol document at all.  But I emphasise, I have no hat on.

Best (guess!),
A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Aug 2012 17:25:29 -0400

>SPF protocol document at all.  But I emphasise, I have no hat on.
+1.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Aug 2012 17:51:33 -0400

In that case, lets open the case for something more relevant to SPF:

             SPF 2.0

and how it 100% related to SPF operations in the market.

I think it is an engineering sin to not discuss SPF 2.0 in a SPF 
related document.

best-guest SPF is a kludge that pertains to the idea that senders and 
receivers are part of the same computer, which may be true or 
reflective of a market where there is less ISPs/ESPs (they abandoned 
this business, etc) and also a market where there are less scaled out 
farms (more machines) and more scaled up (more CPUs/Multi-Core) 
operations thus the same IP/MX, etc.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Aug 2012 14:57:18 -0700

> SPF protocol document at all.  But I emphasise, I have no hat on.

It's fine with me if consensus is "no".  I just wanted to have the conversation.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Aug 2012 15:10:53 -0700

>It's fine with me if consensus is "no".  I just wanted to have the 

Dave Crocker said [1]: "Hmmm.  SPF in the Absence of SPF...".  John 
Leslie mentioned [2] that:

   'But regardless, "best-guess" _isn't_ _Sender_ Policy Framework; so
    I object to calling it "Best Guess SPF". Call it "BGPF" if you must
    refer to it at all.'

I'll consider this issue as addressed.

Regards,
S. Moonesamy
SPFBIS WG co-chair

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02213.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02217.html

---

From: "Wayne Doust" <[email-masked]>
Date: Thu, 23 Aug 2012 09:36:49 +1000

IMO Best guess SPF immediately sounds like a bad idea.

However, if someone were to make an assumption "v=spf1 mx ?all" wouldn't
be a bad starting point - certainly better that the PTR lookups that
commonly take place.

The problem with inserting best guess is that there is no counterpart to
SoftFail on the positive side (no "SoftPass"). Which IMO would be a
mandatory starting point and therefore outside of the scope. 

(As an aside note, I've always regarded the lack of a "SoftPass" a
limitation of SPF)

Wayne

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Aug 2012 19:42:03 -0400

Wayne Doust <[email-masked]> wrote:

>limitation of SPF.

You can't have a "Sender Policy Framework" without a sender policy. Whatever "Best Guess" is, it's not SPF.

Scott K

---

From: Stuart Gathman <[email-masked]>
Date: Wed, 22 Aug 2012 21:02:17 -0400

>> SPF protocol document at all.  But I emphasise, I have no hat on.
It certainly isn't SPF, but it is a good idea IMO when there is no SPF 
record.  4408bis should explicitly forbidding calling it (or any other 
heuristic) an SPF result in Received-SPF or Authentication-Results.  
(And note that both Received-SPF and Authentication-Results provide 
extension frameworks for user-defined results.)

---

From: "John Levine" <[email-masked]>
Date: 23 Aug 2012 06:36:30 -0000

>there's non-trivial usage of it today.

I'd rather put it in a separate non-standards track document.

R's,
John