Re: [spfbis] Local macros strike again, was Suggestion...

[Scott Kitterman <[e-mail]>]

On Wednesday, January 18, 2012 05:46:19 AM Hector Santos wrote:
> Douglas Otis wrote:
> > On 1/13/12 5:42 PM, Hector Santos wrote:
> >>  Douglas Otis wrote:
> >> > Dear Hector,
> >> > 
> >> > This was simply explaining the impact caused by a change Wayne
> >> > Schlitt made to host name limits in his SPF library. He restricted
> >> > the number of host names resolved to 5. This caused a problem for
> >> > t-online.de who never published SPF records but were subjected to
> >> > "default" SPF records such as "a mx/24" and that had 8 hosts in
> >> > their MX RRset, for example. :^(
> >>  
> >>  Doug,
> >>  
> >>  Since I'm not familiar with the idea of a "default" SPF record, I
> >>  don't quite understand why a receiver would applied a "SPF default"
> >>  to a domain that did make any SPF explicit declaration. Why would
> >>  you
> >>  not expect to see problems with this? If this part of the
> >>  specification?
> > 
> > Dear Hector,
> > 
> > AFAIK, t-online.de never published SPF records.  Some implementers
> > leveraged SPF built-in functions to make "best guesses" about domains
> > lacking SPF records.  This tactic is found in many SPF implementations
> > as it will be for years.
> 
> Who?
> 
> This must be completed isolated.
> 
> I have a hard time understanding why would any system screw around
> with a guessing game  of "SPF default record" with completely not
> possibility for actual accuracy and yet, expect there would not be
> problem or rather begin to use this as some basis that something is
> broken about SPF!  I don't get it Doug. This would is already random.
> I see no way to presume there is a default SPF record without falling
> into trouble.
> 
> Now, if it was fundamentally the case that Senders *always* used an
> machine among the Receiveer network of MX host IP addresses, then I
> can see some default rules.  Sure.  But that is not reality. There is
> no requirement that a Sender machine must be part of any RECEIVER (MX)
> network.  This applies closer to smaller systems but not with larger
> network systems and not even with smaller systems.
> 
> I just don't see why you think this has any value.

The SPF "Best Guess" approach was supported early in SPF development 
(2003/2004) as a method to help bootstrap the protocol.  At the time, it was 
clearly described as something that was only even potentially useful for 
making positive assertions.  If someone based SPF rejections on a Best Guess 
record they were very mistaken.  I don't doubt this happened, but I don't 
think it's fundamentally an issue with the SPF protocol.  

The most that 4408bis might want to deal with the practice is to explicitly 
tell people not to make up SPF records for senders.

This, BTW, has nothing to do with local macros.

Also, a bit further up in the mail, the information about Wayne Schlitt's 
libspf2 is a bit misleading.  The limit of 5 pre-dated RFC 4408.  The current 
version of libspf2 uses the RFC 4408 limit of 10, so this notion that one of 
the editors of RFC 4408 had to use different limits in their implementation is 
not correct.

Scott K