IETF Logo Mail Archive

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

Hector Santos <hsantos@isdg.net> Wed, 18 January 2012 10:47 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E6821F8602 for <spfbis@ietfa.amsl.com>; Wed, 18 Jan 2012 02:47:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.392
X-Spam-Level:
X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=-1.315, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBxZhSaairq1 for <spfbis@ietfa.amsl.com>; Wed, 18 Jan 2012 02:46:59 -0800 (PST)
Received: from ftp.catinthebox.net (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 901C121F8746 for <spfbis@ietf.org>; Wed, 18 Jan 2012 02:46:59 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2103; t=1326883612; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=FobzTWNx/B+KnSxldciA7kj4iMw=; b=bLkDbDK0cwFznWDn9YXQ fJp6R6iFFuTVg0wDo6NVzVynZyBnnR5DdCz/eKjaeOJjpYOmdps4KxaPQblM0M6b s8P40Rd/ButTqsXFJ59dh4PM3w5vRSRTPwjQldtglEItogrLijR4mTzHG9Q5YRZH YJoM2aezeJFgI8o2fekma6M=
Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Jan 2012 05:46:52 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 85491390.43773.2148; Wed, 18 Jan 2012 05:46:51 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2103; t=1326883429; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=BFVh8Zr goPS+Pdk0Fd5jUlhTQ0CK/OZLQCdT5KoTtN8=; b=iKLNa08nJ4r8YoKEHR2xlDh oUkID36T3z3Q2M7LwFiRrDm4yxYXNAvVVpJ7/sTdi6RUnJbo/uSyi/2MJDGhc9HQ B+5gSn51nMPw+4FyVXXmhbuQDHWTfANaO04h2nkhRFlHeUu0RdXiL3jFNeUTn5UQ QpmRMMoZoGmxp+ILoFHI=
Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 18 Jan 2012 05:43:49 -0500
Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 684452579.6079.6276; Wed, 18 Jan 2012 05:43:49 -0500
Message-ID: <4F16A2FB.3070709@isdg.net>
Date: Wed, 18 Jan 2012 05:46:19 -0500
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: spfbis@ietf.org
References: <F5833273385BB34F99288B3648C4F06F19C6C15673@EXCH-C2.corp.cloudmark.com> <4EF8F336.8080508@gathman.org> <F5833273385BB34F99288B3648C4F06F19C6C1569C@EXCH-C2.corp.cloudmark.com> <1590867.1quv5UxKKV@scott-latitude-e6320> <4EFCB88A.1080104@mail-abuse.org> <4EFE6F39.90000@isdg.net> <4F0358CC.6030505@mail-abuse.org> <4F03775B.4050905@isdg.net> <4F04E292.9030502@mail-abuse.org> <4F04FB1C.7070302@isdg.net> <4F060E74.2070103@cisco.com> <4F063F09.3030900@isdg.net> <4F06884D.2070509@mail-abuse.org> <4F082861.5080803@tana.it> <4F09269C.6090402@isdg.net> <4F0B0035.3050106@cisco.com> <4F0C9777.1090904@mail-abuse.org> <4F0C9E61.1010306@cisco.com> <4F0DD063.5090103@tana.it> <4F0E0A7E.1040905@isdg.net> <Pine.GSO.4.62.1201111726390.13909@spaz.oit.wmich.edu> <4F10BEED.7050207@mail-abuse.org> <4F10DD94.8040905@isdg.net> <4F1190BB.9080202@mail-abuse.org>
In-Reply-To: <4F1190BB.9080202@mail-abuse.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] Local macros strike again, was Suggestion...
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spfbis>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2012 10:47:00 -0000

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.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

v2.23.0 | Report a Bug | By Email