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

Hector Santos <hsantos@isdg.net> Sun, 22 January 2012 05:55 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 9C2F821F84B2 for <spfbis@ietfa.amsl.com>; Sat, 21 Jan 2012 21:55:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.125
X-Spam-Level:
X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599]
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 fhB-QB+8feCE for <spfbis@ietfa.amsl.com>; Sat, 21 Jan 2012 21:55:50 -0800 (PST)
Received: from news.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE1521F84D5 for <spfbis@ietf.org>; Sat, 21 Jan 2012 21:55:49 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2468; t=1327211729; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=mTT2n90Hz48Aog7a1EifonA8mJA=; b=rZcfE05Z3hLA4Cs7ohCb W1RK6cqv7KJ6+QM29kQ8gPWQ0pmLvw/A2iSo8m237R5MMKy3WH+orZoL2u5yF8xA dgVxpaQjvtbeXPSDOAxyBHyht0YIlb8mphsrhtpxGNptBAMTduoc7SDzDPCku1fz O/B51uiMxHdVjC7afZXvrOU=
Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 22 Jan 2012 00:55:29 -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 413604580.46254.3900; Sun, 22 Jan 2012 00:55:28 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2468; t=1327211540; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2NJfK8R 4+Btx794JTf5iA1KXbyJW4ryXtvnt+lveQLA=; b=wlepgsbwsefJ4e3HOpCPpAR /ZTdHWa3rGozANIKz0Z/mNIdlyVpGkt05UGGr2ePZCE6LcYt98BRTyBRm3HnCGOR vxaLOfODnzrwNqJAzP3HOt+ltN91mM5lhKMupcWSzppAbPkbMvrHx0tqbfD+l+iY s3fm5eyn812xszF5OExI=
Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 22 Jan 2012 00:52:20 -0500
Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1012562939.6523.3404; Sun, 22 Jan 2012 00:52:19 -0500
Message-ID: <4F1BA4C2.9010705@isdg.net>
Date: Sun, 22 Jan 2012 00:55:14 -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" <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> <4F16A2FB.3070709@isdg.net> <F5833273385BB34F99288B3648C4F06F19C6C158E7@EXCH-C2.corp.cloudmark.com>
In-Reply-To: <F5833273385BB34F99288B3648C4F06F19C6C158E7@EXCH-C2.corp.cloudmark.com>
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: Sun, 22 Jan 2012 05:55:51 -0000

Hi Murray,

I guess it all depends on how its written, but my only concern is that 
no one should get bent out of shape about trying to implement a 
"default rule" that would apply to all. I say that from the point of 
view that REJECTION is a strong part of SPF and this best guess idea 
can only serve a purpose for "reporting," at best, for one data point:

     The sender and receiver are part of the same network.

If this was a fundamental concept for all, i.e. part of the spec, then 
I can see the default "rule" applying for filters and IMO, we really 
never would need SPF.

But that is not an SMTP setup operational requirement, so I find no 
value in this default rule other than getting some "interesting data 
point" about the sender network setup.  The Sender/Receiver is part of 
the same network. So what?  It means nothing, at least I don't see it 
unless a NON-SPF logic is done to see if the MX is black listed or 
doesn't exist.

Per SMTP, an MX is not a requirement and we use a fall back to the A 
record.  If that fails, depending on the implementation it could be 
filtered. i.e. many systems use a "NO MX/TRIED A record Once" concept 
when sending mail.

--


Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Hector Santos
>> Sent: Wednesday, January 18, 2012 2:46 AM
>> To: spfbis@ietf.org
>> Subject: Re: [spfbis] Local macros strike again, was Suggestion...
>>
>>> 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.
> 
> It's not.  A Google search for "best guess SPF" comes up with numerous records, and I've seen it referenced in white papers.  And I know for a fact that Gmail uses it.
> 
> The best definition I've seen is here: http://www.openspf.net/FAQ/Best_guess_record
> 
> I think part of the -bis effort should include an appendix that talks about this, albeit informatively, just so that a real consensus definition exists someplace.
> 
> -MSK
> _______________________________________________
> spfbis mailing list
> spfbis@ietf.org
> https://www.ietf.org/mailman/listinfo/spfbis
> 
> 

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