From dotis@mail-abuse.org Tue Jan 3 11:36:43 2012 Return-Path: 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 8DC3011E8099 for ; Tue, 3 Jan 2012 11:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.175 X-Spam-Level: X-Spam-Status: No, score=-101.175 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_40=-0.185, USER_IN_WHITELIST=-100] 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 wbqejswHNBo9 for ; Tue, 3 Jan 2012 11:36:43 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id DFB0C11E80CF for ; Tue, 3 Jan 2012 11:36:42 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway2.sdi.trendnet.org [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 525841740317 for ; Tue, 3 Jan 2012 19:36:42 +0000 (UTC) Message-ID: <4F0358CC.6030505@mail-abuse.org> Date: Tue, 03 Jan 2012 11:36:44 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <1590867.1quv5UxKKV@scott-latitude-e6320> <4EFCB88A.1080104@mail-abuse.org> <4EFE6F39.90000@isdg.net> In-Reply-To: <4EFE6F39.90000@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:36:43 -0000 On 12/30/11 6:11 PM, Hector Santos wrote: > Douglas Otis wrote: >> Is there any interest in assuring use of mx mechanism will work >> properly with domains publishing more than 5 MX records? > Can you illustrate the MX concern and whether there is an SPF problem > here? Hector, Most often this occurred as result of "default" SPF records applied where none were found. A common practice. A reduction in limits of subsequent hosts being resolved in many scripts is of course welcome. IIRC, t-online.de had more than 5 MX records, which now has 5 and still no SPF record. This problem was caused for senders not attempting to use SPF. There remains a significant discrepancy between implementation and specification. Many implementations do not accommodate common MX record use. The recommended subsequent recursion limit has not been followed for good reason. A specification that offers no warning or recommended minimum has not helped to ensure interchange. >> Many current SPF libraries process a maximum of 5 rather than the >> specified 10 to circumvent a possible 100+ DNS transactional >> sequence. The impact is this may cause intermittent failures >> difficult to troubleshoot. What makes this contentious is possible >> macro expansion of local-parts against cached SPF records. > > Doug, its been what? nearly 9, 10 years? I have yet to see a > situation that was not managed with the SPF implementation, especially > with recursive parts where limits are placed. We have a large complaint center.:^) At a recent MAAWG meeting, I led an ISP specific discussion regarding SPF use. There was consensus that rejecting failing SPF records ending with "-all" cause a large number of complaints. SPF registration is poorly understood and often misapplied even now. SPF records offering a pass do not necessarily confirm the domain originating the message either. In general, efforts are aimed at improving message acceptance rates. This has led some phishing sensitive senders to enter into private arrangements to ensure invalid DKIM messages are rejected. Even DKIM's low failure rate still has some wanting a fallback alternative. IMHO, address registration will remain and will become increasingly problematic. Few are willing to process million per second log entries. The SPF macro flexibility offered in terms of requesting ANY RR by the SPF "exists" mechanism, made against hosts derived from components of local-part addresses and script is not something easily ascertained. Email handles requests primarily originating directly or indirectly from compromised systems. Email's lack of source authentication has resulted in several orders of magnitude greater criminal use when compared to HTTP related sources. A poorly considered comparison when used to dismiss concerns. > I have yet to see or hear of any exploit that circumvents SPF > implementations. Its all theoretical with the presumption the > implementation is not aware of aggressive abuse. Few recipients expending resources processing SPF macros are likely to be the target of any attack and few retain a log of this activity. The targeted victim or the domain used to stage the attack need not appear anywhere within attacking messages. If SPF required specific resources be used either by type or by label, there might be a way to ascertain SPF's involvement. SPF does neither. The flexibility offered by SPF macros also means use of domain reputation will prove ineffective at mitigating this threat as well. -Doug From hsantos@isdg.net Tue Jan 3 13:47:36 2012 Return-Path: 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 3BFA211E80DD for ; Tue, 3 Jan 2012 13:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.43 X-Spam-Level: X-Spam-Status: No, score=-0.43 tagged_above=-999 required=5 tests=[AWL=-1.709, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_48=0.6] 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 27OrqOW8r85Q for ; Tue, 3 Jan 2012 13:47:35 -0800 (PST) Received: from ntbbs.santronics.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A1F3711E80AC for ; Tue, 3 Jan 2012 13:47:34 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=8074; t=1325627251; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ObaJAtn1v2Km3oqtZskNE3UWz8E=; b=nZrWlhRb22wpNFGq7fkc hLFUwN1IHtzpNcNo7U6JCsaNPvQYDgoHPMfix8BlIp2E5xSVfgl9VxZB67koeBsn hnoQUh0DnYl1jdR+J+LYrfjcbvNJQQNkyBMpipAupmxrGJvkAxz1n/DobB4SYIe/ L7WgrjjCy6LNHzgag+v53rY= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 03 Jan 2012 16:47:31 -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 3124112761.28557.3032; Tue, 03 Jan 2012 16:47:31 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=8074; t=1325627090; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=lece6Qp 8Z8taAsRQmMPi78y2LrvqDpr2w2wrJZhwvq8=; b=Lr6BVFL3yV6y6GPoJNySXqJ xiBmIa8MlcqjE2IIkx6Ncq0Ph7mnrmjVbC2fk/cDoj15WCA+pj7p5tu+NFCX1irN 1ggyNS8SXk3J6W4WD+rp5rVcGpZjzE2cqSsAcGLXkczJErdUgRy9biuYOMlRhfl1 s0iTBKVHp8QzFICE/o0E= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Tue, 03 Jan 2012 16:44:50 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3723080969.3306.7460; Tue, 03 Jan 2012 16:44:50 -0500 Message-ID: <4F03775B.4050905@isdg.net> Date: Tue, 03 Jan 2012 16:47:07 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <1590867.1quv5UxKKV@scott-latitude-e6320> <4EFCB88A.1080104@mail-abuse.org> <4EFE6F39.90000@isdg.net> <4F0358CC.6030505@mail-abuse.org> In-Reply-To: <4F0358CC.6030505@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:47:36 -0000 Douglas Otis wrote: > On 12/30/11 6:11 PM, Hector Santos wrote: >> Douglas Otis wrote: >>> Is there any interest in assuring use of mx mechanism will work >>> properly with domains publishing more than 5 MX records? >> Can you illustrate the MX concern and whether there is an SPF problem >> here? > Hector, > > Most often this occurred as result of "default" SPF records applied > where none were found. A common practice. Agreed, and probably the initial WIZARDS had a lot to do with that because initially when there was skepticism, the default was a neutral policy - a very wasteful policy especially when nothing else is available to give it any weight - negatively or positively. SPF-BIS should make a note that any attempt to explicitly declare a SPF policy SHOULD NOT be a wasteful policy for SPF receiver to process. > A reduction in limits of > subsequent hosts being resolved in many scripts is of course welcome. > IIRC, t-online.de had more than 5 MX records, which now has 5 and still > no SPF record. This problem was caused for senders not attempting to > use SPF. Not sure of the issue here since there is no SPF record for t-online.de. But overall, any DNS lookup for records will have limits placed. Including for MX and expansions. Robust DNS Clients are expected to be part of the SPF tool chest. > There remains a significant discrepancy between implementation and > specification. Many implementations do not accommodate common MX record > use. The recommended subsequent recursion limit has not been followed > for good reason. Where is the proof that it hasn't been followed? It would not be compliant if it did not control recursion. > A specification that offers no warning or recommended > minimum has not helped to ensure interchange. Well, maybe there is some truth to this "theoretically" but I have not seen any evidence of it. Limits are prudent SPF design otherwise you will get bitten. >> Doug, its been what? nearly 9, 10 years? I have yet to see a >> situation that was not managed with the SPF implementation, especially >> with recursive parts where limits are placed. > We have a large complaint center.:^) At a recent MAAWG meeting, I led > an ISP specific discussion regarding SPF use. There was consensus that > rejecting failing SPF records ending with "-all" cause a large number of > complaints. SPF registration is poorly understood and often misapplied > even now. SPF records offering a pass do not necessarily confirm the > domain originating the message either. I totally disagree with that consensus purely on the basis of its audience. Its like a gathering of all Republicans all agreeing that Obama is a BAD person. No truth to it. If I was in the Reputation Business, you can bet your boots I would have a strategic concern about how SPF does not HELP the business. I look at the technical merits. A Hard Policy is the most powerful, the most deterministic, the most beneficial and lowest overhead you can get. Of course, if you don't honor it, then you are undermining the Domain wishes, defeating its purpose and you will get a lot of overhead. Thats the problem I have with this GROUP - a majority of people who simply NEVER gave SPF any light in day - EVER. I mean it. So their blurts of failure is burned in and there was absolutely NEVER any evidence of that. That is why it had prosper despite all these erroneous negative statements about it. It is can stated in trade groups, doesn't make it true whatsoever. Now, if you said weaker indeterminate wasteful policies like SOFT or NEUTRAL, I agreed that that is a serious problem. But not the hard policy. > In general, efforts are aimed at improving message acceptance rates. > This has led some phishing sensitive senders to enter into private > arrangements to ensure invalid DKIM messages are rejected. Even DKIM's > low failure rate still has some wanting a fallback alternative. IMHO, > address registration will remain and will become increasingly problematic. DKIM has failed because it destroyed its HARD POLICY framework, making it weak and indeterminate, wasteful and so relaxed that no one required to following any kind of strong assertion about its presence in email. > Few are willing to process million per second log entries. The SPF > macro flexibility offered in terms of requesting ANY RR by the SPF > "exists" mechanism, made against hosts derived from components of > local-part addresses and script is not something easily ascertained. > Email handles requests primarily originating directly or indirectly from > compromised systems. Email's lack of source authentication has resulted > in several orders of magnitude greater criminal use when compared to > HTTP related sources. A poorly considered comparison when used to > dismiss concerns. Email's lack of ability to offer strong HARD policies is whats keeping this all open-ended and wasteful. SPF offers strong deterministic policies. So does DKIM with ADSP and its extensions with ACL and ATPS. If you wish to ignore these strong domain policies, then I don't how anyone can make a claim that there is a solution to any of these work, at any level. It will simply never WORK without some level of strong DOMAIN policies that receivers follow. It doesn't matter if its TRUST related - if we have support for TRUST working today, the same concept applies - you TRUST the domain or not and that information has to be passed to receivers one way or another. No matter what it is - hard core TRUE/FALSE policies are required about failure and the expectations by originating owners, domains or just plain people making a declaration about the way they do things. >> I have yet to see or hear of any exploit that circumvents SPF >> implementations. Its all theoretical with the presumption the >> implementation is not aware of aggressive abuse. > Few recipients expending resources processing SPF macros are likely to > be the target of any attack and few retain a log of this activity. The > targeted victim or the domain used to stage the attack need not appear > anywhere within attacking messages. If SPF required specific resources > be used either by type or by label, there might be a way to ascertain > SPF's involvement. SPF does neither. The flexibility offered by SPF > macros also means use of domain reputation will prove ineffective at > mitigating this threat as well. The only issue with SPF macros is the recursion potential and Doug, that is already 100% dealt with. Old news. The bottom line, there is no systemic problem with SPF and all the blurted catastrophic concerns about SPF is just that - erroneous fear mongering to replace it with other things and none of it was ever true nor materialized. It can be stated with any technology or protocol, including SMTP, FTP, NNTP, HTTP, etc, there is always some level of it being employed wrong. That absolutely does not suggest its universally true or the protocol is inherently problematic. Finally, I know each site has its own statistics, but looking at our 3-4 days for the DNS cache of SPF records, 2 of 613 had macros rules and they were attempts to record usage. And among those 2, one of those had a failed syntax. Go figure. Here was the break down: - Total : 613 - Total Bad : 15 - Total SPF1 : 583 - Total SPF2 : 15 (SENDER-ID) # of directives - Total MX : 435 - Total PTR : 325 - Total IP4 : 900 - Total IP6 : 3 - Total A : 437 - Total INCLUDE : 145 - Total REDIRECT : 5 - Total EXISTS : 2 Policy Types: - Total PASS : 6 - Total FAIL : 110 - Total SOFTFAIL : 411 - Total NEUTRAL : 86 (17 implicit) Directives with Policy Prefixes: - Total TAG PASS : 0 - Total TAG FAIL : 1 - Total TAG SOFTFAIL : 0 - Total TAG NEUTRAL : 2 These numbers mean number, but only to show the high amount of HARD+SOFTFAIL. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From msk@cloudmark.com Tue Jan 3 14:46:31 2012 Return-Path: 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 74AC711E8109 for ; Tue, 3 Jan 2012 14:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 We0JoPJ6xvlf for ; Tue, 3 Jan 2012 14:46:31 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0D90C11E8108 for ; Tue, 3 Jan 2012 14:46:31 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 14:46:25 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 3 Jan 2012 14:46:30 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 3 Jan 2012 14:46:30 -0800 Thread-Topic: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Index: AczKaTAdZqWFlE64QsWaJN4GvBcx2AAAFSBQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_F5833273385BB34F99288B3648C4F06F19C6C156E0EXCHC2corpclo_" MIME-Version: 1.0 Subject: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 22:46:31 -0000 --_002_F5833273385BB34F99288B3648C4F06F19C6C156E0EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've started this individual submission to correct the SPF entry in the Aut= hentication-Results result name table from "hardfail" to "fail", to match w= hat RFC4408 (and presumably RFC4408bis) says. This corrects an approved er= ratum against RFC5451. I suggested this as a first-tier work item for spfbis but there was resista= nce to doing so for the sake of keeping its charter lean; since it's really= a lightweight effort, I decided to move ahead with it on my own. Please give it a once over and a thumbs-up if I haven't missed anything. Thanks, -MSK --_002_F5833273385BB34F99288B3648C4F06F19C6C156E0EXCHC2corpclo_ Content-Type: message/rfc822 Received: from EXCH-HTCAS902.corp.cloudmark.com (172.22.10.74) by spite.corp.cloudmark.com (172.22.10.72) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 3 Jan 2012 14:44:01 -0800 Received: from mail.cloudmark.com (208.83.136.59) by ht2.cloudmark.com (172.22.10.81) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 14:44:00 -0800 Received: from mail.ietf.org ?(mail.ietf.org [12.22.58.30]) by mail.cloudmark.com (8.14.3/8.14.3) with ESMTP id q03Mi0LO002856 for ; Tue, 3 Jan 2012 14:44:00 -0800 (envelope-from i-d-announce-bounces@ietf.org) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348CF1F0C3E; Tue, 3 Jan 2012 14:43:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3997111E80FF for ; Tue, 3 Jan 2012 14:43:52 -0800 (PST) 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 xAFad9o2i+pt for ; Tue, 3 Jan 2012 14:43:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D124D11E80CE for ; Tue, 3 Jan 2012 14:43:51 -0800 (PST) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" Sender: "i-d-announce-bounces@ietf.org" Date: Tue, 3 Jan 2012 14:43:51 -0800 Subject: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Topic: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Index: AczKaTAdZqWFlE64QsWaJN4GvBcx2A== Message-ID: <20120103224351.24172.59587.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "internet-drafts@ietf.org" X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: exch-htcas902.corp.cloudmark.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-Exchange-Organization-SenderIdResult: Pass X-MS-Exchange-Organization-SCL: -1 X-MS-Exchange-Organization-PRD: ietf.org X-MS-TNEF-Correlator: received-spf: Pass (exch-htcas902.corp.cloudmark.com: domain of i-d-announce-bounces@ietf.org designates 12.22.58.30 as permitted sender) receiver=exch-htcas902.corp.cloudmark.com; client-ip=12.22.58.30; helo=mail.cloudmark.com; dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325630634; bh=hE9+aW5JP72WN5+in+cevhvU5MPcfUu6s/rlUqyue2E=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=F70l3eAnrHIN1vAAHs5oF6exHQ5ZCArti9tPo9jOI++kzzV3zfbbGiK+KFxEggfI2 bO3ACrf75/McJKsiEAH/i1kfG8xQY17FEWlxfDvR+/Bo+5nUDKA+wwcZk4IYpUMLdR ED/8hZAaJvr1+b9q6NyUzJwMNSuG0e4dFxwZNVRg= errors-to: i-d-announce-bounces@ietf.org delivered-to: i-d-announce@ietfa.amsl.com x-spam-flag: NO x-virus-scanned: amavisd-new at amsl.com x-spam-score: -102.582 x-spam-level: x-spam-status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] x-original-to: i-d-announce@ietfa.amsl.com x-beenthere: i-d-announce@ietf.org x-mailman-version: 2.1.12 list-id: Internet Draft Announcements only list-archive: list-post: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Authentication-Results Registration Update for SPF Resul= ts Author(s) : Murray S. Kucherawy Filename : draft-kucherawy-authres-spf-erratum-00.txt Pages : 5 Date : 2012-01-03 This memo updates the registry of authentication method results in Authentication-Results: message header fields, correcting a discontinuity between the original registry creation and the SPF specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kucherawy-authres-spf-erratum-00.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-kucherawy-authres-spf-erratum-00.t= xt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_002_F5833273385BB34F99288B3648C4F06F19C6C156E0EXCHC2corpclo_-- From spf2@kitterman.com Tue Jan 3 19:24:43 2012 Return-Path: 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 50E6211E808C for ; Tue, 3 Jan 2012 19:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 zSG+k3CfdZlI for ; Tue, 3 Jan 2012 19:24:41 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9334C11E8073 for ; Tue, 3 Jan 2012 19:24:41 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 184AE20E4100; Tue, 3 Jan 2012 22:24:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325647481; bh=00lCBxwFoQlWrjl17QchtySk3s2PJHf7NenxURsPi5A=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=BIVQ0eJ/vCmdu/vcYXmsyqxNr8FCRu/wRVmrd8EmG0Pmctr6d4OIQ3k9i/M+LV0pt jPfONiclE14UBOsoJc0pYLCknVx0HPOU5E1wOtHSC4M7Yj+hdBK2lpQZl+79F43in7 m8xbpJ9JZvI/3OZKexSv9BkGQVae6BIB7rL3aUI4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EE88020E409F; Tue, 3 Jan 2012 22:24:40 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Jan 2012 22:24:40 -0500 Message-ID: <1500824.ojDseZqxQR@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 03:24:43 -0000 On Tuesday, January 03, 2012 02:46:30 PM Murray S. Kucherawy wrote: > I've started this individual submission to correct the SPF entry in the > Authentication-Results result name table from "hardfail" to "fail", to > match what RFC4408 (and presumably RFC4408bis) says. This corrects an > approved erratum against RFC5451. > > I suggested this as a first-tier work item for spfbis but there was > resistance to doing so for the sake of keeping its charter lean; since it's > really a lightweight effort, I decided to move ahead with it on my own. > > Please give it a once over and a thumbs-up if I haven't missed anything. I think what's there is correct and a good change to make. If you want to take a step further and look and making Authentication Results a potential replacement for Received-SPF (up to you if you want to tackle this, it's your individual submission) there are additional changes needed. The most critical missing piece is a way to to distinguish between a Mail From and HELO result. Receivers commonly treat these differently and and Received- SPF provides this. I would recommend adding two new entries to the Email Authentication Method Name Registry: spf-mfrom spf-helo The values in the table would (minimally) be the same as the existing SPF entry (alternately it might be sufficient to define the current SPF entry as for Mail From - since that is by far the most common - and just add one new entry for spf-helo). Additionally, Received-SPF defines a key value list structure for comments about addiitonal information so that they can be machine parsed. I think this is an important part of the header field we should preserve. I think this will need to be more than an IANA registry change, however. Scott K From msk@cloudmark.com Tue Jan 3 19:31:38 2012 Return-Path: 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 6B05221F84B7 for ; Tue, 3 Jan 2012 19:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] 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 VJq7PX8e3FFm for ; Tue, 3 Jan 2012 19:31:38 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 103CC21F84B5 for ; Tue, 3 Jan 2012 19:31:38 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 19:31:32 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 3 Jan 2012 19:31:37 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 3 Jan 2012 19:31:35 -0800 Thread-Topic: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Index: AczKkGtqMnppuqhzQbqxECn8tDG8tQAAH/6w Message-ID: References: <1500824.ojDseZqxQR@scott-latitude-e6320> In-Reply-To: <1500824.ojDseZqxQR@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 03:31:38 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Tuesday, January 03, 2012 7:25 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum= -00.txt >=20 > The most critical missing piece is a way to to distinguish between a > Mail From and HELO result. Receivers commonly treat these differently > and and Received- SPF provides this. I would recommend adding two new > entries to the Email Authentication Method Name Registry: >=20 > spf-mfrom > spf-helo >=20 > The values in the table would (minimally) be the same as the existing > SPF entry (alternately it might be sufficient to define the current SPF > entry as for Mail From - since that is by far the most common - and > just add one new entry for spf-helo). I think this is already supported. The very last entry in Section 6.2 of R= FC5451 shows that you would do something like: Authentication-Results: hostname; spf=3Dpass smtp.mailfrom=3Dwhatever ...or: Authentication-Results: hostname; spf=3Dpass smtp.helo=3Dwhatever ...to indicate which evaluation was done. > Additionally, Received-SPF defines a key value list structure for > comments about addiitonal information so that they can be machine > parsed. I think this is an important part of the header field we > should preserve. I think this will need to be more than an IANA > registry change, however. Check the ABNF in Section 2.2. The "reasonspec" appears to do just this. -MSK From spf2@kitterman.com Tue Jan 3 20:40:49 2012 Return-Path: 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 DD0FA11E80AA for ; Tue, 3 Jan 2012 20:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 CkZuwlxLyPaX for ; Tue, 3 Jan 2012 20:40:46 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD1611E8098 for ; Tue, 3 Jan 2012 20:40:46 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8B78C20E4100; Tue, 3 Jan 2012 23:40:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325652044; bh=Zlq+BxIIpROlGWwvmz7LEKjuq7S4PnYFFcCeg0l9F9E=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=E928OHMjg/jMf+lMEnUmCxhRwjxDMpmW2bEExyYJuvoqsUIKLo5i+sl7dx67Km0qK WCHY3WPLNTlJIiU/xOVOXGut6Xm+9JNBdB95850FQPC8pwIIQ6lmSd9SsYnZuLvJEr Z57oDWPaBrawgjIfn+8mx0nSJU8RA+O3u7E7lOSI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7210520E409F; Tue, 3 Jan 2012 23:40:44 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Jan 2012 23:40:43 -0500 Message-ID: <1461456.9sGrbDcE3i@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <1500824.ojDseZqxQR@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 04:40:50 -0000 On Tuesday, January 03, 2012 07:31:35 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Tuesday, January 03, 2012 7:25 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] FW: I-D Action: > > draft-kucherawy-authres-spf-erratum-00.txt > > > > The most critical missing piece is a way to to distinguish between a > > Mail From and HELO result. Receivers commonly treat these differently > > and and Received- SPF provides this. I would recommend adding two new > > entries to the Email Authentication Method Name Registry: > > > > spf-mfrom > > spf-helo > > > > The values in the table would (minimally) be the same as the existing > > SPF entry (alternately it might be sufficient to define the current SPF > > entry as for Mail From - since that is by far the most common - and > > just add one new entry for spf-helo). > > I think this is already supported. The very last entry in Section 6.2 of > RFC5451 shows that you would do something like: > > Authentication-Results: hostname; spf=pass smtp.mailfrom=whatever > > ...or: > > Authentication-Results: hostname; spf=pass smtp.helo=whatever > > ...to indicate which evaluation was done. > OK. Perhaps I was misreading 5451 on that one. If I'm reading you right, you're suggesting a ptype of smtp, property of mailfrom or helo, and a pvalue of whatever, yielding a single propspec of smtp.mailfrom=whatever. > > Additionally, Received-SPF defines a key value list structure for > > comments about addiitonal information so that they can be machine > > parsed. I think this is an important part of the header field we > > should preserve. I think this will need to be more than an IANA > > registry change, however. > > Check the ABNF in Section 2.2. The "reasonspec" appears to do just this. I think it's close, but Received-SPF provides a list of "reasons" that implementations can standardize on (keys): key = "client-ip" / "envelope-from" / "helo" / "problem" / "receiver" / "identity" / mechanism / "x-" name / name This is important for machine parsing and interoperability. Scott K From msk@cloudmark.com Tue Jan 3 20:51:32 2012 Return-Path: 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 7FF8021F85A5 for ; Tue, 3 Jan 2012 20:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Kzy37QhHpStk for ; Tue, 3 Jan 2012 20:51:32 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 208A421F8480 for ; Tue, 3 Jan 2012 20:51:32 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 20:51:26 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 3 Jan 2012 20:51:31 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 3 Jan 2012 20:51:30 -0800 Thread-Topic: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Index: AczKmwz7Jiawt/7nT9qcRXEW6cdWcwAAPElg Message-ID: References: <1500824.ojDseZqxQR@scott-latitude-e6320> <1461456.9sGrbDcE3i@scott-latitude-e6320> In-Reply-To: <1461456.9sGrbDcE3i@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 04:51:32 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Tuesday, January 03, 2012 8:41 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum= -00.txt >=20 > OK. Perhaps I was misreading 5451 on that one. If I'm reading you > right, you're suggesting a ptype of smtp, property of mailfrom or helo, > and a pvalue of whatever, yielding a single propspec of > smtp.mailfrom=3Dwhatever. Yes. In fact I think those were added specifically because SPF wanted them= . > > Check the ABNF in Section 2.2. The "reasonspec" appears to do just > > this. >=20 > I think it's close, but Received-SPF provides a list of "reasons" that > implementations can standardize on (keys): >=20 > key =3D "client-ip" / "envelope-from" / "helo" / > "problem" / "receiver" / "identity" / > mechanism / "x-" name / name >=20 > This is important for machine parsing and interoperability. I think this would best be done in SPFbis itself, as an "Updates RFC5451" t= ype of thing. That is, enumerate these, and say people SHOULD use a reason= spec with one of them as the value when reporting SPF results using Authent= ication-Results. Then we could deprecate Received-SPF, or at least recomme= nd use of the newer header field. We should drop "x-" from that list though, in deference to draft-ietf-appsa= wg-xdash. -MSK From spf2@kitterman.com Tue Jan 3 20:56:56 2012 Return-Path: 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 3C06B11E8087 for ; Tue, 3 Jan 2012 20:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 zXjBIQw4nnEu for ; Tue, 3 Jan 2012 20:56:55 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0C511E8086 for ; Tue, 3 Jan 2012 20:56:55 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1563320E4100; Tue, 3 Jan 2012 23:56:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325653015; bh=mBn3Y1RNw+00CnnvJknXBcur7JmQILGXjgJYMFu/Nzk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=D8uwQMPo+ia5W2NVl6LgKVUiR+ahApej9GT2azcX1Dyl8CU2CKMAZCWhJbQQMLlpT RS+u/oJ9CPD1IZbwkLIulNx/5/7VuD+g+gYKQ4ionj5+b6X83RW1akOvABBjx2PPgR M8dBw4qN5xvhnIqNaexBTSb7CkVqHVreAFzKAyNg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ECB0420E409F; Tue, 3 Jan 2012 23:56:54 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 03 Jan 2012 23:56:54 -0500 Message-ID: <18677464.khoE2hKgGB@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <1461456.9sGrbDcE3i@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 04:56:56 -0000 On Tuesday, January 03, 2012 08:51:30 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Tuesday, January 03, 2012 8:41 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] FW: I-D Action: > > draft-kucherawy-authres-spf-erratum-00.txt > > > > OK. Perhaps I was misreading 5451 on that one. If I'm reading you > > right, you're suggesting a ptype of smtp, property of mailfrom or helo, > > and a pvalue of whatever, yielding a single propspec of > > smtp.mailfrom=whatever. > > Yes. In fact I think those were added specifically because SPF wanted them. It probably is. I was misreading the RFC (and some API documentation for the Python module for building Authentication Results headers. > > > Check the ABNF in Section 2.2. The "reasonspec" appears to do just > > > this. > > > > I think it's close, but Received-SPF provides a list of "reasons" that > > > > implementations can standardize on (keys): > > key = "client-ip" / "envelope-from" / "helo" / > > > > "problem" / "receiver" / > > "identity" / > > > > mechanism / "x-" name / > > name > > > > This is important for machine parsing and interoperability. > > I think this would best be done in SPFbis itself, as an "Updates RFC5451" > type of thing. That is, enumerate these, and say people SHOULD use a > reasonspec with one of them as the value when reporting SPF results using > Authentication-Results. Then we could deprecate Received-SPF, or at least > recommend use of the newer header field. > > We should drop "x-" from that list though, in deference to > draft-ietf-appsawg-xdash. At the time 4408 was written, x- was the standard method. I agree this can be done in 4408bis if it's in scope for the working group to do so. Scott K From vesely@tana.it Wed Jan 4 12:46:16 2012 Return-Path: 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 D616511E808F for ; Wed, 4 Jan 2012 12:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.109 X-Spam-Level: X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] 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 JHNdSqiBSy2s for ; Wed, 4 Jan 2012 12:46:16 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0A36B11E8089 for ; Wed, 4 Jan 2012 12:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325709974; bh=3d0rKyFfidSJ61KEmiaUwSDjoUYPJlWQ0Cuj8kRyUjQ=; l=1484; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WjrK9A3KKpYlRghlPEZcsQCceSxWY/g+GuHvO2aOmzbh0RUYmF4YO/h51Lstk6c+x cukoC44+j7AB9hyE+78u+ltNgOORn8Xwcbn6PW24cv7XvYcJiFGJDlhWE2qTh+9jUp dYM5lXwoSUYr2YdDKMLj1F9rLoLUfh/jMV3pm+RA= Received: from [109.113.8.240] ([109.113.8.240]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 04 Jan 2012 21:46:10 +0100 id 00000000005DC033.000000004F04BA94.00003FF5 Message-ID: <4F04BA7E.4080705@tana.it> Date: Wed, 04 Jan 2012 21:45:50 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1500824.ojDseZqxQR@scott-latitude-e6320> <1461456.9sGrbDcE3i@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:46:16 -0000 On 04.01.2012 05:51, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Scott Kitterman > >> I think it's close, but Received-SPF provides a list of "reasons" that >> implementations can standardize on (keys): >> >> key = "client-ip" / "envelope-from" / "helo" / >> "problem" / "receiver" / "identity" / >> mechanism / "x-" name / name >> >> This is important for machine parsing and interoperability. > > I think this would best be done in SPFbis itself, as an "Updates RFC5451" > type of thing. That is, enumerate these, and say people SHOULD use a > reasonspec with one of them as the value when reporting SPF results using > Authentication-Results. Then we could deprecate Received-SPF, or at least > recommend use of the newer header field. I'm not clear on how this is to be done. I wouldn't like the following: Authentication-Results: some-server.example; spf=neutral smtp.mailfrom=whatever reasonspec=x-bestguess=pass; The generic unquoted /name/ in the key rule doesn't suit required IANA registrations. SPF extensions will also have to register their properties and pvalues, if they are not to be considered different methods. What are the use cases for seldom used Received-SPF keys? Perhaps, we could limit A-R to concisely report the results. How about the following? Authentication-Results: some-server.example; spf=neutral smtp.mailfrom=whatever (this line could be omitted); spf-bestguess=pass smtp.mailfrom=whatever; From msk@cloudmark.com Wed Jan 4 12:49:27 2012 Return-Path: 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 9BF7311E80AF for ; Wed, 4 Jan 2012 12:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] 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 5oSTnjfAppGt for ; Wed, 4 Jan 2012 12:49:27 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 38AE611E80A6 for ; Wed, 4 Jan 2012 12:49:27 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 4 Jan 2012 12:49:21 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 4 Jan 2012 12:49:26 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Wed, 4 Jan 2012 12:49:25 -0800 Thread-Topic: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Index: AczLIejl8M3l46frT3eJQTAfIcZcBQAAEIbg Message-ID: References: <1500824.ojDseZqxQR@scott-latitude-e6320> <1461456.9sGrbDcE3i@scott-latitude-e6320> <4F04BA7E.4080705@tana.it> In-Reply-To: <4F04BA7E.4080705@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:49:27 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Wednesday, January 04, 2012 12:46 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum= -00.txt >=20 > I'm not clear on how this is to be done. I wouldn't like the > following: >=20 > Authentication-Results: some-server.example; > spf=3Dneutral smtp.mailfrom=3Dwhatever reasonspec=3Dx-bestguess=3Dpas= s; That wouldn't match the ABNF. If you want to show that SPF itself was neut= ral but best-guess SPF passed, you should register a method called "bestgue= ss-spf" and then report a separate result for it. From spf2@kitterman.com Wed Jan 4 12:51:12 2012 Return-Path: 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 7F52D11E80BE for ; Wed, 4 Jan 2012 12:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] 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 RVccdwXpxHEg for ; Wed, 4 Jan 2012 12:51:11 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D58F311E80BD for ; Wed, 4 Jan 2012 12:51:11 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BF3E620E4100; Wed, 4 Jan 2012 15:51:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325710269; bh=bhKEwkF4I1aFlYgArlXRhYG4OYlg5pHnPuObJ1tVtz8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ShWzEjKUkJlhSmGy5LjeAFqDw2483jK1jm/gexemEBfpR9OeBIyy5cw59ByBEF/wE +TYSRjwN/xFRhG0zFgK9zm6y9/bcqAEDnYq10xwXMSkVZHGqKSj0FacXYP6uNppZT4 ec6yNw+k7dAZmnoDUuNKxxIHgL8AomvhAd5v1jgM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A63FE20E4081; Wed, 4 Jan 2012 15:51:09 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 04 Jan 2012 15:51:09 -0500 Message-ID: <5066257.iriM1KbG7Y@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4F04BA7E.4080705@tana.it> References: <4F04BA7E.4080705@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:51:12 -0000 On Wednesday, January 04, 2012 09:45:50 PM Alessandro Vesely wrote: > On 04.01.2012 05:51, Murray S. Kucherawy wrote: > >> From: ietf.org On Behalf Of Scott Kitterman > >> > >> I think it's close, but Received-SPF provides a list of "reasons" that > >> > >> implementations can standardize on (keys): > >> key = "client-ip" / "envelope-from" / "helo" / > >> > >> "problem" / "receiver" / > >> "identity" / > >> > >> mechanism / "x-" name / > >> name > >> > >> This is important for machine parsing and interoperability. > > > > I think this would best be done in SPFbis itself, as an "Updates > > RFC5451" > > type of thing. That is, enumerate these, and say people SHOULD use a > > reasonspec with one of them as the value when reporting SPF results > > using > > Authentication-Results. Then we could deprecate Received-SPF, or at > > least recommend use of the newer header field. > > I'm not clear on how this is to be done. I wouldn't like the following: > > Authentication-Results: some-server.example; > spf=neutral smtp.mailfrom=whatever reasonspec=x-bestguess=pass; > > The generic unquoted /name/ in the key rule doesn't suit required IANA > registrations. SPF extensions will also have to register their properties > and pvalues, if they are not to be considered different methods. > > What are the use cases for seldom used Received-SPF keys? Perhaps, we could > limit A-R to concisely report the results. How about the following? > > Authentication-Results: some-server.example; > spf=neutral smtp.mailfrom=whatever (this line could be omitted); > spf-bestguess=pass smtp.mailfrom=whatever; If (and it's not clear we do yet) we want Authentication Results to supplant Recieved-SPF then I think it has to support the same information passing that Recieved-SPF support (to the extent the features are being used - perhaps not all of them are), so I think while the list could be constrained, I think it would be constrained to something pretty close to what's in RFC 4408 for Received-SPF. Some like receiver and IP address are very frequently used. Scott K From spf2@kitterman.com Wed Jan 4 12:52:44 2012 Return-Path: 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 2532021F8623 for ; Wed, 4 Jan 2012 12:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] 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 EKRlI75Fxk0f for ; Wed, 4 Jan 2012 12:52:43 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B431521F861C for ; Wed, 4 Jan 2012 12:52:43 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 49ED520E4100; Wed, 4 Jan 2012 15:52:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325710363; bh=77Bw1Dlh930AJSkLXwV/54mA3WluMZOdJlLT4w/Anq4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=p+4UjqHUFTgOblAshqmIOP20GiiFVyvUvlbynRkWWR+UiFxj+8E2ieVIP3jpckF1h mqWS7CsWxjUEiD9x0c2pEVQSLiLH6lpPjb3BiYXVDjFpbEEj/+maieqc8fkqm70aBe qnXooWOtSsXQpFpr7x/AzxhCkQ3UUuENL5Mcqooc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3DDDD20E4081; Wed, 4 Jan 2012 15:52:43 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 04 Jan 2012 15:52:42 -0500 Message-ID: <3231867.jDzYBP4rTF@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <4F04BA7E.4080705@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:52:44 -0000 On Wednesday, January 04, 2012 12:49:25 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Alessandro Vesely Sent: Wednesday, January 04, 2012 12:46 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] FW: I-D Action: > > draft-kucherawy-authres-spf-erratum-00.txt > > > > I'm not clear on how this is to be done. I wouldn't like the > > > > following: > > Authentication-Results: some-server.example; > > > > spf=neutral smtp.mailfrom=whatever reasonspec=x-bestguess=pass; > > That wouldn't match the ABNF. If you want to show that SPF itself was > neutral but best-guess SPF passed, you should register a method called > "bestguess-spf" and then report a separate result for it. +1. A best guess rule result isn't an SPF result and should not be reported as one. Scott K From msk@cloudmark.com Wed Jan 4 13:00:12 2012 Return-Path: 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 4083E11E80BD for ; Wed, 4 Jan 2012 13:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 oOG898LgYhUc for ; Wed, 4 Jan 2012 13:00:11 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 41AE811E809F for ; Wed, 4 Jan 2012 13:00:11 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 4 Jan 2012 13:00:05 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 4 Jan 2012 13:00:10 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Wed, 4 Jan 2012 13:00:08 -0800 Thread-Topic: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Index: AczLIpxU4zIFwkwIQFKzzrqHeORYRQAAFNiA Message-ID: References: <4F04BA7E.4080705@tana.it> <5066257.iriM1KbG7Y@scott-latitude-e6320> In-Reply-To: <5066257.iriM1KbG7Y@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:00:12 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Scott Kitterman > Sent: Wednesday, January 04, 2012 12:51 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum= -00.txt >=20 > If (and it's not clear we do yet) we want Authentication Results to > supplant Recieved-SPF then I think it has to support the same > information passing that Recieved-SPF support (to the extent the > features are being used - perhaps not all of them are), so I think > while the list could be constrained, I think it would be constrained to > something pretty close to what's in RFC 4408 for Received-SPF. Some > like receiver and IP address are very frequently used. I think the Updates/SHOULD approach I mentioned yesterday includes all of t= hat. From spf2@kitterman.com Wed Jan 4 13:05:44 2012 Return-Path: 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 7DD7211E80BF for ; Wed, 4 Jan 2012 13:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 7hRTi6EflpZd for ; Wed, 4 Jan 2012 13:05:43 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CDB4311E80BE for ; Wed, 4 Jan 2012 13:05:43 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6851020E4100; Wed, 4 Jan 2012 16:05:43 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325711143; bh=2BiWgYSjIwsS6PGXxm2QkVd1YZAgpy5mL4q5D4id9Wk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=GEMS8RI2VFay1SbBdkJOaLwW9tnS4pNeXI9on7I/lHJi4vYI+cceJqGruPlrtu/5/ escd951LBCi6oKPy/ziPHFG0FEjGNFSanegy+8t0UbBET1kGfjJVcT6vU1pR4TWj4V EpVt+dlc1B6Y+gX9TfYc47WP9rAHOL3Vz/DXy5YQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4F89820E4081; Wed, 4 Jan 2012 16:05:43 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 04 Jan 2012 16:05:42 -0500 Message-ID: <8728078.njKCkGZtXq@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <5066257.iriM1KbG7Y@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:05:44 -0000 On Wednesday, January 04, 2012 01:00:08 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf > > Of Scott Kitterman Sent: Wednesday, January 04, 2012 12:51 PM > > To: spfbis@ietf.org > > Subject: Re: [spfbis] FW: I-D Action: > > draft-kucherawy-authres-spf-erratum-00.txt > > > > If (and it's not clear we do yet) we want Authentication Results to > > supplant Recieved-SPF then I think it has to support the same > > information passing that Recieved-SPF support (to the extent the > > features are being used - perhaps not all of them are), so I think > > while the list could be constrained, I think it would be constrained to > > something pretty close to what's in RFC 4408 for Received-SPF. Some > > like receiver and IP address are very frequently used. > > I think the Updates/SHOULD approach I mentioned yesterday includes all of > that. I agree, as long as we put the right stuff on the list and don't overly contrain ourselves too early. Scott K From dotis@mail-abuse.org Wed Jan 4 15:36:49 2012 Return-Path: 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 4388911E813F for ; Wed, 4 Jan 2012 15:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.941 X-Spam-Level: X-Spam-Status: No, score=-100.941 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_50=0.001, USER_IN_WHITELIST=-100] 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 capqD2DoyRCt for ; Wed, 4 Jan 2012 15:36:47 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id E374111E8136 for ; Wed, 4 Jan 2012 15:36:47 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway2.sdi.trendnet.org [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id B9B5B1740121 for ; Wed, 4 Jan 2012 23:36:47 +0000 (UTC) Message-ID: <4F04E292.9030502@mail-abuse.org> Date: Wed, 04 Jan 2012 15:36:50 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <1590867.1quv5UxKKV@scott-latitude-e6320> <4EFCB88A.1080104@mail-abuse.org> <4EFE6F39.90000@isdg.net> <4F0358CC.6030505@mail-abuse.org> <4F03775B.4050905@isdg.net> In-Reply-To: <4F03775B.4050905@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:36:49 -0000 On 1/3/12 1:47 PM, Hector Santos wrote: > Douglas Otis wrote: > > On 12/30/11 6:11 PM, Hector Santos wrote: > >> Douglas Otis wrote: > >>> Is there any interest in assuring use of mx mechanism will work > >>> properly with domains publishing more than 5 MX records? > >> Can you illustrate the MX concern and whether there is an SPF > >> problem here? > > Hector, > > > > Most often this occurred as result of "default" SPF records applied > > where none were found. A common practice. > Agreed, and probably the initial WIZARDS had a lot to do with that > because initially when there was skepticism, the default was a > neutral policy - a very wasteful policy especially when nothing else > is available to give it any weight - negatively or positively. > SPF-BIS should make a note that any attempt to explicitly declare a > SPF policy SHOULD NOT be a wasteful policy for SPF receiver to > process. Hector, Not exactly. Some will substitute "No SPF Record" with a synthetic "v=spf1 a mx/24 ?all". This could produce a difficult to diagnose loss of DSNs or sporadic junk folder message placements. > > A reduction in limits of subsequent hosts being resolved in many > > scripts is of course welcome. IIRC, t-online.de had more than 5 MX > > records, which now has 5 and still no SPF record. This problem was > > caused for senders not attempting to use SPF. > Not sure of the issue here since there is no SPF record for > t-online.de. By not having an SPF record, some receivers employ "synthetic" records instead. The mx mechanism is flaky when generally applied largely because Wayne Schlitt changed the number of mx records his SPF library processed from 10 to 5. While a commendable change, it led to interchange issues which demand no more than 5 MX records be published, especially for domains making use of mx mechanisms in their records! The publisher does not control processing limits employed by recipients and the specification offers no minimum a requirement. Some have also suggested those affected by a long sequence of bogus host name requests result from improper DNS configuration. Per RFC2308, the SOA minimum field has had two previous meanings but now provides the requested duration of negative responses. Unfortunately, due to problems of blocked access leading to support calls, often recipients will override requested negative caching durations. Windows 2000 supports negative caching as specified in RFC2308, but with modifications of low maximum limits. Negative responses are held for the number of seconds specified in the NegativeCacheTime value with a default limit of 300 seconds. The value of NegativeCacheTime can be set to 0. However, it can not be greater than 15 minutes. For Windows 2008, the dnscmd supports /maxnegativecachettl with a default of 10 minutes. Bind 8 and 9 also provide global max-ncache-ttl to limit negative caching. Cisco offers similar methods to limit negative caching using the command dns set max-negcache-ttl that defaults to 1 hour. It would cost malefactors little of their resources to publish an SPF record: "v=spf1 exists:%{l}0.victim-domain exists:%{l}1.victim exists:%{l}2.victim-domain exists:%{l}3.victim-domain exists:%{l}4.victim-domain exists:%{l}5.victim-domain exists:%{l}6.victim-domain exists:%{l}7.victim-domain exists:%{l}8.victim-domain exists:%{l}9.victim-domain +all" This record will generate no traffic from the attacker's DNS after the first message, but may generate an endless series of 10 A record transactions/message against a victim domain when either the local-part in their return-path in their spam campaign does not repeat, or repeats after a sequence that is beyond negative cache limits commonly employed. Mx mechanisms can extend this sequence to 100/message. Our logs show malefactors have no problem not repeating. The source of these messages is typically a script running on a compromised system able to generate random local-part values. Most email is emitted from compromised systems where neither SPF nor Authentication-Results header fields identify or confirm the transmitter. The authentication-Results header field even fails to capture the source IP address! > But overall, any DNS lookup for records will have limits placed. > Including for MX and expansions. Robust DNS Clients are expected to > be part of the SPF tool chest. DNS clients and script processing libraries are not controlled by SPF record publishers. A client being robust does not help targeted victims either. Spammers use a technique some describe as a snowshoe method. Levels low enough to hide within the noise. SPF macros allow an attack to be broadly distributed at levels not noticed by any recipient, but still focused against a single victim. The victim that can not be deduced by message content, where victims are impacted to the point of having their link saturated with UDP traffic from an unlimited number of sources that can't be blocked or mitigated. When dealing with security, once demonstrated, seldom does one ask whether it is currently being exploited before looking for solutions. With SPF, the macro scripts are able to exploit far too much of the recipient's resources. Even a 1 to 1 reflected network amplification, rather than 150 to 1, or 50 to 1 represents a serious concern. Especially when a DDoS can be implemented concurrently with spamming. Often DDoS attacks are used to create a diversion or to slow distribution of intercept patterns. > Where is the proof that it hasn't been followed? It would not be > compliant if it did not control recursion. Check a selection of SPF libraries and test asserted limits. There is no required minimum. There is a recommended maximum where some libraries assert no limit or use the previous 20 SPF record recursive depth as a limit. Since record publishers are not processing the record, correct results depend upon undefined minimum processing limits. In the case of those developed by Wayne, this might be 5, and not 10 subsequent record resolutions. > > A specification that offers no warning or recommended minimum has > > not helped to ensure interchange. > Well, maybe there is some truth to this "theoretically" but I have > not seen any evidence of it. Limits are prudent SPF design otherwise > you will get bitten. Those _not_ using SPF are and have been affected! > > We have a large complaint center.:^) At a recent MAAWG meeting, > > I led an ISP specific discussion regarding SPF use. There was > > consensus that rejecting failing SPF records ending with "-all" > > cause a large number of complaints. SPF registration is poorly > > understood and often misapplied even now. SPF records offering a > > pass do not necessarily confirm the domain originating the message > > either. > I totally disagree with that consensus purely on the basis of its > audience. This was not my opinion. A redeeming feature of SPF was using scripts to determine which RBL currently lists the domain. > I look at the technical merits. A Hard Policy is the most powerful, > the most deterministic, the most beneficial and lowest overhead you > can get. Of course, if you don't honor it, then you are undermining > the Domain wishes, defeating its purpose and you will get a lot of > overhead. A large provider is wise not to reject on the basis of SPF failure when this generates expensive support calls. > Thats the problem I have with this GROUP - a majority of people who > simply NEVER gave SPF any light in day - EVER. I mean it. So their > blurts of failure is burned in and there was absolutely NEVER any > evidence of that. That is why it had prosper despite all these > erroneous negative statements about it. It is can stated in trade > groups, doesn't make it true whatsoever. Initially, many supported Sender-ID. Redmond offered $50K apiece to have it implemented. After some time, it became apparent Sender-ID would not resolve the phishing problem and it made path registration dependent upon email modification. Few now are willing to support Sender-ID. It also seems many view SPF as little more than a tool that can be used to investigate delivery issues, or to setup whitelists. Use of local-part macros or the exists mechanism would degrade or destroy even this limited utility. IMHO, the exists mechanism and local-part macros should be deprecated, with more stringent error limits placed on SPF processing libraries. > Now, if you said weaker indeterminate wasteful policies like SOFT or > NEUTRAL, I agreed that that is a serious problem. > > But not the hard policy. This is expressing a desire to assert control over outbound services. IMHO, outbound domains should stand on their own merit. Use of "-all" causes additional grief for little benefit. Domains prone to being phished should use DKIM, and hope recipient's MUAs check for invalid pre-pended header fields. :^) > DKIM has failed because it destroyed its HARD POLICY framework, > making it weak and indeterminate, wasteful and so relaxed that no one > required to following any kind of strong assertion about its presence > in email. In the Repute WG some expressed a desire for SPF or DKIM results to accrue against associated domains. DKIM never confirms who sent the message, nor intended recipients. Requiring SPF domains to pass in conjunction with their DKIM signatures would make DKIM far less robust, where some even desire a fall-back for failed DKIM signatures. Anyone blocking a domain on the basis of DKIM or SPF results is at risk, since this evidence never authenticates the domain actually responsible for transmitting the message. It is not wise to block the wrong domain. > Email's lack of ability to offer strong HARD policies is whats > keeping this all open-ended and wasteful. SPF offers strong > deterministic policies. So does DKIM with ADSP and its extensions > with ACL and ATPS. If you wish to ignore these strong domain > policies, then I don't how anyone can make a claim that there is a > solution to any of these work, at any level. It will simply never > WORK without some level of strong DOMAIN policies that receivers > follow. I agree with a need to curtail unauthenticated transmission and receipt of email. ATSP can only function properly with the authentication of outbound servers. While HELO/SPF could fulfill that role, the Internet environment now demands cryptographic methods. > It doesn't matter if its TRUST related - if we have support for TRUST > working today, the same concept applies - you TRUST the domain or not > and that information has to be passed to receivers one way or > another. > > No matter what it is - hard core TRUE/FALSE policies are required > about failure and the expectations by originating owners, domains or > just plain people making a declaration about the way they do > things. > > The only issue with SPF macros is the recursion potential and Doug, > that is already 100% dealt with. Old news. It has not been handled, only presumed handled. Email/DNS traffic is not analogous with other Internet traffic. Web services streamline transmitter authentication. Email avoids transmitter authentication and expects recipients to grant unknown entities script based access to their DNS resources. :^O > The bottom line, there is no systemic problem with SPF and all the > blurted catastrophic concerns about SPF is just that - erroneous fear > mongering to replace it with other things and none of it was ever > true nor materialized. An inability to discover evidence of a threat does not represent evidence of no threat. There are plenty of active threats not detected until someone looks. Carberp was a good example that affected several US government agencies and financial institutions by never escalating permissions. While you might not regularly see a DDoS attack, not everyone is that fortunate. SPF automatically grants access to DNS with SPF scripts running on behalf of any malefactor. http://blog.trendmicro.com/?p=34170 I suspect that in your SPF sampling you failed to accurately define which elements represent a macro. IMHO, % script expansion and various canned "mechanisms" should be considered active (recipient resource dependent) script components that increase the number of unique DNS transactions. -Doug From hsantos@isdg.net Wed Jan 4 17:22:02 2012 Return-Path: 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 987CD11E80CF for ; Wed, 4 Jan 2012 17:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, 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 AOlveWEoDbya for ; Wed, 4 Jan 2012 17:22:01 -0800 (PST) Received: from ntbbs.santronics.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6221C11E80B9 for ; Wed, 4 Jan 2012 17:22:01 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1377; t=1325726519; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Bdequ6nAb8/DmOwAX1A1a32KgcY=; b=tSQcUG3vugPIgE3Ne9hA coHvqQPW6wrYH4rtUHbuq57X7Br567EMF5eZJpYrxrEVOV1decBQiTCVRGypoVJ1 7VhViTi1d24YAf3uAPPOz+b1cRhgVf50hzpXDDnFA5MySJYNVpuyszAr5g87fE6m EjUywWFNyD3mrwSLtyqXVFw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 04 Jan 2012 20:21:59 -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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3223378959.28557.1168; Wed, 04 Jan 2012 20:21:58 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1377; t=1325726357; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bDdogC6 yEZDUX3ElTqj2SHdzZ18N2YX479bPqqQ/rxI=; b=Q7Cc5Mldkmn/Yas9ZUNp6k6 gKGlxN3AfNnYcM0SI7rui8YYL2mY9bMkJ4PP9J90+3eXXRBACGNfwgnk5zmX8B/K aCGejuRudlDJS8T72jguE7HSt8de+FbcZgvxUqTxdDmDbWuDeTKI7P+Tp6KKzwgZ 8IUjikJyAUVWberSFe4k= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 04 Jan 2012 20:19:17 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3822347157.3417.5064; Wed, 04 Jan 2012 20:19:16 -0500 Message-ID: <4F04FB1C.7070302@isdg.net> Date: Wed, 04 Jan 2012 20:21:32 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F04E292.9030502@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 01:22:02 -0000 Doug, If all this is about the need to have learned limits written in SPF-BIF. I agree. My point was that that it was learned long ago and the issues, i.e. required attention to recursion, buffer overflow and/or stack related issues, were addressed, trapped and mitigated. DNS caching is very important for today's modern SMTP system that is employing additional DNS related technologies. Sure, all these points are possible SPFBIF material that needs to be convey. > I suspect that in your SPF sampling you failed to accurately define > which elements represent a macro. IMHO, % script expansion and various > canned "mechanisms" should be considered active (recipient resource > dependent) script components that increase the number of unique DNS > transactions. No Doug. For the sample, it was two of 600+ SPF records with macros and both used it with EXISTS. One of those had a bad syntax for v=spf1, so the record was bad. Let me see the current accumulated cache. In this collection, over 1000+ SPF records. Only 2 with SPF macros. The same two as a matter of fact with the same one record with the bad syntax. Based on this, Macros are rarely used and I'm not surprised because historically only those trying to "track" usage were interested in them. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From vesely@tana.it Thu Jan 5 04:55:15 2012 Return-Path: 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 2ED9F21F8824 for ; Thu, 5 Jan 2012 04:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] 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 L7q1yF0gdXVg for ; Thu, 5 Jan 2012 04:55:14 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4D92421F8823 for ; Thu, 5 Jan 2012 04:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325768112; bh=3FuCgX+wKT9Rkvh6QLNaWnMsBQ1VQCz7EiVgbWfZoUs=; l=841; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=eXo5mV0osEZxk7h3znFOoKPa1OqLr4lBcHf0e3ZGuTxkEEq7XoqPRsVy84vcY3oSd 4aHnOMU7bLb3yUj1GFmmZK/fwzTcD5Iq+TGpSgdPtofLG/7s4zAmodNJmXh9QP7OvG wwGSCNAKGSDX/o9EoHhHQZ9wQwWUuZXYu1P0pOpA= Received: from [109.115.205.6] ([109.115.205.6]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 05 Jan 2012 13:55:10 +0100 id 00000000005DC033.000000004F059DAF.0000176C Message-ID: <4F059DA5.8040206@tana.it> Date: Thu, 05 Jan 2012 13:55:01 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1500824.ojDseZqxQR@scott-latitude-e6320> <1461456.9sGrbDcE3i@scott-latitude-e6320> <4F04BA7E.4080705@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 12:55:15 -0000 On 04.01.2012 21:49, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >> I'm not clear on how this is to be done. I wouldn't like the >> following: >> >> Authentication-Results: some-server.example; >> spf=neutral smtp.mailfrom=whatever reasonspec=x-bestguess=pass; > > That wouldn't match the ABNF. If you want to show that SPF itself was > neutral but best-guess SPF passed, you should register a method called > "bestguess-spf" and then report a separate result for it. Thanks for the clarification. Thus the following should work Authentication-Results: some-server.example; spf=neutral smtp.mailfrom=whatever (this line could be omitted); spf-bestguess=pass smtp.mailfrom=whatever; Since we're at it, do you think such method can be registered by your presently in subject draft? From vesely@tana.it Thu Jan 5 05:21:47 2012 Return-Path: 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 89CF721F8839 for ; Thu, 5 Jan 2012 05:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.659 X-Spam-Level: X-Spam-Status: No, score=-4.659 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 eBIPLkR7mb-7 for ; Thu, 5 Jan 2012 05:21:46 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B789B21F8549 for ; Thu, 5 Jan 2012 05:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325769705; bh=mLaPEDW0BYo+DiJmIVxXiUE3e+11T3/7UeRXTjWnB/w=; l=910; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=aYJvqfoHw0t9aPYRXkjbEfyQKrTucoKWseOoJ+Yw8ZTy0kfcMZd4HZ6nBinLQCODk HALpoUIMinGvJdhAqhSxjs8W/qq/VZ6dIrf8iD5Tyl9U6OlUyFZu6QmQMt5ChTLo0X eVAo/7JTCR5dMEDBDruipHvbXM3wMfAZ+gyvHns8= Received: from [109.115.205.6] ([109.115.205.6]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 05 Jan 2012 14:21:43 +0100 id 00000000005DC033.000000004F05A3E8.00001DC1 Message-ID: <4F05A3DA.1020101@tana.it> Date: Thu, 05 Jan 2012 14:21:30 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F04BA7E.4080705@tana.it> <5066257.iriM1KbG7Y@scott-latitude-e6320> In-Reply-To: <5066257.iriM1KbG7Y@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 13:21:47 -0000 On 04.01.2012 21:51, Scott Kitterman wrote: > > If (and it's not clear we do yet) we want Authentication Results to supplant > Recieved-SPF then I think it has to support the same information passing that > Recieved-SPF support (to the extent the features are being used - perhaps not > all of them are), so I think while the list could be constrained, I think it > would be constrained to something pretty close to what's in RFC 4408 for > Received-SPF. Some like receiver and IP address are very frequently used. Indeed, including the IP address was the subject of Section 2 of this appeal: http://www.sonic.net/~dougotis/id/draft-otis-auth-header-sec-issues-00.html (See also http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000511.html) IMHO, they are two different header fields, with different aims, and the cycles required to make them equal could be better spent in useful tasks. From dotzero@gmail.com Thu Jan 5 06:21:29 2012 Return-Path: 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 F09FA21F86E3 for ; Thu, 5 Jan 2012 06:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 drPrIoglqIZQ for ; Thu, 5 Jan 2012 06:21:28 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 822B321F86DB for ; Thu, 5 Jan 2012 06:21:28 -0800 (PST) Received: by dajz8 with SMTP id z8so435673daj.31 for ; Thu, 05 Jan 2012 06:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bdmfk6Ta8N1CSO9TBR+JXVzURIK9eUlk6YQZFNRy0r0=; b=WwZNIQ1+Mqhz9LLp2QLMpQb16CIzps1fUKpGmFWl8fX4F8VI/TKXWMw19f+xaRK1BH 7w4o0Vn+eZ+Wk3gGqXz212OOXCFQXjbCi8AIF5gZofSotZsuu3ln1d+lOMTVeIfYwGa8 WhzkkJE9rIovvTw7sQnEtrgFK/cxKjfzFH3S8= MIME-Version: 1.0 Received: by 10.68.119.162 with SMTP id kv2mr5779327pbb.72.1325773287871; Thu, 05 Jan 2012 06:21:27 -0800 (PST) Received: by 10.143.146.21 with HTTP; Thu, 5 Jan 2012 06:21:27 -0800 (PST) In-Reply-To: <3231867.jDzYBP4rTF@scott-latitude-e6320> References: <4F04BA7E.4080705@tana.it> <3231867.jDzYBP4rTF@scott-latitude-e6320> Date: Thu, 5 Jan 2012 09:21:27 -0500 Message-ID: From: Dotzero To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 14:21:29 -0000 On Wed, Jan 4, 2012 at 3:52 PM, Scott Kitterman wrote: > > A best guess rule result isn't an SPF result and should not be reported as > one. > +1 From hsantos@isdg.net Thu Jan 5 06:36:49 2012 Return-Path: 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 5DB3B21F8780 for ; Thu, 5 Jan 2012 06:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 ii8CJW+GEFzV for ; Thu, 5 Jan 2012 06:36:48 -0800 (PST) Received: from dkim.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2A01E21F876C for ; Thu, 5 Jan 2012 06:36:48 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=271; t=1325774205; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=LpDHUCn0Zay9j/+Wz6RCzbVcTNw=; b=SVSz+j6q7+yI/tx92ewW JUQ3wsG4R4vOLYrc1z/ivoO+1auzqA7qKoVZhKd1Yh3Ndc2fdojgm0qGzuNoz/jk 0hvpRChZIO5pOZfQQ/noXUjp+88+Q4sPohHJAkG4LGyj/X3cWdtwQS1ut3lHlabX N07hTvkjE1sbykLL525frcw= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 05 Jan 2012 09:36:45 -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 3271064408.28557.1776; Thu, 05 Jan 2012 09:36:44 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=271; t=1325774040; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=LcOIwsb KB0wf2Keg8wO4TR8I8NZfPX48Y2833r93HdA=; b=ZFQ2BL4D4XeO4GgSis6yHnA mrZ2sV/S7DZX/YARy51YB3CNgTOilNZaRBiOw9hOJL3Ixa91Kp128DBZMTnoCq/a oSDv9YDTohg98ns1YEs1tMmhwVzNZRYuZSMj6x4A4R3Q4M6qt8A8prwQwYuF0wLU HWQF/CL2edTdNDPbt7js= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 05 Jan 2012 09:34:00 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3870030438.3475.4892; Thu, 05 Jan 2012 09:33:59 -0500 Message-ID: <4F05B560.2090200@isdg.net> Date: Thu, 05 Jan 2012 09:36:16 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4F04BA7E.4080705@tana.it> <3231867.jDzYBP4rTF@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 14:36:49 -0000 Dotzero wrote: > On Wed, Jan 4, 2012 at 3:52 PM, Scott Kitterman wrote: > >> A best guess rule result isn't an SPF result and should not be reported as >> one. >> > > +1 +1 -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dhc2@dcrocker.net Thu Jan 5 06:40:40 2012 Return-Path: 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 84E0D21F87FE for ; Thu, 5 Jan 2012 06:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 YcCQSydqjhiH for ; Thu, 5 Jan 2012 06:40:39 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCAC21F878B for ; Thu, 5 Jan 2012 06:40:33 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q05EeRWv026162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jan 2012 06:40:32 -0800 Message-ID: <4F05B657.5010403@dcrocker.net> Date: Thu, 05 Jan 2012 06:40:23 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Scott Kitterman References: <4F04BA7E.4080705@tana.it> <3231867.jDzYBP4rTF@scott-latitude-e6320> In-Reply-To: <3231867.jDzYBP4rTF@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 05 Jan 2012 06:40:33 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 14:40:40 -0000 On 1/4/2012 12:52 PM, Scott Kitterman wrote: > On Wednesday, January 04, 2012 12:49:25 PM Murray S. Kucherawy wrote: >> That wouldn't match the ABNF. If you want to show that SPF itself was >> neutral but best-guess SPF passed, you should register a method called >> "bestguess-spf" and then report a separate result for it. > > +1. > > A best guess rule result isn't an SPF result and should not be reported as > one. +1 Protocol standards do not include heuristics. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Thu Jan 5 09:11:42 2012 Return-Path: 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 2D83621F8829 for ; Thu, 5 Jan 2012 09:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 4bk2oFjU-szp for ; Thu, 5 Jan 2012 09:11:41 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id CB88121F87B9 for ; Thu, 5 Jan 2012 09:11:41 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 5 Jan 2012 09:11:35 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 5 Jan 2012 09:11:41 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Thu, 5 Jan 2012 09:11:40 -0800 Thread-Topic: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt Thread-Index: AczLqUpEdKtkRmZoSmqulMzLGny/HAAI7Zjg Message-ID: References: <1500824.ojDseZqxQR@scott-latitude-e6320> <1461456.9sGrbDcE3i@scott-latitude-e6320> <4F04BA7E.4080705@tana.it> <4F059DA5.8040206@tana.it> In-Reply-To: <4F059DA5.8040206@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:11:42 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Alessandro Vesely > Sent: Thursday, January 05, 2012 4:55 AM > To: spfbis@ietf.org > Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum= -00.txt >=20 > Since we're at it, do you think such method can be registered by your > presently in subject draft? No, piggybacking on an erratum is not appropriate. The spfbis working group can take this on when it recharters. From stpeter@stpeter.im Thu Jan 5 09:18:17 2012 Return-Path: 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 0A67221F86F8 for ; Thu, 5 Jan 2012 09:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 oCWiIqOfgq4E for ; Thu, 5 Jan 2012 09:18:16 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9E63D21F86DF for ; Thu, 5 Jan 2012 09:18:16 -0800 (PST) Received: from dhcp-64-101-72-192.cisco.com (unknown [64.101.72.192]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 948794009B; Thu, 5 Jan 2012 10:26:58 -0700 (MST) Message-ID: <4F05DB59.9090700@stpeter.im> Date: Thu, 05 Jan 2012 10:18:17 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <1500824.ojDseZqxQR@scott-latitude-e6320> <1461456.9sGrbDcE3i@scott-latitude-e6320> <4F04BA7E.4080705@tana.it> <4F059DA5.8040206@tana.it> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:18:17 -0000 On 1/5/12 10:11 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Alessandro Vesely >> Sent: Thursday, January 05, 2012 4:55 AM >> To: spfbis@ietf.org >> Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt >> >> Since we're at it, do you think such method can be registered by your >> presently in subject draft? > > No, piggybacking on an erratum is not appropriate. > > The spfbis working group can take this on when it recharters. Agreed. Peter -- Peter Saint-Andre http://stpeter.im/ From pgladstone@cisco.com Thu Jan 5 12:56:38 2012 Return-Path: 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 C573721F8883 for ; Thu, 5 Jan 2012 12:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6] 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 FvVhJAonps-u for ; Thu, 5 Jan 2012 12:56:38 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 68F4721F8882 for ; Thu, 5 Jan 2012 12:56:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=10565; q=dns/txt; s=iport; t=1325796997; x=1327006597; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=JpUNerXYHc+krKle+svSCNYNS9TPpB2bwtXj1xjruoo=; b=FLWqK9/bNA1NX8qRfYBc2WlbKGQTv6UOUCw+jWwV3RjRk05sR9+gY7Oj /xEf6XR80rDueNlWZWGAwcBQDwMu4puGJrKwkZ/0nHnmmE4doNJTBA83t sJEIs1GDe2tebL08WR4mLLd7LNLU/zQrJiqNyPfMIobbtD4E9dTXesFBl k=; X-Files: smime.p7s : 4899 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0EAD0OBk9Io8UY/2dsb2JhbAA/A4IFgwqodIFyAQEBBBIBEFUPAgsYCRYLAgICBwMCAQIBCTwTBgIBAR6fYQGMXZFCBIhuggmBFgSIOYVwgReFRoVPjQQ X-IronPort-AV: E=Sophos;i="4.71,464,1320624000"; d="p7s'?scan'208";a="2854706" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 05 Jan 2012 20:56:25 +0000 Received: from [161.44.106.143] (dhcp-161-44-106-143.cisco.com [161.44.106.143]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q05KuLPC027589 for ; Thu, 5 Jan 2012 20:56:22 GMT Message-ID: <4F060E74.2070103@cisco.com> Date: Thu, 05 Jan 2012 15:56:20 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F04FB1C.7070302@isdg.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040006090803020804090208" Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 20:56:38 -0000 This is a cryptographically signed message in MIME format. --------------ms040006090803020804090208 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 1/4/2012 8:21 PM, Hector Santos wrote: > Doug, > > If all this is about the need to have learned limits written in=20 > SPF-BIF. I agree. My point was that that it was learned long ago and=20 > the issues, i.e. required attention to recursion, buffer overflow=20 > and/or stack related issues, were addressed, trapped and mitigated.=20 > DNS caching is very important for today's modern SMTP system that is=20 > employing additional DNS related technologies. > > Sure, all these points are possible SPFBIF material that needs to be=20 > convey. > >> I suspect that in your SPF sampling you failed to accurately define=20 >> which elements represent a macro. IMHO, % script expansion and=20 >> various canned "mechanisms" should be considered active (recipient=20 >> resource dependent) script components that increase the number of=20 >> unique DNS transactions. > > No Doug. For the sample, it was two of 600+ SPF records with macros=20 > and both used it with EXISTS. One of those had a bad syntax for=20 > v=3Dspf1, so the record was bad. > > Let me see the current accumulated cache. In this collection, over=20 > 1000+ SPF records. Only 2 with SPF macros. The same two as a matter = > of fact with the same one record with the bad syntax. > > Based on this, Macros are rarely used and I'm not surprised because=20 > historically only those trying to "track" usage were interested in them= =2E In my list of SPF records, I have over 80 distinct records (after=20 eliminating the ip addresses, domain names etc) which use macros. A few=20 of these records are invalid. I don't know what volume of traffic is=20 sent with SPF records that use macros.... The macros are used in exists:, exp=3D, include:, a:, mx:, redirect=3D The actual macros were: %{d} %{h} %{ir} %{i} %{l1r+} %{l1r-} %{l} %{o}=20 %{r} %{s} -- i.e. nobody is using v, p, c, or t. The actual clauses were (for some value in ) a:%{ir}. a:.%{d} a:.%{o} exists:%{ir}. exists:%{ir}._ip.%{l}. exists:%{ir}.mrbl.%{d} exists:%{i}.%{l1r-}.user.%{d} exists:%{i}.%{l}. exists:%{i}.3/86400.rate.%{d} exists:%{i}. exists:%{i}._.%{h}._.%{s}. exists:%{i}._.%{h}._.%{s}._.%{r}. exists:%{l1r+}. exists:%{l}.%{ir}. exists:%{l}.%{i}. exists:%{l}.%{o}.%{i}.%{h}. exists:%{l}. exists:%{l}.x.%{ir}. exists:%{s}.%{i}. exists:%{s}. exists:%{s}.EmailAddr.%{i}. exists:%{s}.S.%{i}. exists:%{s}.sending-to.%{r}.from-ip-address-%{i}. exists:%{s}_%{i}_ exists:CL.%{i}.FR.%{s}. exists:CL.%{i}.FR.%{s}.HE.%{h}. exists:I.%{i}.F.%{l}.%{o}.H.%{h}. exists:IP%{i}.H%{h}.D%{d}. exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._s.%{s}._r.%{r}. exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} exists:h_%{h}-i_%{i}-%{s}. exists:i%{i}.f%{s}. exp=3D.%{d} include:%{l}.%{o}. include:.%{d} mx:.%{d} redirect=3D%{l}. redirect=3D%{o}. redirect=3D.%{d} Philip --=20 Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ --------------ms040006090803020804090208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2TCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUpMIIEEaAD AgECAhBluzNhw6CDObOmDguxgJDVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwNjAwMDAwMFoXDTEyMDkwNTIzNTk1 OVowJTEjMCEGCSqGSIb3DQEJARYUcGdsYWRzdG9uZUBjaXNjby5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC8ShP963c4uAJcGoHC2JCwJKJth79tIXQ2aVrtbK1tN5vi eX+0nKzylBxgLOfpyPuYxGuya1GNLXPXCnIp8sYpy6AlaQw2laBBODjl13Yjgnv/jlpVmE4d AwhRqWdcCH0WkrKniZiFEr72GUfhemnFNXILC5D82IiDOjqQ4guzO+ll/OoyYNBwx7ux4WAH hebTSrXcciAq/TqZnc8HlimFC6kS53kQdNd/MsYWNKVSj/60WxaHqFAjeRDopmZ4IDR2GvgX W7N4UIzXIcpJW8DC/KktfMxo/DXhi64RY3mLE0cxepA/D0T94uVwKXHneE9Q+GNhcNBIE4hT NrcsSlNbAgMBAAGjggHkMIIB4DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAd BgNVHQ4EFgQUEB9ztHyHGmanfNM9BLyVUI828nEwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB /wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQE AwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNv bW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2Eu Y29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYI KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRwZ2xhZHN0 b25lQGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAASu4Jrf2J6VFo8sJU04WDaW5P3wa jd5RSUWyhAgC/Doog4YlFvfQInnsMiEh069+czqynhigU8ahGOwzRCvZC044sPWU53wtz0Wp jzz9I/2ekKDceJr+Neu1tcIrH2eqrjwE0Mn+pbsUw1eUn7G7bq1B8gT6TAEx3mrrxXCr2mkQ VABiT1L1rkkcGpvV5ls040AU5Oe9bPPgtlWh7qjcaXBeOsYu5EAqRtbP+w7LeVfs0W0vXG1O h9O3X2FCHqZrQTh5gj3by4p0bssKCMKk/pELMzi5uHfB2OZhG4gLxTqwkVVXXcfCt2s/Womp 4TeiuQm/aozNUjlJQSfDYKaaETGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFD T01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhBluzNhw6CDObOmDguxgJDVMAkGBSsOAwIaBQCgggI4 MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEwNTIwNTYy MFowIwYJKoZIhvcNAQkEMRYEFOMT/OeAnz4OZl7S7Lqtd86MdHgzMF8GCSqGSIb3DQEJDzFS MFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBluzNhw6CDObOmDguxgJDV MIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZbszYcOggzmzpg4LsYCQ1TANBgkqhkiG9w0BAQEFAASCAQAviGa7oHjw IM2Bc+uzI+9jSAFBpqQRpnp0bOVaQpGeZzH+9/nnIgaZi9o2ADqO3UxC/EUvtjnwd89opJ+E MmLGe1T9LmbrsBcjkQDKGn55deSoqAxr57+Pg/KDbUm09Ue5kMiH6fpKuUxGtIyiSGnYWOI1 /5eoDShiPunYBqKj6hN5W5H90iQM7DxO2c9lc3J9/n3DW67/BBweffXWoAekd9ncxgD1I9k3 y44uH/tjKORWXJczvQ6ySl5q8DA6Jmeuu9GW8SdQV2NI1gpxW07r/mVT8B4PL1XCo4D5DFNx +9R6iSIiDDrIe1zRDwM3PGIiffACZlbreU9AAKLC/wdOAAAAAAAA --------------ms040006090803020804090208-- From SRS0=PjBt0=7Q==stuart@gathman.org Thu Jan 5 13:57:15 2012 Return-Path: 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 866E121F858B for ; Thu, 5 Jan 2012 13:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 7w3U89hiKKGS for ; Thu, 5 Jan 2012 13:57:15 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id B1BB221F858A for ; Thu, 5 Jan 2012 13:57:14 -0800 (PST) Received: from sdg.bmsi.com (sdg.bmsi.com [192.168.9.34] (may be forged)) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q05LuVfk014372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jan 2012 16:56:34 -0500 Message-ID: <4F061CB6.5030909@gathman.org> Date: Thu, 05 Jan 2012 16:57:10 -0500 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F04E292.9030502@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:04:27 -0000 Long ago, Nostradamus foresaw that on 01/04/2012 06:36 PM, Douglas Otis would write: > > Not exactly. Some will substitute "No SPF Record" with a synthetic > "v=spf1 a mx/24 ?all". This could produce a difficult to diagnose > loss of DSNs or sporadic junk folder message placements. Whatever problem you are worried about here, it is not an SPF problem. The spec is already clear that any result from such practices (and I myself am such a practitioner) is *not* an SPF result and MUST NOT be reported as such. In the discussion of the Authentication-Results header field, we did talk about needing a way to report such heuristic results (but not as SPF results). From hsantos@isdg.net Thu Jan 5 16:24:19 2012 Return-Path: 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 F403B21F8842 for ; Thu, 5 Jan 2012 16:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, 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 dKHxRFdZaj7h for ; Thu, 5 Jan 2012 16:24:17 -0800 (PST) Received: from dkim.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3DB21F8837 for ; Thu, 5 Jan 2012 16:24:17 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4934; t=1325809446; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=dEj4LwDqK6M6DyjfB+m0xkGQIVw=; b=AEf+Rcr/RB3WgUwca384 fRpon6ufG/+usKkJ++H2yP9/VwEtpXWJftzYIoJ1R0LBMSEOx8IQNKjM1wYQn1Jq 3JFagQpPX3Nt5n5ROyiaxQsskM7Lt0GvKbxluOxdwFFNkN/ueWtZLyNSGSJ2KvqU szgKRFLS9rlOGlQQgCfEBss= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 05 Jan 2012 19:24:06 -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 3306304832.28557.520; Thu, 05 Jan 2012 19:24:05 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4934; t=1325809280; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=rHj7FQG OO1wkq1K9bEUIzxN2rb9nHMY1np33Ntwhs9U=; b=ONnM+msN5bG7Kwm4Ek8lwjN 3LAF081JVY/TcoG4xvnNrZbEdK5qR1kmE9XxlB5NnIemh4JOTdTPB6ln02yt20E0 PIgzqUpWi9LhnIhvSd0AuvY4vLgb9UGOUFJXIVGniSO6YRGr+j+2imW35plUIlBm 6+OZakNv8V+lcMTxNliM= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 05 Jan 2012 19:21: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 3905270844.3521.3740; Thu, 05 Jan 2012 19:21:20 -0500 Message-ID: <4F063F09.3030900@isdg.net> Date: Thu, 05 Jan 2012 19:23:37 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F060E74.2070103@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 00:24:19 -0000 Philip Gladstone wrote: > > On 1/4/2012 8:21 PM, Hector Santos wrote: >> Based on this, Macros are rarely used and I'm not surprised because >> historically only those trying to "track" usage were interested in them. > > In my list of SPF records, I have over 80 distinct records (after > eliminating the ip addresses, domain names etc) which use macros. A few > of these records are invalid. I don't know what volume of traffic is > sent with SPF records that use macros.... > > The macros are used in exists:, exp=, include:, a:, mx:, redirect= > > The actual macros were: %{d} %{h} %{ir} %{i} %{l1r+} %{l1r-} %{l} %{o} > %{r} %{s} -- i.e. nobody is using v, p, c, or t. > > The actual clauses were (for some value in ) > > a:%{ir}. > a:.%{d} > a:.%{o} > exists:%{ir}. > exists:%{ir}._ip.%{l}. > exists:%{ir}.mrbl.%{d} > exists:%{i}.%{l1r-}.user.%{d} > exists:%{i}.%{l}. > exists:%{i}.3/86400.rate.%{d} > exists:%{i}. > exists:%{i}._.%{h}._.%{s}. > exists:%{i}._.%{h}._.%{s}._.%{r}. > exists:%{l1r+}. > exists:%{l}.%{ir}. > exists:%{l}.%{i}. > exists:%{l}.%{o}.%{i}.%{h}. > exists:%{l}. > exists:%{l}.x.%{ir}. > exists:%{s}.%{i}. > exists:%{s}. > exists:%{s}.EmailAddr.%{i}. > exists:%{s}.S.%{i}. > exists:%{s}.sending-to.%{r}.from-ip-address-%{i}. > exists:%{s}_%{i}_ > exists:CL.%{i}.FR.%{s}. > exists:CL.%{i}.FR.%{s}.HE.%{h}. > exists:I.%{i}.F.%{l}.%{o}.H.%{h}. > exists:IP%{i}.H%{h}.D%{d}. > exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._s.%{s}._r.%{r}. > exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} > exists:h_%{h}-i_%{i}-%{s}. > exists:i%{i}.f%{s}. > exp=.%{d} > include:%{l}.%{o}. > include:.%{d} > mx:.%{d} > redirect=%{l}. > redirect=%{o}. > redirect=.%{d} > > Philip Of course, every site business/social personal network community will have different stats, so I don't to imply one case is ever the norm. As a former ESP site (i.e. free email accounts, etc) during the 90s (turned off in 98/99), we still get a very high hit rate of anonymous abuse, including all the blasting of CIS account hits and attempts to target our user base. This represented an immediate and huge DNS overhead when SPF was implemented and executed at the MAIL FROM. So it was pretty obvious we needed to delay it until the RCPT TO was validated. This alone provided a 60% DNS overhead savings. In addition, SPF results are cached and hard failures are remembered and not repeated (DNS lookup) again until a certain time. The point is for our product implementation (not just our own support site usage) used by customers, is by the time a SPF query is done, a large percentage of would be "abusers" would be already filtered and what remains has a lesser abusive quality of SPF records. This was a primary focus because we didn't want DNS overhead. My SPF experience and view is macros are highly isolated to those that have an interest in tracking and feedback which I recall was the primary focus and interest. I agree that macro limits should be conveyed and written into SPF-BIF. I just don't think it was a major issue as its seems to be implied here and certainly not something which warrants any major flash as a security concern. If it was, I would be the first to stop using SPF. But was never the case and I think veteran SPF implementations have learned that long ago. The only concern I always had was the wasteful policies that contributed to DNS query waste that only resulted in indeterminate (No Decision) results, like NEUTRAL and also SOFTFAIL unless it was coupled with secondary criteria to make a decision for which AFAIK, there is no standard SOFTFAIL+OTHER heuristic used. Of the 80 you indicated in your sample, what percentage of those were abusive? More importantly, which ones are exerting a high processing overhead because certainly not all possible macro expansions are abusive and the waste case is a recursive overhead. That is the key limit (recursion) all SPF implementation MUST have and if SPF/SPF-BIS does not convey this, then is something that needs to be done. Without a doubt. My view is a legitimate domain with a large email network of providers that requires a complex set of macros probably needs a thorough review if its network and that includes a suggestion that perhaps SPF is probably not for them, especially if the SPF result is always an wasteful indeterminate result when none of its macro rules are satisfy. Its a major burden on SPF receivers to process SPF rules that end up with no results. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dotis@mail-abuse.org Thu Jan 5 21:36:17 2012 Return-Path: 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 356C81F0C5F for ; Thu, 5 Jan 2012 21:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.718 X-Spam-Level: X-Spam-Status: No, score=-101.718 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, GB_AFFORDABLE=1, USER_IN_WHITELIST=-100] 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 1X7IMtHfqc9y for ; Thu, 5 Jan 2012 21:36:16 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 96ED41F0C56 for ; Thu, 5 Jan 2012 21:36:16 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 28474174013D for ; Fri, 6 Jan 2012 05:36:16 +0000 (UTC) Message-ID: <4F06884D.2070509@mail-abuse.org> Date: Thu, 05 Jan 2012 21:36:13 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F063F09.3030900@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 05:36:17 -0000 On 1/5/12 4:23 PM, Hector Santos wrote: > Philip Gladstone wrote: > > On 1/4/2012 8:21 PM, Hector Santos wrote: > >> Based on this, Macros are rarely used and I'm not surprised > >> because historically only those trying to "track" usage were > >> interested in them. > > > > In my list of SPF records, I have over 80 distinct records (after > > eliminating the ip addresses, domain names etc) which use macros. A > > few of these records are invalid. I don't know what volume of > > traffic is sent with SPF records that use macros.... > > > > The macros are used in exists:, exp=, include:, a:, mx:, redirect= > > > > The actual macros were: %{d} %{h} %{ir} %{i} %{l1r+} %{l1r-} %{l} > > %{o} %{r} %{s} -- i.e. nobody is using v, p, c, or t. > > Of course, every site business/social personal network community will > have different stats, so I don't to imply one case is ever the norm. > As a former ESP site (i.e. free email accounts, etc) during the 90s > (turned off in 98/99), we still get a very high hit rate of anonymous > abuse, including all the blasting of CIS account hits and attempts to > target our user base. This represented an immediate and huge DNS > overhead when SPF was implemented and executed at the MAIL FROM. So > it was pretty obvious we needed to delay it until the RCPT TO was > validated. This alone provided a 60% DNS overhead savings. In > addition, SPF results are cached and hard failures are remembered and > not repeated (DNS lookup) again until a certain time. Hector, Excluding SPF processing for messages with invalid recipients offers spammers immediate feedback for which messages contain invalid recipients. The macro aspect of SPF is highly problematic. A spammer can encode the recipient into the return-path local-part along with an SPF record containing "exists:%{l}..%{o}" where their DNS logs will then indicate which recipients were accepted and processed. :^( > The point is for our product implementation (not just our own support > site usage) used by customers, is by the time a SPF query is done, a > large percentage of would be "abusers" would be already filtered and > what remains has a lesser abusive quality of SPF records. This was a > primary focus because we didn't want DNS overhead. > > My SPF experience and view is macros are highly isolated to those > that have an interest in tracking and feedback which I recall was the > primary focus and interest. > > I agree that macro limits should be conveyed and written into > SPF-BIF. I just don't think it was a major issue as its seems to be > implied here and certainly not something which warrants any major > flash as a security concern. If it was, I would be the first to stop > using SPF. But was never the case and I think veteran SPF > implementations have learned that long ago. Unfortunately, this misses the DDoS concern entirely! It is NOT in the malefactor's interest to attack recipients whose resources are exploited by their accepted messages. Thousands of other equally unwitting accomplices can saturate links to any victim's domain with DNS UDP traffic. The local-part macro might represent a random value that will never be cached for use by subsequent messages. This feature represents a real security concern since there is no affordable mitigation strategy to deal with this, where victims will have few clues of the attack source. > The only concern I always had was the wasteful policies that > contributed to DNS query waste that only resulted in indeterminate > (No Decision) results, like NEUTRAL and also SOFTFAIL unless it was > coupled with secondary criteria to make a decision for which AFAIK, > there is no standard SOFTFAIL+OTHER heuristic used. When there is a HARDFAIL most ESPs know better than to reject the message. The majority of email traffic is being emitted by compromised systems. Why would anyone offer this type of criminal activity FREE access to SPF macro script processing able hit any third-party DNS server with significantly increased gain. Other server to server services prevent abuse from reaching this level by directly authenticating the source in the most efficient method possible. Accepting a message, then processing dozens or hundreds of potentially non-cachable DNS transactions just to select which messages to place into a junk folder is irresponsible. While much of the residential address space has been mapped out and thereby excluded, IPv6 is about to open vast unmapped regions too large to even make prefix queries against. Security will soon depend upon everyone recognizing they are all part of the Internet ecosystem and that they must not ignore their own pollution, even when it does not appear to be affecting them directly. -Doug From hsantos@isdg.net Fri Jan 6 00:25:30 2012 Return-Path: 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 0D2E921F8887 for ; Fri, 6 Jan 2012 00:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, GB_AFFORDABLE=1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=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 2J3L5MOtP5CH for ; Fri, 6 Jan 2012 00:25:29 -0800 (PST) Received: from news.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C945F21F848F for ; Fri, 6 Jan 2012 00:25:24 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4132; t=1325838321; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=6O2fYzTEAmZ+KPGzcQ/26iuhuGw=; b=TQIQaqV3JJdgx5RXgvuH OgbtldAg3dBsePFEejJ3LYaf1XfpxWV0BOQwTJHol09YUx8q9VhNLBPuz2RafpjS 90BNb9Bc8jIl5FjSp8MhM5IvXmqaaHi0SSj8eoh3CtlvVwtCRjnpz43Uq1hLpIr4 yRJEONdF7jy9Ih/Vq/bUvqM= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 06 Jan 2012 03:25:21 -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 3335180227.28557.3340; Fri, 06 Jan 2012 03:25:21 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4132; t=1325838155; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=rXQxoSS pYw63KmofpjxYyhWCGjKO9Nkh2OXzEe8U5cI=; b=UXz9Az6w5wK2V0KW6ukXVnD gJqhEb1TH5zbRjpABJ104OK1ix7WXUH5xe0tc10ij8Kkg/lc51HHgCmdHBvVDLRI 6zf/7EgyQae11jG4dlKsUuPqUlQbTxDeMskp2FiNJcmU/nb/xc0TmcxQ1307/IrG N01lkKSvuEm7f5M7EJQM= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 06 Jan 2012 03:22:35 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3934144329.3564.2996; Fri, 06 Jan 2012 03:22:33 -0500 Message-ID: <4F06AFD3.2080206@isdg.net> Date: Fri, 06 Jan 2012 03:24:51 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F06884D.2070509@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 08:25:30 -0000 Douglas Otis wrote: >> This represented an immediate and huge DNS >> overhead when SPF was implemented and executed at the MAIL FROM. So >> it was pretty obvious we needed to delay it until the RCPT TO was >> validated. This alone provided a 60% DNS overhead savings. In >> addition, SPF results are cached and hard failures are remembered and >> not repeated (DNS lookup) again until a certain time. > > Hector, > > Excluding SPF processing for messages with invalid recipients offers > spammers immediate feedback for which messages contain invalid > recipients. Its a red-herring to suggest they will actually learn to STOP trying and thats the fallacy in your consideration the negative feedback means anything to them. Dynamic RCPT TO validation and returning a 550 is going to happen regardless of SPF or anything. The goal is to give immediate feedback and if this going to happen 50-60% of the time pretty persistently, every day, there will be a tremendous amount of overhead in payload downloads and SPF or any other DNS lookup technologies. Coupled when a large percentage of the domains are bogus or NXDOMAIN, there is a serious amount of DNS related SMTP session slow downs. This is not conjecture. I have 9 years of statistic showing all this. http://www.winserver.com/public/spamstats.wct The history shows the overhead before and after December 2003 when the delayed validation was implemented with immediate DNS overhead reduction and SMTP time improvement. > The macro aspect of SPF is highly problematic. You have no real proof of this Doug and if there is, you need to be very specific on what kind of macros are used and how it is problematic. I already stated SPF system SHOULD have recursive and DNS lookup limits for SPF. Even for MX lookups for SMTP clients, there are limits, so its not just SPF related. > A spammer > can encode the recipient into the return-path local-part along with an > SPF record containing "exists:%{l}..%{o}" where their DNS logs > will then indicate which recipients were accepted and processed. :^( Even if this is a systemic record used by spammers, which is not by far, if they can't get pass RCPT TO, there is no SPF query. > Unfortunately, this misses the DDoS concern entirely! It is NOT in the > malefactor's interest to attack recipients whose resources are exploited > by their accepted messages. Thousands of other equally unwitting > accomplices can saturate links to any victim's domain with DNS UDP > traffic. The local-part macro might represent a random value that will > never be cached for use by subsequent messages. This feature represents > a real security concern since there is no affordable mitigation strategy > to deal with this, where victims will have few clues of the attack source. I don't see and have never heard of any problem when there are LIMITS Doug. > When there is a HARDFAIL most ESPs know better than to reject the > message. Then they are going against the SPF specification. > The majority of email traffic is being emitted by compromised > systems. Why would anyone offer this type of criminal activity FREE > access to SPF macro script processing able hit any third-party DNS > server with significantly increased gain. You are making it sound like this is wide spread. It is not and any DoS potential is already managed. I fail to see where you are going with all this. Are you trying to abolish SPF like you always tried with all your predictions which simply never materialized? > While much of the residential address space has been mapped out and > thereby excluded, IPv6 is about to open vast unmapped regions too large > to even make prefix queries against. Security will soon depend upon > everyone recognizing they are all part of the Internet ecosystem and > that they must not ignore their own pollution, even when it does not > appear to be affecting them directly. And your point regarding SPF and how this applies to SPF-BIF? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dotis@mail-abuse.org Fri Jan 6 19:24:45 2012 Return-Path: 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 00DF911E807F for ; Fri, 6 Jan 2012 19:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.478 X-Spam-Level: X-Spam-Status: No, score=-100.478 tagged_above=-999 required=5 tests=[AWL=-1.338, BAYES_20=-0.74, GB_AFFORDABLE=1, SARE_BAYES_5x7=0.6, USER_IN_WHITELIST=-100] 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 mLA0ZVA5kk3X for ; Fri, 6 Jan 2012 19:24:43 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id E938B11E807A for ; Fri, 6 Jan 2012 19:24:43 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway2.sdi.trendnet.org [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 4A97A17402EA for ; Sat, 7 Jan 2012 03:24:42 +0000 (UTC) Message-ID: <4F07BAF8.7020503@mail-abuse.org> Date: Fri, 06 Jan 2012 19:24:40 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> <4F06AFD3.2080206@isdg.net> In-Reply-To: <4F06AFD3.2080206@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 03:24:45 -0000 On 1/6/12 12:24 AM, Hector Santos wrote: > Douglas Otis wrote: > > Hector, > > > > Excluding SPF processing for messages with invalid recipients > > offers spammers immediate feedback for which messages contain > > invalid recipients. > Its a red-herring to suggest they will actually learn to STOP trying > and thats the fallacy in your consideration the negative feedback > means anything to them. > > Dynamic RCPT TO validation and returning a 550 is going to happen > regardless of SPF or anything. The goal is to give immediate > feedback and if this going to happen 50-60% of the time pretty > persistently, every day, there will be a tremendous amount of > overhead in payload downloads and SPF or any other DNS lookup > technologies. Coupled when a large percentage of the domains are > bogus or NXDOMAIN, there is a serious amount of DNS related SMTP > session slow downs. This is not conjecture. I have 9 years of > statistic showing all this. > > http://www.winserver.com/public/spamstats.wct > > The history shows the overhead before and after December 2003 when > the delayed validation was implemented with immediate DNS overhead > reduction and SMTP time improvement. Dear Hector, You are asking the right questions. Many domains delay refusal until after the data phase to obscure their reason and endure the increased SMTP latency. Offering immediate valid recipient feedback means recipient checks will be less effective at restricting malefactor access to user inboxes, to SPF processing engines, or to Call-Back checks. Initiating Call-Back checks to test the viability of the return-path increases SMTP latency at the expense of consuming another domain's resources. IMHO, lack of a practical outbound MTA authentication methodology has led to what might be considered inconsiderate behaviors. > > The macro aspect of SPF is highly problematic. > You have no real proof of this Doug and if there is, you need to be > very specific on what kind of macros are used and how it is > problematic. I already stated SPF system SHOULD have recursive and > DNS lookup limits for SPF. Even for MX lookups for SMTP clients, > there are limits, so its not just SPF related. Indeed most SPF libraries impose limits on DNS transactions permitted per message. The current specification permits up to 100 randomized transactions targeting any unrelated victim not evident within the message and still provide a PASS result. With today's level of abuse exceeding 90%, there is a real need to vet message sources. Unfortunately, SPF expects recipients to determine whether a return-path domain has authorized the last MTA of an indeterminate sequence of MTAs. Such a process always produces indeterminate results, as is now the case. That is not to say SPF provides no value. SPF in its simplest form offers a method to determine which reputation service lists the authorized outbound MTAs or to place them into a white-list. This function works best for SPF records lacking seldom used macro expansions, the exists mechanism, or modify default host domains. Any of which is seldom done. > > A spammer can encode the recipient into the return-path local-part > > along with an SPF record containing "exists:%{l}..%{o}" > > where their DNS logs will then indicate which recipients were > > accepted and processed. :^( > > Even if this is a systemic record used by spammers, which is not by > far, if they can't get pass RCPT TO, there is no SPF query. Giving malefactors RCPT TO validity feedback permits quick evasion of this check. > > Unfortunately, this misses the DDoS concern entirely! It is NOT in > > the malefactor's interest to attack recipients whose resources are > > exploited by their accepted messages. Thousands of other equally > > unwitting accomplices can saturate links to any victim's domain > > with DNS UDP traffic. The local-part macro might represent a > > random value that will never be cached for use by subsequent > > messages. This feature represents a real security concern since > > there is no affordable mitigation strategy to deal with this, where > > victims will have few clues of the attack source. > > I don't see and have never heard of any problem when there are LIMITS > Doug. It would be unreasonable to expect ESPs with their large bandwidths to notice anything. What other server authentication processes grant unknown malefactors similar levels of access and control over these powerful recipient resources? Lengthy SPF based transactions are carried out by any number of recipient domains happily unaware whether records referenced by local-parts of return-paths emit transactions targeting innocent uninvolved services that nevertheless may be vital and have nothing to do with email. What would you expect victims to see? What will victims do after their links are saturated with UDP traffic from thousands of sources. Have everyone cease use of email? Have everyone cease use of DNS? > > When there is a HARDFAIL most ESPs know better than to reject the > > message. > > Then they are going against the SPF specification. The specification says software can mark or reject a message. There are no requirements to reject. The strongest language is a should consider rejecting e-mail from invalid domains. The specification also makes a remarkable and inaccurate statement in the introduction: "An additional benefit to mail receivers is that after the use of an identity is verified, local policy decisions about the mail can be made based on the sender's domain, rather than the host's IP address. This is advantageous because reputation of domain names is likely to be more accurate than reputation of host IP addresses." With today's level of abuse, most now outsource email services. As such, outbound MTAs are commonly shared with thousands of domains. While a domain may authorize outbound servers, it would be unfounded conjecture whether the authorizing domain intended any specific message be sent to any specific recipient. However, the IP addresses of outbound MTAs are weakly authenticated by the TCP transport. Unless the EHLO has been validated against the domain of the return-path, mere authorization is never stronger than IP address authentication. The outbound MTA is obligated to exclude abusive sources since recipients can only guess who was the responsible domain. > > The majority of email traffic is being emitted by compromised > > systems. Why would anyone offer this type of criminal activity > > FREE access to SPF macro script processing able hit any third-party > > DNS server with significantly increased gain. > > You are making it sound like this is wide spread. It is not and any > DoS potential is already managed. I fail to see where you are going > with all this. Are you trying to abolish SPF like you always tried > with all your predictions which simply never materialized? Are you saying DDoS has been solved or that your are certain these attacks are not related to SPF? Realistic consideration of SPF benefits should significantly limit its automatic use. Mail-From authorization is unsuitable for abating spam since it offers no incontrovertible evidence of abuse. It is also unsuitable for abating spoofing, since it is normally not seen. SPF is also unable to deal with IPv6 related changes as source addresses become even more indeterminate. > > While much of the residential address space has been mapped out and > > thereby excluded, IPv6 is about to open vast unmapped regions too > > large to even make prefix queries against. Security will soon > > depend upon everyone recognizing they are all part of the Internet > > ecosystem and that they must not ignore their own pollution, even > > when it does not appear to be affecting them directly. > > And your point regarding SPF and how this applies to SPF-BIF? Looking at your web status page, it is clear much of your vetting process depends upon using the resources of others. Others that just might be DDoS targets as well. SPF would benefit from the simplification of the SPF definition by removing much of its seldom used flexibility. The recommendation was to deprecate the exists and local-part macros and to remove terminal strings from any mechanism. The few domains making use of these features will be prompted by minor problems that they need to simplify their records. The list of legitimate domains sending email responsibly is comparatively small. Why not immediately accept messages from those that have authenticated the HELO domain of the transmitting server? That could be done within one DNS transaction. After which, reputation can be safely and effectively applied against authenticated domains that are in full control of the assessed transactions. ATSP can then prevent unauthorized transmissions using an additional DNS transaction. These changes should ensure responsible and responsive ESPs will have a prosperous future and better mitigate the current levels of abuse. All of this keeps you in the driver's seat. We are on the same side after all. Regards, Doug Otis From hsantos@isdg.net Fri Jan 6 22:33:04 2012 Return-Path: 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 91BDC11E8074 for ; Fri, 6 Jan 2012 22:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.644 X-Spam-Level: X-Spam-Status: No, score=-0.644 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_50=0.001] 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 r2N2JFaDBErk for ; Fri, 6 Jan 2012 22:33:03 -0800 (PST) Received: from mail.catinthebox.net (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6373011E8072 for ; Fri, 6 Jan 2012 22:33:02 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2047; t=1325917655; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=iQ0IAnfAw4SQPRMMr1D4aChx/ZA=; b=Nrtiyc0URgp8HtVSEmSk i0aOoaGjPZGuHxsNNalAopixyvudm1/J0miqypx1WkbG39PGjECD3cgeVSDpvnCf 3n54ObPnU5oaGvaWXKAICcpCkyj2/kfwLLhfKUmDSKUexnmefE+YTlpDaXO7ZY8+ TOzAxZwqMqDR1O3eqNdB1JM= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 07 Jan 2012 01:27:35 -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 3414512289.28557.2548; Sat, 07 Jan 2012 01:27:34 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2047; t=1325917487; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=GMQGINv 7DiYZAh4hcmjJsQGbKaOMmwU9uFfGVQZFiD8=; b=QSoICQ6719aNs8NeLINAC9D 5VgxzvSsnu7v6nhYv8iKLmI7C6x0BFZ/fN6Iy6/agYQjJsOBOexlXIdyjQRl62K9 bCpex4gJ9MEkJIxYwVqpIZsE+T8ayfgqRccz6IIMNY8jRq0j0jIlGUHFCuwpUkd9 ISihiqPNoaD5LwnSytEM= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sat, 07 Jan 2012 01:24:47 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4013476360.3646.6444; Sat, 07 Jan 2012 01:24:45 -0500 Message-ID: <4F07E5B9.70103@isdg.net> Date: Sat, 07 Jan 2012 01:27:05 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> <4F06AFD3.2080206@isdg.net> <4F07BAF8.7020503@mail-abuse.org> In-Reply-To: <4F07BAF8.7020503@mail-abuse.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] HardFail Marking vs HardFail Rejects X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 06:33:04 -0000 Douglas Otis wrote: >> > When there is a HARDFAIL most ESPs know better than to reject the >> > message. >> >> Then they are going against the SPF specification. > > The specification says software can mark or reject a message. There are > no requirements to reject. The strongest language is a should consider > rejecting e-mail from invalid domains. Perhaps, the term MARK needs to be defined in SPF-BIF. What is MARKING? My opinion on the topic: A HARDFAIL MARK still represents a condition of FAILURE. In other words, HARDFAIL MARK should still separate a transaction from the rest as a very suspicious transaction with a very high confidence and zero FALSE positive state. If a SPF receiver is not going to honor the outright SPF DOMAIN HARDFAIL policy result is a 100% unacceptable bad transaction with 100% confidence, then all liabilities will be transferred to the RECEIVER who is now intentionally ignorant of a 100% unacceptable condition. There is no claim here of plausible denial for a SPF compliant receiver. All liabilities passes to it when it ignores a Domain HardFail policy result. The ultimate outcome SHOULD be the same for either. SPF-BIF should make that very clear. When it comes to a HardFail result, a decision to mark and accept and still pass on the transaction to recipient(s), is highly dangerous and goes against the main purpose of what SPF is trying to achieve, especially with HardFail declarations. While moving it to a spam box is acceptable idea, but it must be understood a HARDFAIL MARK outcome is to match the a HARDFAIL REJECT outcome where the recipients are not subject to harm, the bottom line. To me, MARKING is great for the indeterminate results simply because no decision can be made and IMV the receiver SHOULD not be rejecting purely on these indeterminate results. Again, a HARDFAIL is very different in all this. Its Black and White, there is no grey here. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From vesely@tana.it Sat Jan 7 02:50:58 2012 Return-Path: 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 B200821F8543 for ; Sat, 7 Jan 2012 02:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.58 X-Spam-Level: X-Spam-Status: No, score=-4.58 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 8yBvq5s9nsgm for ; Sat, 7 Jan 2012 02:50:58 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id DDC5C21F84F4 for ; Sat, 7 Jan 2012 02:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325933455; bh=k9e5mJ/DyW96j8oKxZR3mRY2cI7hs23vId8civfRhEY=; l=1208; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=lkCPmjhXwWw7eQpxFla9aP/Z4N7nA8BRpg+Px4RimV+L293Ve2ube18yFtNpnSaDF lUBDCI/rb1sE5ZbOZHrMAkTF5lh7F4nvqcTwxzxd7/dvmnSu8gQJrt9s5rQMYhHZvG hP/cj2sSXGvFhrTV1/WzoZB5PZYehb4AryKzdmw0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 07 Jan 2012 11:50:55 +0100 id 00000000005DC039.000000004F08238F.00000483 Message-ID: <4F08238E.9010005@tana.it> Date: Sat, 07 Jan 2012 11:50:54 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> <4F061CB6.5030909@gathman.org> In-Reply-To: <4F061CB6.5030909@gathman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion for an additional deliverable X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 10:50:58 -0000 On 05/Jan/12 22:57, Stuart D Gathman wrote: > Long ago, Nostradamus foresaw that on 01/04/2012 06:36 PM, Douglas > Otis would write: >> >> Not exactly. Some will substitute "No SPF Record" with a synthetic >> "v=spf1 a mx/24 ?all". This could produce a difficult to diagnose >> loss of DSNs or sporadic junk folder message placements. > > Whatever problem you are worried about here, it is not an SPF > problem. I don't agree on this. If there were problems evaluating bestguess, then there would be problems in case that domain actually published such policy. > The spec is already clear that any result from such practices (and > I myself am such a practitioner) is *not* an SPF result and MUST > NOT be reported as such. Correct. > In the discussion of the Authentication-Results header field, we did > talk about needing a way to report such heuristic results (but not as > SPF results). An additional method is needed for that. We might speculate whether that would be a case of "addition of any enhancements that have already gained widespread support" or if rechartering is needed. The consensus seems to be not to schedule a deliverable for bestgess at this stage. From vesely@tana.it Sat Jan 7 03:11:31 2012 Return-Path: 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 2C5F921F8484 for ; Sat, 7 Jan 2012 03:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.589 X-Spam-Level: X-Spam-Status: No, score=-4.589 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 jrg1frFcvCd3 for ; Sat, 7 Jan 2012 03:11:30 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 59C2021F8483 for ; Sat, 7 Jan 2012 03:11:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325934689; bh=ygjuCjsGMrMgT7S2WsU2diMFq9R2G0dbXVBcLt+9Xf8=; l=1256; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=E7OboGxpTqMiTM3xdKA+NflBT4PFqfJKGlQW8KOJCgPHaX/Jd7GSXQc3xcknX/+2j 5vYAKK1ocCkg/1THd8sFnOiycdGs6a5tURGi0GkoP22cq8pLzXOBrqYPmFxsxYAJ7z YzeC9pzEssyzfbV29jlnFRa/aJ1paewrgB4yXGoU= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 07 Jan 2012 12:11:29 +0100 id 00000000005DC039.000000004F082861.00000918 Message-ID: <4F082861.5080803@tana.it> Date: Sat, 07 Jan 2012 12:11:29 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F06884D.2070509@mail-abuse.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 11:11:31 -0000 On 06/Jan/12 06:36, Douglas Otis wrote: > On 1/5/12 4:23 PM, Hector Santos wrote: >> Philip Gladstone wrote: >>> >>> The actual macros were: %{d} %{h} %{ir} %{i} %{l1r+} %{l1r-} %{l} >>> %{o} %{r} %{s} -- i.e. nobody is using v, p, c, or t. >> >> [I]t was pretty obvious we needed to delay it until the RCPT TO was >> validated. This alone provided a 60% DNS overhead savings. > > Excluding SPF processing for messages with invalid recipients offers > spammers immediate feedback for which messages contain invalid > recipients. The macro aspect of SPF is highly problematic. A spammer > can encode the recipient into the return-path local-part along with an > SPF record containing "exists:%{l}..%{o}" where their DNS logs > will then indicate which recipients were accepted and processed. :^( I agree this is a weakness of SPF. The current charter does not allow us to ban local macros, but that could be done for v=spf3. If there is agreement on that, spfbis could include some text more or less like so: Note: reporting mechanisms are being improved, and it is suggested that domain owners use those instead of DNS-tracking. Future versions of SPF may deprecate "exists" mechanisms that use local macros. jm2c From hsantos@isdg.net Sat Jan 7 21:16:43 2012 Return-Path: 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 6F8C321F84A5 for ; Sat, 7 Jan 2012 21:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] 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 8tn7Rq0QW4ow for ; Sat, 7 Jan 2012 21:16:42 -0800 (PST) Received: from listserv.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 58F6121F848B for ; Sat, 7 Jan 2012 21:16:40 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2455; t=1325999797; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=7uCjZg8lRgNqM60QHSBlF+T+qCs=; b=B0mCX67CGRyec7ABlcFy vmCUhzTUN5nrFBzvu6U9YsfrefMzGD+6nnklVDJy/R8YJoMll19rtJlCr0Y5/uCA 9Y9OfgGkHfjGA5hIW+MVDEEdizr+v/Hxg2u04ABKPnusZXAmnVBuW6H3mkqpff+c /w5CgW1DWEE88QxGfd7qiSA= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 08 Jan 2012 00:16:37 -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 3496653117.33109.888; Sun, 08 Jan 2012 00:16:35 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2455; t=1325999628; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JEHQ3IA tsbcZBdEDxD2KXL6ekyZ+DpnSYOcfMytXPOU=; b=jcBe60bHo/odsqV2d5tDpZP Jq3GagVZxM9mWJAH/hGmxyXg/NHlmmjWh8aqFP2BH8rkjjAhrhJFo3WakQZdeCJG vUSZZIYJtFT42Oq1gh144lzgMihwd+Vuia4WClgVxSMr9yP2LMJYg6zZEqoluRJe JOBV+LzKFWoOAWdWLUdU= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Sun, 08 Jan 2012 00:13:48 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4095618094.3806.5564; Sun, 08 Jan 2012 00:13:47 -0500 Message-ID: <4F09269C.6090402@isdg.net> Date: Sun, 08 Jan 2012 00:16:12 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F082861.5080803@tana.it> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 05:16:43 -0000 Alessandro Vesely wrote: > On 06/Jan/12 06:36, Douglas Otis wrote: >> Excluding SPF processing for messages with invalid recipients offers >> spammers immediate feedback for which messages contain invalid >> recipients. The macro aspect of SPF is highly problematic. A spammer >> can encode the recipient into the return-path local-part along with an >> SPF record containing "exists:%{l}..%{o}" where their DNS logs >> will then indicate which recipients were accepted and processed. :^( > > I agree this is a weakness of SPF. The current charter does not allow > us to ban local macros, but that could be done for v=spf3. If there > is agreement on that, spfbis could include some text more or less like so: > > Note: reporting mechanisms are being improved, and it is suggested > that domain owners use those instead of DNS-tracking. Future > versions of SPF may deprecate "exists" mechanisms that use > local macros. > The problem with this SPF macros discussion is its being generalized as bad as a whole. That is far from any truth. So if there is a problem with SPF macro expansions, there needs to be specific examples of how and where this problem begins and what it causes. Is the "exists" directive the only problem with? If so, why? How about the "include" and "redirect" directives? In my experience of the issues that had came up very early on, what the lack of limits. It was immediately apparent that SPF implementations needs to pay attention to recursive limits. For SPF-BIF, in the name of not having an revision change the core specification, I believe, the security topics need to expanded and begin to have semantics and guidelines that imply something like: SPF implementations MAY impose strict limits and policies SHOULD be very attentive to reduce complexity, directives, mechanisms and macros that will cause extensive DNS operations. SPF receivers MAY impose limits on the amount of recursive include, redirects or the number of exists directives. For our package,we added the limits and we never seen issues again. I thought other packages also implemented limits, but according to Doug, some SPF libraries do not. That may because its old, not supported, whatever. But for the supported packages, we learned this long ago and limits need to be stated in SPF-BIF. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From pgladstone@cisco.com Mon Jan 9 06:56:59 2012 Return-Path: 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 80BF321F87A8 for ; Mon, 9 Jan 2012 06:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] 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 WB5eugD79F1i for ; Mon, 9 Jan 2012 06:56:55 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1CE21F873E for ; Mon, 9 Jan 2012 06:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=8907; q=dns/txt; s=iport; t=1326121015; x=1327330615; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=FbDP4UFbrkRcEgFuHKGjkfP8+jqLbWEIcAK+ixvGTfQ=; b=RS3Z/iE4oB36Se1fbgpfbqL6vWcCVLGt/KEX2IFe3PAQ//Ae5gEkUAov q5ctSv0MT4iF+1qL9maH7j+G41PAKligdVmE0ut8j08oLiZN+zUST9lNv VkzmOAk99b0Ony71CilWHzgKXkBaUTLTZQJpOgKZQq2NC34q2KA34RQKa E=; X-Files: smime.p7s : 4899 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOD+Ck+rRDoJ/2dsb2JhbABBA4UPp0OBBYFyAQEBBBIBEFUPAgsYCRYLAgICBwMCAQIBCTwTBgIBAR6fTgGMYJFfBIhuBYIEgRYEiDmFcoEYhUaFUY0G X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; d="p7s'?scan'208";a="24467598" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 09 Jan 2012 14:56:55 +0000 Received: from [161.44.106.143] (dhcp-161-44-106-143.cisco.com [161.44.106.143]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q09Eur0g016683 for ; Mon, 9 Jan 2012 14:56:54 GMT Message-ID: <4F0B0035.3050106@cisco.com> Date: Mon, 09 Jan 2012 09:56:53 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F09269C.6090402@isdg.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060700090705030205000506" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 14:56:59 -0000 This is a cryptographically signed message in MIME format. --------------ms060700090705030205000506 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 1/8/2012 12:16 AM, Hector Santos wrote: > > Alessandro Vesely wrote: >> I agree this is a weakness of SPF. The current charter does not allow= >> us to ban local macros, but that could be done for v=3Dspf3. If there= >> is agreement on that, spfbis could include some text more or less=20 >> like so: >> >> Note: reporting mechanisms are being improved, and it is suggested >> that domain owners use those instead of DNS-tracking. Future= >> versions of SPF may deprecate "exists" mechanisms that use >> local macros. >> > > The problem with this SPF macros discussion is its being generalized=20 > as bad as a whole. That is far from any truth. > > So if there is a problem with SPF macro expansions, there needs to be=20 > specific examples of how and where this problem begins and what it=20 > causes. > Exactly. A powerful use of the local part macros is to be able to cause=20 email that is sent (by any MTA) from an invalid user to be rejected. There are still lots of forwarding services that don't do SRS or similar = and thus cause problems with SPF. I wanted to be able to permit these=20 uses, but only when the email is sent from known good usernames. In general, making a system more flexible is a good thing as it allows=20 people to use it in ways that the designers did not consider. I would=20 firmly resist any deprecation of macros *unless* equivalent=20 functionality was provided in another way. Philip --=20 Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ --------------ms060700090705030205000506 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2TCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUpMIIEEaAD AgECAhBluzNhw6CDObOmDguxgJDVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwNjAwMDAwMFoXDTEyMDkwNTIzNTk1 OVowJTEjMCEGCSqGSIb3DQEJARYUcGdsYWRzdG9uZUBjaXNjby5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC8ShP963c4uAJcGoHC2JCwJKJth79tIXQ2aVrtbK1tN5vi eX+0nKzylBxgLOfpyPuYxGuya1GNLXPXCnIp8sYpy6AlaQw2laBBODjl13Yjgnv/jlpVmE4d AwhRqWdcCH0WkrKniZiFEr72GUfhemnFNXILC5D82IiDOjqQ4guzO+ll/OoyYNBwx7ux4WAH hebTSrXcciAq/TqZnc8HlimFC6kS53kQdNd/MsYWNKVSj/60WxaHqFAjeRDopmZ4IDR2GvgX W7N4UIzXIcpJW8DC/KktfMxo/DXhi64RY3mLE0cxepA/D0T94uVwKXHneE9Q+GNhcNBIE4hT NrcsSlNbAgMBAAGjggHkMIIB4DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAd BgNVHQ4EFgQUEB9ztHyHGmanfNM9BLyVUI828nEwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB /wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQE AwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNv bW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2Eu Y29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYI KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRwZ2xhZHN0 b25lQGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAASu4Jrf2J6VFo8sJU04WDaW5P3wa jd5RSUWyhAgC/Doog4YlFvfQInnsMiEh069+czqynhigU8ahGOwzRCvZC044sPWU53wtz0Wp jzz9I/2ekKDceJr+Neu1tcIrH2eqrjwE0Mn+pbsUw1eUn7G7bq1B8gT6TAEx3mrrxXCr2mkQ VABiT1L1rkkcGpvV5ls040AU5Oe9bPPgtlWh7qjcaXBeOsYu5EAqRtbP+w7LeVfs0W0vXG1O h9O3X2FCHqZrQTh5gj3by4p0bssKCMKk/pELMzi5uHfB2OZhG4gLxTqwkVVXXcfCt2s/Womp 4TeiuQm/aozNUjlJQSfDYKaaETGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFD T01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhBluzNhw6CDObOmDguxgJDVMAkGBSsOAwIaBQCgggI4 MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEwOTE0NTY1 M1owIwYJKoZIhvcNAQkEMRYEFK1WRS1nyUqCmtpgRIeGCGXmgE8QMF8GCSqGSIb3DQEJDzFS MFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBluzNhw6CDObOmDguxgJDV MIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZbszYcOggzmzpg4LsYCQ1TANBgkqhkiG9w0BAQEFAASCAQAcQJjDjdb0 QCqiPTdb3d25xFhFwQQVTtcrimtfTLLa+Qk8Og7dAhK6rY8JF5m9EblxlMQsESP6seV74jJ7 UZzx951W/njg1Jbiat6rQX73Y+qIDPDczNtEZQ4Tt9QSBByXQyOtILA2O4YbIn+2xBxJDuMM xwrQxpAL7v3MHriySde8lQ23QvYZy0E7BJ/1yFC0SFZhlgqGu6UiKMHcuzgFbSRdqYUpjN7W XNU9rYsKOJK/In6aSIBlljnyJzN5bJACyn7IsMQWpqS8+LC9N45VmONkYJQhm0FTI4VCATps L4TuPi5eImdVeQU097xYE0/d6UTw/IIcN45V+VKC5ERDAAAAAAAA --------------ms060700090705030205000506-- From dotis@mail-abuse.org Tue Jan 10 11:54:32 2012 Return-Path: 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 C76F421F851C for ; Tue, 10 Jan 2012 11:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.096 X-Spam-Level: X-Spam-Status: No, score=-102.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 NGVB07C6oN3G for ; Tue, 10 Jan 2012 11:54:32 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3AF21F8593 for ; Tue, 10 Jan 2012 11:54:32 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 11B6917402C8 for ; Tue, 10 Jan 2012 19:54:32 +0000 (UTC) Message-ID: <4F0C9777.1090904@mail-abuse.org> Date: Tue, 10 Jan 2012 11:54:31 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F0B0035.3050106@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:54:32 -0000 On 1/9/12 6:56 AM, Philip Gladstone wrote: > > > On 1/8/2012 12:16 AM, Hector Santos wrote: >> >> Alessandro Vesely wrote: >>> I agree this is a weakness of SPF. The current charter does not allow >>> us to ban local macros, but that could be done for v=spf3. If there >>> is agreement on that, spfbis could include some text more or less >>> like so: >>> >>> Note: reporting mechanisms are being improved, and it is suggested >>> that domain owners use those instead of DNS-tracking. Future >>> versions of SPF may deprecate "exists" mechanisms that use >>> local macros. >>> >> >> The problem with this SPF macros discussion is its being generalized >> as bad as a whole. That is far from any truth. >> >> So if there is a problem with SPF macro expansions, there needs to be >> specific examples of how and where this problem begins and what it >> causes. >> > Exactly. A powerful use of the local part macros is to be able to > cause email that is sent (by any MTA) from an invalid user to be > rejected. > There are still lots of forwarding services that don't do SRS or > similar and thus cause problems with SPF. I wanted to be able to > permit these uses, but only when the email is sent from known good > usernames. Dear Philip, Use of local-part macros to vet valid email-addresses allows malefactors unlimited access to a mechanism that validates local-part guesses. In other words, spammers are being welcomed. Once any valid local-part has been determined and is intended to be used from any MTA, this will produce a PASS based simply on the presents of guessed local-parts. A poorly considered method for preventing abuse that makes PASS results completely meaningless. > In general, making a system more flexible is a good thing as it allows > people to use it in ways that the designers did not consider. I would > firmly resist any deprecation of macros *unless* equivalent > functionality was provided in another way. Use of SPF macros in unintended ways creates real risk. Authenticating outbound MTAs offers a scalable solution for generally determining whether a message might be trusted. S/MIME or OpenPGP offers a viable alternative for ensuring who originated a message. Use of SPF local-part macros is never safe for any purpose. Regards, Doug Otis From spf2@kitterman.com Tue Jan 10 12:01:51 2012 Return-Path: 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 359095E8002 for ; Tue, 10 Jan 2012 12:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 vQsztTYzcfRd for ; Tue, 10 Jan 2012 12:01:50 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6F16521F8826 for ; Tue, 10 Jan 2012 12:01:50 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3E60A20E410A; Tue, 10 Jan 2012 15:01:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1326225708; bh=/XerISgigR2rSFhM4EWZ++2IxSoRRgJ8H6prZV+yk3Y=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=hhfeEs+fqV8ZjQ3ykth43/shZ1F0uRaAdzRznn+2pheujWeBwJkrdikmPP1cRA4Tg xAxVCuszpIZwKGroAvBhl6nJ+3CowwJTsUkfKQEm6eadJ+fK7kRE657ek+/lEUEGi5 mDRn4F/k4lQecDz+XI/JQox8fk6zGgLb94RUWQhQ= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 10FBE20E409F; Tue, 10 Jan 2012 15:01:47 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 10 Jan 2012 15:01:45 -0500 Message-ID: <11850211.Go2gdSMgA1@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4F0C9777.1090904@mail-abuse.org> References: <4F0B0035.3050106@cisco.com> <4F0C9777.1090904@mail-abuse.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 20:01:51 -0000 On Tuesday, January 10, 2012 11:54:31 AM Douglas Otis wrote: > On 1/9/12 6:56 AM, Philip Gladstone wrote: > > On 1/8/2012 12:16 AM, Hector Santos wrote: > >> Alessandro Vesely wrote: > >>> I agree this is a weakness of SPF. The current charter does not > >>> allow > >>> us to ban local macros, but that could be done for v=spf3. If there > >>> is agreement on that, spfbis could include some text more or less > >>> > >>> like so: > >>> Note: reporting mechanisms are being improved, and it is > >>> suggested > >>> > >>> that domain owners use those instead of > >>> DNS-tracking. Future > >>> versions of SPF may deprecate "exists" mechanisms > >>> that use > >>> local macros. > >> > >> The problem with this SPF macros discussion is its being generalized > >> as bad as a whole. That is far from any truth. > >> > >> So if there is a problem with SPF macro expansions, there needs to be > >> specific examples of how and where this problem begins and what it > >> causes. > > > > Exactly. A powerful use of the local part macros is to be able to > > cause email that is sent (by any MTA) from an invalid user to be > > rejected. > > There are still lots of forwarding services that don't do SRS or > > similar and thus cause problems with SPF. I wanted to be able to > > permit these uses, but only when the email is sent from known good > > usernames. > > Dear Philip, > > Use of local-part macros to vet valid email-addresses allows malefactors > unlimited access to a mechanism that validates local-part guesses. In > other words, spammers are being welcomed. Once any valid local-part has > been determined and is intended to be used from any MTA, this will > produce a PASS based simply on the presents of guessed local-parts. A > poorly considered method for preventing abuse that makes PASS results > completely meaningless. > > > In general, making a system more flexible is a good thing as it allows > > people to use it in ways that the designers did not consider. I would > > firmly resist any deprecation of macros *unless* equivalent > > functionality was provided in another way. > > Use of SPF macros in unintended ways creates real risk. Authenticating > outbound MTAs offers a scalable solution for generally determining > whether a message might be trusted. S/MIME or OpenPGP offers a viable > alternative for ensuring who originated a message. Use of SPF > local-part macros is never safe for any purpose. This is all a bunch of hand waving. Do you have any evidence for real world occurences of these alleged problems? Scott K From pgladstone@cisco.com Tue Jan 10 12:24:06 2012 Return-Path: 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 208C121F8857 for ; Tue, 10 Jan 2012 12:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] 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 07G8O2MUhzqr for ; Tue, 10 Jan 2012 12:24:05 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E375B1F0C4E for ; Tue, 10 Jan 2012 12:24:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=9159; q=dns/txt; s=iport; t=1326227043; x=1327436643; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=MnTgqrbGSAIqSlOqGNSJZdXbUZ8Imf+51nH+TJ9VBc4=; b=eGeGI43flRZ759Ci2/MHSJpoXGerX7xMQfKT+mudpEoA4tWx9XH6tjZU PEcLD5tahyRRmblJCcoCTswHMEv+WijiNReWY3DKSVKN1mSlYgzFw/DCh FdFNDhyhjW/QKlISiW5EPoQRijEVAitLRrNMgLPTyq5ZVFgJE7HF2tjwF I=; X-Files: smime.p7s : 4899 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFqdDE+rRDoG/2dsb2JhbAA/A4UPp0uBBYFyAQEBBBIBEFUPAgsYCRYLAgICBwMCAQIBCTwTBgIBARcHoDABjGKRNgSIbgWCBoEWBIg6hXSBGIVGhVGNBw X-IronPort-AV: E=Sophos;i="4.71,489,1320624000"; d="p7s'?scan'208";a="24732228" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 10 Jan 2012 20:24:02 +0000 Received: from [161.44.106.244] (dhcp-161-44-106-244.cisco.com [161.44.106.244]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0AKO1sM023049 for ; Tue, 10 Jan 2012 20:24:02 GMT Message-ID: <4F0C9E61.1010306@cisco.com> Date: Tue, 10 Jan 2012 15:24:01 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F0C9777.1090904@mail-abuse.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060304050602000102030302" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 20:24:06 -0000 This is a cryptographically signed message in MIME format. --------------ms060304050602000102030302 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 1/10/2012 2:54 PM, Douglas Otis wrote: > Dear Philip, > > Use of local-part macros to vet valid email-addresses allows=20 > malefactors unlimited access to a mechanism that validates local-part=20 > guesses. In other words, spammers are being welcomed. Once any valid = > local-part has been determined and is intended to be used from any=20 > MTA, this will produce a PASS based simply on the presents of guessed=20 > local-parts. A poorly considered method for preventing abuse that=20 > makes PASS results completely meaningless. >> In general, making a system more flexible is a good thing as it=20 >> allows people to use it in ways that the designers did not consider.=20 >> I would firmly resist any deprecation of macros *unless* equivalent=20 >> functionality was provided in another way.=20 > Use of SPF macros in unintended ways creates real risk. Authenticating = > outbound MTAs offers a scalable solution for generally determining=20 > whether a message might be trusted. S/MIME or OpenPGP offers a=20 > viable alternative for ensuring who originated a message. Use of SPF=20 > local-part macros is never safe for any purpose. > Doug I understand that you wouldn't make use of this feature. However I am=20 free to design my SPF record in any way that I like that meets my needs. = By your reasoning, '+all' would not be allowed either as it makes SPF=20 meaningless as well. In my sample of SPF records, '-all' beats '~all' beats '+all' beats=20 'all' (in terms of counts) -- with +all being about 5% of -all (sample = not weighted in any particular way). If you have some concrete examples of the risk that the use of the SPF=20 local-part macro poses, then lets discuss them. Philip --=20 Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ --------------ms060304050602000102030302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2TCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUpMIIEEaAD AgECAhBluzNhw6CDObOmDguxgJDVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwNjAwMDAwMFoXDTEyMDkwNTIzNTk1 OVowJTEjMCEGCSqGSIb3DQEJARYUcGdsYWRzdG9uZUBjaXNjby5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC8ShP963c4uAJcGoHC2JCwJKJth79tIXQ2aVrtbK1tN5vi eX+0nKzylBxgLOfpyPuYxGuya1GNLXPXCnIp8sYpy6AlaQw2laBBODjl13Yjgnv/jlpVmE4d AwhRqWdcCH0WkrKniZiFEr72GUfhemnFNXILC5D82IiDOjqQ4guzO+ll/OoyYNBwx7ux4WAH hebTSrXcciAq/TqZnc8HlimFC6kS53kQdNd/MsYWNKVSj/60WxaHqFAjeRDopmZ4IDR2GvgX W7N4UIzXIcpJW8DC/KktfMxo/DXhi64RY3mLE0cxepA/D0T94uVwKXHneE9Q+GNhcNBIE4hT NrcsSlNbAgMBAAGjggHkMIIB4DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAd BgNVHQ4EFgQUEB9ztHyHGmanfNM9BLyVUI828nEwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB /wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQE AwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNv bW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2Eu Y29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYI KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRwZ2xhZHN0 b25lQGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAASu4Jrf2J6VFo8sJU04WDaW5P3wa jd5RSUWyhAgC/Doog4YlFvfQInnsMiEh069+czqynhigU8ahGOwzRCvZC044sPWU53wtz0Wp jzz9I/2ekKDceJr+Neu1tcIrH2eqrjwE0Mn+pbsUw1eUn7G7bq1B8gT6TAEx3mrrxXCr2mkQ VABiT1L1rkkcGpvV5ls040AU5Oe9bPPgtlWh7qjcaXBeOsYu5EAqRtbP+w7LeVfs0W0vXG1O h9O3X2FCHqZrQTh5gj3by4p0bssKCMKk/pELMzi5uHfB2OZhG4gLxTqwkVVXXcfCt2s/Womp 4TeiuQm/aozNUjlJQSfDYKaaETGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFD T01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhBluzNhw6CDObOmDguxgJDVMAkGBSsOAwIaBQCgggI4 MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDExMDIwMjQw MVowIwYJKoZIhvcNAQkEMRYEFD5BLokTtX8ZGB6QSQc9Da5/cmUrMF8GCSqGSIb3DQEJDzFS MFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBluzNhw6CDObOmDguxgJDV MIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZbszYcOggzmzpg4LsYCQ1TANBgkqhkiG9w0BAQEFAASCAQB1NW4T4zg/ s89C7Ar3BPsSQhoAT4YumTwMOJmkyz3mGyIkVVrAKjC4nGXjuohDiKnpkTsTkgfmcAxQ2lOO Do20I/7MfYd5swfIaVkNXxls0Upb/0HNVseCISXgEjssL9OX8HQeTWj0oiGYxNrN8xEVh6jz QRKEKQpHPbg5oMSpoxl1AL+smJ3V5sGk59jIKSWHzir9Djs2VeLX+IqNrUlvhUxIvSrDcWTv fgEpAN85cduRRdbA5c8OwcEE0Vb1ToFlih/jTFCPcOU8K7xgP+lLsB1ZhwLst0S4xvTVqquM 8RfYmg9QnlTnDr0yD3GObc3KbNzf0+IMx63GU+yuGQ6KAAAAAAAA --------------ms060304050602000102030302-- From vesely@tana.it Wed Jan 11 10:09:41 2012 Return-Path: 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 D9C8321F87F1 for ; Wed, 11 Jan 2012 10:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.502 X-Spam-Level: X-Spam-Status: No, score=-4.502 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] 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 tZEW-OzTzGYA for ; Wed, 11 Jan 2012 10:09:40 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A76DB21F87B8 for ; Wed, 11 Jan 2012 10:09:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326305379; bh=yk5+dPesBmUGijBxkUjzqeNDQQvqNFfnzfvg5NisTqI=; l=581; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=BLWqNGNsltepOEmlS4K0GOus7Wy0jZxKtoRyHfOyIY2HJEYCehINNnHFPzCtwNOCn FtkJMdJqIQcACA+83bPGZ2bJiGKDPz7DuV4Sf+1ns+pgmKodB/0aBgsCSu/FnDCzCA oiONjDLJcDAetyKWQGDCMjl5P3L0l6AEPxfGeBmg= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 11 Jan 2012 19:09:39 +0100 id 00000000005DC03F.000000004F0DD063.000001D3 Message-ID: <4F0DD063.5090103@tana.it> Date: Wed, 11 Jan 2012 19:09:39 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F0C9E61.1010306@cisco.com> Content-Type: text/plain; charset=us-ascii 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:09:42 -0000 On 10/Jan/12 21:24, Philip Gladstone wrote: > > If you have some concrete examples of the risk that the use of the SPF > local-part macro poses, then lets discuss them. Please, let's not. Such kinds of discussion won't bring us much. It is a fact that there is people who consider SPF more complicate than it needs to be for mail sites that use MSAs correctly. We may want to estimate whether the user base --both publishers and checkers-- would increase sensibly if we offered a simplified version. We don't need to enumerate the possible risks once more. jm2c From hsantos@isdg.net Wed Jan 11 14:17:57 2012 Return-Path: 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 8E8C311E808C for ; Wed, 11 Jan 2012 14:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, SARE_WEOFFER=0.3] 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 bZ+FlLPv0JNg for ; Wed, 11 Jan 2012 14:17:56 -0800 (PST) Received: from mail.catinthebox.net (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 71D3F11E8074 for ; Wed, 11 Jan 2012 14:17:55 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2266; t=1326320268; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=S8Wz1eQ165YbnwPU7vR0Ch958yw=; b=jlij4uh1VwlL5oBoRK0R KbdGWNJQ1FJZs1KqRTxuQ9+4dVfXkAW5WzwJij5FEpkgbKnBa0+zXP6MQI3f2UIr YTRIW9fhgK2nINXB4KtLh64HlEamBOIZUoQ+kTeuP/KbN4ATfrxncizRE8tv1J1t r6wlrwZGKj/4du20RTuHkW0= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Jan 2012 17:17:48 -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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3817121572.33109.3120; Wed, 11 Jan 2012 17:17:47 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2266; t=1326320093; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=cCycnjv ozV4h9j2XdpOybmYzyAYuJiNrr3p/VqsYiew=; b=TLLWIgeLK33PIMz5PDKl+VD 6EjbXrnEzKDhVtI3fH9hBQdGGLiE1x/gNtAv6zKg+vT6829qKKts+fKL4cb/jnp5 SiTB7xvr/PnaqoDP7Cv7zp1cu4J7b3b8KDNUjr8ZtL+3UTsMnX/vMIv0SZklwh8a XsSpVudh1wyITBQ9Ue7w= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Jan 2012 17:14:53 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 121116533.4466.6520; Wed, 11 Jan 2012 17:14:53 -0500 Message-ID: <4F0E0A7E.1040905@isdg.net> Date: Wed, 11 Jan 2012 17:17:34 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: <4F0DD063.5090103@tana.it> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 22:17:57 -0000 Alessandro Vesely wrote: > On 10/Jan/12 21:24, Philip Gladstone wrote: >> If you have some concrete examples of the risk that the use of the SPF >> local-part macro poses, then lets discuss them. > > Please, let's not. Such kinds of discussion won't bring us much. > > It is a fact that there is people who consider SPF more complicate > than it needs to be for mail sites that use MSAs correctly. We may > want to estimate whether the user base --both publishers and > checkers-- would increase sensibly if we offered a simplified version. > > We don't need to enumerate the possible risks once more. For our package, an MSA is an authorized, authenticated session and thus SPF and other stuff are skipped. It is for unknown transactions like done at a MDA where it is operationally not required to do an authorization to receive a local recipient message where SPF by supportive receivers apply it. Not saying the MSA can't apply SPF, but I don't see where it can help against the compromised MSA user client because the user is not one to be using an SPF record. I believe if there is a specific, known, loophole that is not currently covered by SPF implementations in the field, nor specified, mentioned, written in RFC4408, then it should be discussed and covered by SPF-BIF. Section 10.1 Processing Limits, covers the security idea of limits. But it only mentions one hard limit of 10 for MX and PTR. It recommends a unspecified minimum for others like INCLUDE which is more of a concern because of its recursive nature. We have a limit of 20 here. Probably more than enough to allow a domain to general an include recursion level of 20! Each of these directive whether with macros or not, needs to have limits. So in my view, it will probably be a good idea to avoid the "guessing game" and begin to add semantics about specific recommended limits. Doug is suggesting of changing the 10 for MX/PTR to maybe 5. Where did 10 come from to begin with? I presume is what was some SMTP client were already doing when sending out mail - they have a MX expansion limit of 10. Maybe the 10 come from the author's experience with this. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Wed Jan 11 14:34:43 2012 Return-Path: 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 3939021F875C for ; Wed, 11 Jan 2012 14:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 vjwJ6OOXJX4W for ; Wed, 11 Jan 2012 14:34:42 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0C24F21F875D for ; Wed, 11 Jan 2012 14:34:39 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 760C420E410A; Wed, 11 Jan 2012 17:34:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1326321276; bh=bOGnPIO+QaEG06qI0U6iVgaVHR36EXGAmNEe4d7NdWY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=dVIatGpV3E0239Ds5NBUtE4pWs9vtzW1y/TJApuwjHNxnnd/YPWouviK0Np14feXb tFXhL/r43/delZWuJgkYzddGaLGfYWNJeIVJwyZbZ1mWYXMX2Uj2JOY92MvUnY8PR/ NPcQOrmBoqCe2bNqeoP/GXiKZkckdCxzAi3MJwp8= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 494FA20E4081; Wed, 11 Jan 2012 17:34:36 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 11 Jan 2012 17:34:29 -0500 Message-ID: <4712177.Vc8ConvLxM@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4F0E0A7E.1040905@isdg.net> References: <4F0DD063.5090103@tana.it> <4F0E0A7E.1040905@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 22:34:43 -0000 On Wednesday, January 11, 2012 05:17:34 PM Hector Santos wrote: > Section 10.1 Processing Limits, covers the security idea of limits. > But it only mentions one hard limit of 10 for MX and PTR. It > recommends a unspecified minimum for others like INCLUDE which is more > of a concern because of its recursive nature. We have a limit of 20 > here. Probably more than enough to allow a domain to general an > include recursion level of 20! Each of these directive whether with > macros or not, needs to have limits. This is not correct. What is says is: SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier. The alleged hole does not exist. Scott K From derek.diget+spfbis@wmich.edu Wed Jan 11 14:39:15 2012 Return-Path: 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 03EF411E8099 for ; Wed, 11 Jan 2012 14:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 teTrING91Tiz for ; Wed, 11 Jan 2012 14:39:14 -0800 (PST) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFBA11E808C for ; Wed, 11 Jan 2012 14:39:14 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0LXN001DOO92WMG0@mta01.service.private> for spfbis@ietf.org; Wed, 11 Jan 2012 17:39:11 -0500 (EST) X-WMU-Spam: Gauge=X, Probability=10% on Wed Jan 11 17:39:11 2012, Report=' WMU_MSA_SMTP+ 0, TO_IN_SUBJECT 0.5, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_NOT_1 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NS ' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.11.215414 - Wed Jan 11 17:39:10 2012 Date: Wed, 11 Jan 2012 17:39:02 -0500 (EST) From: Derek Diget X-X-Sender: diget@spaz.oit.wmich.edu To: spfbis@ietf.org In-reply-to: <4F0E0A7E.1040905@isdg.net> Message-id: References: <4EF8F336.8080508@gathman.org> <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> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 22:39:15 -0000 On Jan 11, 2012 at 17:17 -0500, Hector Santos wrote: =>Section 10.1 Processing Limits, covers the security idea of limits. But it =>only mentions one hard limit of 10 for MX and PTR. It recommends a unspecified =>minimum for others like INCLUDE which is more of a concern because of its =>recursive nature. We have a limit of 20 here. Probably more than enough to =>allow a domain to general an include recursion level of 20! Each of these =>directive whether with macros or not, needs to have limits. => =>So in my view, it will probably be a good idea to avoid the "guessing game" =>and begin to add semantics about specific recommended limits. => =>Doug is suggesting of changing the 10 for MX/PTR to maybe 5. Where did 10 =>come from to begin with? I presume is what was some SMTP client were already =>doing when sending out mail - they have a MX expansion limit of 10. Maybe the =>10 come from the author's experience with this. I have been reading this thread and wanting to chime in... I have always read the first sentence of the 3rd paragraph of RFC 4408 section 10.1 (starts with "SPF implementations MUST limit") to mean that an SPF record that requires more that 10 DNS lookups to be a PermError and the SPF library should not do a 11th lookup. Period/end-stop. The MX limit that is mentioned in later paragraphs is still constrained by the first sentence's (10 lookup) limit. I would almost say that the 4th paragraph ('When evaluating the "mx"') is redundant to the 3rd paragraph except for the mention of the %{p} macro. (I can't speak for code writers of the MTA we use, but I think that is the behavior I have seen. 11 DNS lookup causes a PermError to be returned by check_host() ). -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** From msk@cloudmark.com Wed Jan 11 14:41:05 2012 Return-Path: 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 C852C11E80AB for ; Wed, 11 Jan 2012 14:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 dq8GUj6XAyMG for ; Wed, 11 Jan 2012 14:41:05 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 00DB111E8074 for ; Wed, 11 Jan 2012 14:41:05 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 11 Jan 2012 14:40:57 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 11 Jan 2012 14:41:04 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Wed, 11 Jan 2012 14:41:02 -0800 Thread-Topic: [spfbis] Local macros strike again, was Suggestion... Thread-Index: AczQsdqcj6xKEVdvRly5x8mHvCxfxAAACEmw Message-ID: References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 22:41:05 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Derek Diget > Sent: Wednesday, January 11, 2012 2:39 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Local macros strike again, was Suggestion... >=20 > I have always read the first sentence of the 3rd paragraph of RFC 4408 > section 10.1 (starts with "SPF implementations MUST limit") to mean > that an SPF record that requires more that 10 DNS lookups to be a > PermError and the SPF library should not do a 11th lookup. Period/end- > stop. >=20 > The MX limit that is mentioned in later paragraphs is still constrained > by the first sentence's (10 lookup) limit. I would almost say that the > 4th paragraph ('When evaluating the "mx"') is redundant to the 3rd > paragraph except for the mention of the %{p} macro. If people feel this is not clear enough in 4408, the bis effort would certa= inly be in a position to clarify. From hsantos@isdg.net Wed Jan 11 14:47:37 2012 Return-Path: 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 943ED21F8759 for ; Wed, 11 Jan 2012 14:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, 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 iTr9k8qKzeZ9 for ; Wed, 11 Jan 2012 14:47:37 -0800 (PST) Received: from mail.catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CB10921F8755 for ; Wed, 11 Jan 2012 14:47:36 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=993; t=1326322053; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=SOLvEHy1BZtgvFV3IpYIfqJDEno=; b=cNn768ayePVoc/65kP/U Dp7dcVKdHWdvzWf4zAySJk1tt2WOMFQVfXuS1Y+2EF4yBG8fOhftJZyEb12FzY84 RKlmKlXXkhI8/HhkL+nzUuSYDWeTjI7ovBc2/EevIKAkuu1RVCL0ae0ksQbIljPX xZ6iBEcNZjJmTlTXyF4cwhQ= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Jan 2012 17:47:33 -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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3818906692.33109.680; Wed, 11 Jan 2012 17:47:33 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=993; t=1326321878; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=qHbIRN5 KKdrtXe3opSnjZF7rJw2d8ADeMBWkL410Bac=; b=owhCOqOsUTRvLnK2ERkc8m+ P8Ndgt7lbZPKL4az5W39uprTBQBHgjLhgINSkUCGLD8JH8bMOpoTx5lPiIZL7plk yipKkzZ987dMkcwz6GXm+o99GVbwPkBM82sQkozM584tckjduXmuZ5c8B0wU1Os6 5fuGgNApyGICr0iuZHw0= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Jan 2012 17:44:38 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 122900470.4468.4660; Wed, 11 Jan 2012 17:44:37 -0500 Message-ID: <4F0E1177.6000502@isdg.net> Date: Wed, 11 Jan 2012 17:47:19 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <4F0DD063.5090103@tana.it> <4F0E0A7E.1040905@isdg.net> <4712177.Vc8ConvLxM@scott-latitude-e6320> In-Reply-To: <4712177.Vc8ConvLxM@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 22:47:37 -0000 Scott Kitterman wrote: > On Wednesday, January 11, 2012 05:17:34 PM Hector Santos wrote: >> Section 10.1 Processing Limits, covers the security idea of limits. >> But it only mentions one hard limit of 10 for MX and PTR. It >> recommends a unspecified minimum for others like INCLUDE which is more >> of a concern because of its recursive nature. We have a limit of 20 >> here. Probably more than enough to allow a domain to general an >> include recursion level of 20! Each of these directive whether with >> macros or not, needs to have limits. > > This is not correct. What is says is: > > SPF implementations MUST limit the number of mechanisms and modifiers > that do DNS lookups to at most 10 per SPF check, including any > lookups caused by the use of the "include" mechanism or the > "redirect" modifier. > > The alleged hole does not exist. You're right, missed that statement. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Wed Jan 11 19:02:44 2012 Return-Path: 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 0165611E80BD for ; Wed, 11 Jan 2012 19:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.482, 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 iINyqpHnDnpr for ; Wed, 11 Jan 2012 19:02:42 -0800 (PST) Received: from listserv.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 33F4011E80BA for ; Wed, 11 Jan 2012 19:02:41 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=9088; t=1326337354; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=2A5CINN3S/gSo8vfUww7h6S1ymM=; b=i3vTSg2w9S8WIC5UhRnx BElGZXr6CGueFTdCQXRbY8Le+RKWOxmJHWUuIIlSwnINKqm8VrB29FX4h2S7MEuv Rj6XPFpru6Jk8Kxu80GRM5dkorh+kTVKhy1jB72DqtWMYtJ0gBrPKPMOjrk/UP/c vswNOmstJ+b3NmFWDlGk5g8= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Jan 2012 22:02:34 -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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3834207426.36383.2172; Wed, 11 Jan 2012 22:02:34 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=9088; t=1326337181; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=XAaED6z qDFF9qbX/gcmOAp3uwQNm91EUHZoBCSKp5CQ=; b=nwv+xSru4A9qHQpHDCSR6V3 lNZLkhGLCwE1/EzBuukCQm5BnRreVJQg/ryW8qZwTIWwdNyXaIlS6KajQ64+kD6F 3snblW9nvsunwHXEsEClbsXZReo+rPgCerTWQKTTGx0V8jLUDLt9fZthRFZErJBh V9RitoDqqW3i8b0QD1p8= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Wed, 11 Jan 2012 21:59:41 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 138203236.4490.2044; Wed, 11 Jan 2012 21:59:39 -0500 Message-ID: <4F0E4D3D.10107@isdg.net> Date: Wed, 11 Jan 2012 22:02:21 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 03:02:44 -0000 Derek Diget wrote: > On Jan 11, 2012 at 17:17 -0500, Hector Santos wrote: > =>Section 10.1 Processing Limits, covers the security idea of limits. But it > =>only mentions one hard limit of 10 for MX and PTR. It recommends a unspecified > =>minimum for others like INCLUDE which is more of a concern because of its > =>recursive nature. We have a limit of 20 here. Probably more than enough to > =>allow a domain to general an include recursion level of 20! Each of these > =>directive whether with macros or not, needs to have limits. > => > =>So in my view, it will probably be a good idea to avoid the "guessing game" > =>and begin to add semantics about specific recommended limits. > => > =>Doug is suggesting of changing the 10 for MX/PTR to maybe 5. Where did 10 > =>come from to begin with? I presume is what was some SMTP client were already > =>doing when sending out mail - they have a MX expansion limit of 10. Maybe the > =>10 come from the author's experience with this. > > I have been reading this thread and wanting to chime in... > > I have always read the first sentence of the 3rd paragraph of RFC 4408 > section 10.1 (starts with "SPF implementations MUST limit") to mean that > an SPF record that requires more that 10 DNS lookups to be a PermError > and the SPF library should not do a 11th lookup. Period/end-stop. > > The MX limit that is mentioned in later paragraphs is still constrained > by the first sentence's (10 lookup) limit. I would almost say that the > 4th paragraph ('When evaluating the "mx"') is redundant to the 3rd > paragraph except for the mention of the %{p} macro. > > > (I can't speak for code writers of the MTA we use, but I think that is > the behavior I have seen. 11 DNS lookup causes a PermError to be > returned by check_host() ). I think its a matter of what DNS client/API the SPF software used. As I always understood what were the practical issues, it was the two limits, one based for on recursion (i.e. Stack) limit and one limit for the expansion of the MX host record. Recursion is largely dependend on the API on how it repeats a function recursively, i.e first record has a INCLUDE, which has a INCLUDE, which has as INCLUDE, and so on. A well coded, elegant recursive function, OOPS or otherwise, will do this recursively and there could be stack limits. Viruses are out there that specifically look for these "overflow" design errors because depending on the exception trap restart logic, if any, the virus payload is placed (byte wise) at the function Epilog location where the OS will return from the function. That is your classic buffer over/under flow virus that started when the eEye security firm (startup at the time) exposed *blackmailed Microsoft" by showing how easy it can be done back in 1999/2000. All future buffer overflow viruses were based on the eEye exposure. The MX expansion length support is well known for SMTP clients when doing a MX lookup. Some larger domains, ESP, like YAHOO.COM, AOL.COM has very large MX expansions compared to most systems. With Yahoo, when fully expanded, you get 13 IP addresses. V:\wc5beta>testwcdns /q=mx /nd- /nc yahoo.com TESTWCDNS v2.7 (c) copyright 2004-2012 Santronics Software, Inc - DNS Cache Enabled : No - DNS Servers : 208.247.131.210, 192.168.1.254 - DNS Resource Type : MX - DNS Lookup Timeout : 10 secs - DNS Max Records : 64 - MX Expand Multi-Home: Yes - MX Delay Lookup : No * Host: [yahoo.com] count : 13 =========================================================================== RR D# | TTL | PRE | HOST | DATA =========================================================================== MX 0 | 590 | 1 | mta7.am0.yahoodns.net | 209.191.88.254 MX 1 | 590 | 1 | mta7.am0.yahoodns.net | 66.94.237.64 MX 2 | 590 | 1 | mta7.am0.yahoodns.net | 66.94.237.139 MX 3 | 590 | 1 | mta7.am0.yahoodns.net | 66.94.238.147 MX 4 | 590 | 1 | mta7.am0.yahoodns.net | 67.195.103.233 MX 5 | 590 | 1 | mta7.am0.yahoodns.net | 74.6.136.65 MX 6 | 590 | 1 | mta7.am0.yahoodns.net | 74.6.140.64 MX 7 | 590 | 1 | mta7.am0.yahoodns.net | 98.139.175.225 MX 8 | 590 | 1 | mta5.am0.yahoodns.net | 67.195.168.230 MX 9 | 590 | 1 | mta5.am0.yahoodns.net | 66.94.236.34 MX 10 | 590 | 1 | mta6.am0.yahoodns.net | 98.137.54.238 MX 11 | 590 | 1 | mta6.am0.yahoodns.net | 98.139.54.60 MX 12 | 590 | 1 | mta6.am0.yahoodns.net | 67.195.103.232 =========================================================================== but with AOL.COM, you get 19 IP addresses in the MX expansion: V:\wc5beta>testwcdns /q=mx /nd- /nc aol.com TESTWCDNS v2.7 (c) copyright 2004-2012 Santronics Software, Inc - DNS Cache Enabled : No - DNS Servers : 208.247.131.210, 192.168.1.254 - DNS Resource Type : MX - DNS Lookup Timeout : 10 secs - DNS Max Records : 64 - MX Expand Multi-Home: Yes - MX Delay Lookup : No * Host: [aol.com] count : 19 ============================================================================ RR D# | TTL | PRE | HOST | DATA ============================================================================ MX 0 | 256 | 15 | mailin-04.mx.aol.com | 205.188.103.2 MX 1 | 256 | 15 | mailin-04.mx.aol.com | 205.188.146.194 MX 2 | 256 | 15 | mailin-04.mx.aol.com | 64.12.90.34 MX 3 | 256 | 15 | mailin-04.mx.aol.com | 64.12.90.66 MX 4 | 256 | 15 | mailin-04.mx.aol.com | 64.12.138.161 MX 5 | 256 | 15 | mailin-01.mx.aol.com | 205.188.159.42 MX 6 | 256 | 15 | mailin-01.mx.aol.com | 64.12.90.1 MX 7 | 256 | 15 | mailin-01.mx.aol.com | 64.12.90.98 MX 8 | 256 | 15 | mailin-01.mx.aol.com | 205.188.59.194 MX 9 | 256 | 15 | mailin-01.mx.aol.com | 205.188.146.193 MX 10 | 256 | 15 | mailin-02.mx.aol.com | 205.188.190.1 MX 11 | 256 | 15 | mailin-02.mx.aol.com | 64.12.90.65 MX 12 | 256 | 15 | mailin-02.mx.aol.com | 64.12.139.193 MX 13 | 256 | 15 | mailin-02.mx.aol.com | 205.188.103.1 MX 14 | 256 | 15 | mailin-03.mx.aol.com | 64.12.90.33 MX 15 | 256 | 15 | mailin-03.mx.aol.com | 64.12.90.97 MX 16 | 256 | 15 | mailin-03.mx.aol.com | 205.188.59.193 MX 17 | 256 | 15 | mailin-03.mx.aol.com | 205.188.156.193 MX 18 | 256 | 15 | mailin-03.mx.aol.com | 205.188.190.2 ============================================================================ So what exactly is the LIMIT with the MX in SPF? For an SMTP client, it is not operationally required to try all 19 IP address for each Outbound Queued attempt. It probably needs to remember what it last tried, but to there is no requirement that a SMTP client is technically required to try all 19. So if the DNS client API the SPF software is using some limit on how many MX expanded IPs list are returned in order to compare with the connecting IP address, it is conceivable that the IP is not within the returned list and a failure can occur. So the LIMIT on the MX should be discussed on what precises it means and if limits are placed, the DOMAIN record owner needs to be aware that this can happen to them. Fortunately, I believe, the issue is isolated to the very few domains that do have such high MX expanded results, like YAHOO.COM, and AOL.COM. There are not many other domains with that large MX farm of machines. But its is a design consideration and in our last work with our DNS Client software, I believe the internal limit was set at 30, sufficient to cover yahoo.com, aol.com and probably everyone else. But if lets say a 10 limit means MX expanded limited, then like this testwcdns shows when I add the /c=10 count limit: V:\wc5beta>testwcdns /q=mx /nd- /nc /c=10 aol.com TESTWCDNS v2.7 (10/05/2011 DEBUG C++ 6.0) (c) copyright 2004-2012 Santronics Software, Inc - DNS Cache Enabled : No - DNS Servers : 208.247.131.210, 192.168.1.254 - DNS Resource Type : MX - DNS Lookup Timeout : 10 secs - DNS Max Records : 10 - MX Expand Multi-Home: Yes - MX Delay Lookup : No * Host: [aol.com] count : 10 ============================================================================================= RR D# | TTL | PRE | HOST | DATA ============================================================================================= MX 0 | 2798 | 15 | mailin-02.mx.aol.com | 64.12.139.193 MX 1 | 2798 | 15 | mailin-02.mx.aol.com | 205.188.103.1 MX 2 | 2798 | 15 | mailin-02.mx.aol.com | 205.188.190.1 MX 3 | 2798 | 15 | mailin-02.mx.aol.com | 64.12.90.65 MX 4 | 2798 | 15 | mailin-03.mx.aol.com | 205.188.59.193 MX 5 | 2798 | 15 | mailin-03.mx.aol.com | 205.188.156.193 MX 6 | 2798 | 15 | mailin-03.mx.aol.com | 205.188.190.2 MX 7 | 2798 | 15 | mailin-03.mx.aol.com | 64.12.90.33 MX 8 | 2798 | 15 | mailin-03.mx.aol.com | 64.12.90.97 MX 9 | 2798 | 15 | mailin-04.mx.aol.com | 64.12.90.34 ============================================================================================= then as I said, the SPF receiver and the DOMAIN owner needs to be aware that an SPF receiver MX lookup can return a IP list that is not covering the connecting IP address. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Wed Jan 11 21:36:38 2012 Return-Path: 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 0A54611E8072 for ; Wed, 11 Jan 2012 21:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.468, 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 TYirIL3xYaDQ for ; Wed, 11 Jan 2012 21:36:36 -0800 (PST) Received: from winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 763735E8001 for ; Wed, 11 Jan 2012 21:36:36 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2594; t=1326346584; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=bxryuN5nTBB7qvphDik3CdXnfFE=; b=k27fRS+TaZQRvY2JGuln +j2tLymbRbv5E20+837KPDhcUe+o5C1K/SJhf3FgJnqJtGAyrCRTbhOO8lQX4ezY UIevfaA/6Y6NCtrqdsl3uKDl1U8TLAPz+3lzqtJDdqpDr1SU18aeWFMY3O8SpD6c 1hAk1RWFdXvI3e4AXFt18D8= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 12 Jan 2012 00:36:24 -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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3843437662.36383.2952; Thu, 12 Jan 2012 00:36:24 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2594; t=1326346412; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=fxn5sQd gdk9i55eeeNLQ5BXczldAJpj5bCBWLwMSKFY=; b=ND2NTMrxAMOSd3L3BwhtJl9 bh/vX7e6YzYZJyfDfQwGvKW/0sokM9Hh9yIeFiVVZJlhFvPEMk4d5sBVOQMXxTrv giDJEBZ0WUhxq/GJXea87YjqsJ+MOvKKFlK3DKgOY9Br+1ZZwC/4/crp8krertWT nWTABlZzDU5Ecb2+9GY4= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 12 Jan 2012 00:33:32 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 147434923.4498.8172; Thu, 12 Jan 2012 00:33:31 -0500 Message-ID: <4F0E7154.4080208@isdg.net> Date: Thu, 12 Jan 2012 00:36:20 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Section 10.1 Processing Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 05:36:38 -0000 Murray S. Kucherawy responded to Derek: >> Derek Diget stated: >> I have always read the first sentence of the 3rd paragraph of RFC 4408 >> section 10.1 (starts with "SPF implementations MUST limit") to mean >> that an SPF record that requires more that 10 DNS lookups to be a >> PermError and the SPF library should not do a 11th lookup. Period/end- >> stop. >> >> The MX limit that is mentioned in later paragraphs is still constrained >> by the first sentence's (10 lookup) limit. I would almost say that the >> 4th paragraph ('When evaluating the "mx"') is redundant to the 3rd >> paragraph except for the mention of the %{p} macro. > > If people feel this is not clear enough in 4408, the bis effort would certainly be > in a position to clarify. +1 IMV, Section 10.1 is clear in covering the main real practical issues, specifically the two limits dealing with: - Recursion limits with directives such as include, redirect, and - Array sizes/length of DNS RR records returned. However, I think these two paragraphs can be further clarified: When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST be a limit of no more than 10 MX or PTR RRs looked up and checked. SPF implementations SHOULD limit the total amount of data obtained from the DNS queries. For example, when DNS over TCP or EDNS0 are available, there may need to be an explicit limit to how much data will be accepted to prevent excessive bandwidth usage or memory usage and DoS attacks. Is the 10 limit for MX/PTR lookups a limit for the number of records returned or it is the limit of MX/RR directives that are declared in SPF statements? It appears to me that first paragraph addresses the latter - a limit of 10 for 10 different MX/PTR directives in SPF statements, and the 2nd paragraph addresses an unspecified recommendation of limits for the number of records returned in a MX or PTR lookup, especially as a result of a initial truncated query and switch from UDP to TCP. In anything should be considered, possibly a statement can can added to the 2nd paragraph or separate paragraph: ..... However, keep in mind, the limit 10 for MX/PTR is not related to limiting the MX expansion of IP addresses to 10 records only or 10 PTR host records returned to 10 only. Any limit for DATA records MUST consider the possibility larger email domains may exceed the SPF implementation limit in MX expanded records or PTR records returned. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Wed Jan 11 21:47:18 2012 Return-Path: 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 8D9D421F86F4 for ; Wed, 11 Jan 2012 21:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 yxF4inOVDsfp for ; Wed, 11 Jan 2012 21:47:17 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3383121F86E3 for ; Wed, 11 Jan 2012 21:47:17 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 9AF48D04080; Wed, 11 Jan 2012 23:47:15 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1326347235; bh=dXytiL+X3XhZvgibqjChttiGYJCscnSTAot6+wSmgZ4=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=eoc8ZshG+e914BRFN1SlhuI4hsOEkjHgsVwzMeuIjsnHz4QOX1DEopU0PeRMGLvO0 ocxO5YJjmA0shDM77nh3Ro0BVQp1sqFA+Ku3OYW4ykES78+Zp4WkuqMtq2yrX80aN1 0rkYETnrSXPb7Wt/7JDPVbDScRuS/6LAbWVE8vU4= Received: from 250.sub-97-187-58.myvzw.com (250.sub-97-187-58.myvzw.com [97.187.58.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E7DBFD04025; Wed, 11 Jan 2012 23:47:14 -0600 (CST) References: <4EF8F336.8080508@gathman.org> <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> <4F0E7154.4080208@isdg.net> User-Agent: K-9 Mail for Android In-Reply-To: <4F0E7154.4080208@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 11 Jan 2012 23:47:23 -0600 To: "spfbis@ietf.org" Message-ID: <29fba028-5881-4a04-95d4-227582a3801e@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 10.1 Processing Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 05:47:18 -0000 Hector Santos wrote: >Murray S. Kucherawy responded to Derek: > >>> Derek Diget stated: >>> I have always read the first sentence of the 3rd paragraph of RFC >4408 >>> section 10.1 (starts with "SPF implementations MUST limit") to mean >>> that an SPF record that requires more that 10 DNS lookups to be a >>> PermError and the SPF library should not do a 11th lookup. >Period/end- >>> stop. >>> >>> The MX limit that is mentioned in later paragraphs is still >constrained >>> by the first sentence's (10 lookup) limit. I would almost say that >the >>> 4th paragraph ('When evaluating the "mx"') is redundant to the 3rd >>> paragraph except for the mention of the %{p} macro. >> >> If people feel this is not clear enough in 4408, the bis effort would >certainly be >> in a position to clarify. > >+1 > >IMV, Section 10.1 is clear in covering the main real practical issues, >specifically the two limits dealing with: > > - Recursion limits with directives such as include, redirect, and > - Array sizes/length of DNS RR records returned. > >However, I think these two paragraphs can be further clarified: > > When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, > there MUST be a limit of no more than 10 MX or PTR RRs looked up and > checked. > > SPF implementations SHOULD limit the total amount of data obtained > from the DNS queries. For example, when DNS over TCP or EDNS0 are > available, there may need to be an explicit limit to how much data > will be accepted to prevent excessive bandwidth usage or memory usage > and DoS attacks. > >Is the 10 limit for MX/PTR lookups a limit for the number of records >returned or it is the limit of MX/RR directives that are declared in >SPF statements? > >It appears to me that first paragraph addresses the latter - a limit >of 10 for 10 different MX/PTR directives in SPF statements, and the >2nd paragraph addresses an unspecified recommendation of limits for >the number of records returned in a MX or PTR lookup, especially as a >result of a initial truncated query and switch from UDP to TCP. > >In anything should be considered, possibly a statement can can added >to the 2nd paragraph or separate paragraph: > > ..... However, keep in mind, the limit 10 for MX/PTR is not >related to > limiting the MX expansion of IP addresses to 10 records only or 10 >PTR > host records returned to 10 only. Any limit for DATA records MUST > consider the possibility larger email domains may exceed the SPF > implementation limit in MX expanded records or PTR records returned. Hector, I would encourage you to review the entire section again. The concept of recursion limits does not appear in RFC 4408. This was used for quite awhile in pre-4408 drafts of the spec while 4408 focuses more directly on lookup limits. I suspect you may be inadvertently conflating internal implementation design decisions in your code base that were made before 4408 was published with what's in the RFC. Scott K From derek.diget+spfbis@wmich.edu Thu Jan 12 11:22:32 2012 Return-Path: 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 2E82321F85A8 for ; Thu, 12 Jan 2012 11:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Vm4CN-9Bf0UB for ; Thu, 12 Jan 2012 11:22:31 -0800 (PST) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6093B21F8644 for ; Thu, 12 Jan 2012 11:22:31 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0LXP009GA9SUY5G0@mta01.service.private> for spfbis@ietf.org; Thu, 12 Jan 2012 14:22:26 -0500 (EST) X-WMU-Spam: Gauge=X, Probability=10% on Thu Jan 12 14:22:26 2012, Report=' WMU_MSA_SMTP+ 0, TO_IN_SUBJECT 0.5, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NS ' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.12.190024 - Thu Jan 12 14:22:06 2012 Date: Thu, 12 Jan 2012 14:22:06 -0500 (EST) From: Derek Diget X-X-Sender: diget@spaz.oit.wmich.edu To: "spfbis@ietf.org" In-reply-to: <4F0E7154.4080208@isdg.net> Message-id: References: <4EF8F336.8080508@gathman.org> <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> <4F0E7154.4080208@isdg.net> Subject: Re: [spfbis] Section 10.1 Processing Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 19:22:32 -0000 On Jan 12, 2012 at 00:36 -0500, Hector Santos wrote: =>IMV, Section 10.1 is clear in covering the main real practical issues, =>specifically the two limits dealing with: => => - Recursion limits with directives such as include, redirect, and => - Array sizes/length of DNS RR records returned. Disagree. I don't see where RFC 4408 deals with the size of the DNS RR returned for a query. =>However, I think these two paragraphs can be further clarified: => => When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, => there MUST be a limit of no more than 10 MX or PTR RRs looked up and => checked. Note the "RRs looked up" phrase. I read it to mean that check_host() is limited to looking up no more that 10 DNS Resource Records. It does not say anything about the size (number) of the returned data set. => SPF implementations SHOULD limit the total amount of data obtained => from the DNS queries. For example, when DNS over TCP or EDNS0 are => available, there may need to be an explicit limit to how much data => will be accepted to prevent excessive bandwidth usage or memory usage => and DoS attacks. => =>Is the 10 limit for MX/PTR lookups a limit for the number of records returned =>or it is the limit of MX/RR directives that are declared in SPF statements? I read it to be the total number of DNS _queries_ a SPF record can cause to be looked up. As an example, the SPF library I am using fails with a PermError on latimes.com since their includes: never stop. It returns PermError after the ninth lookup for cs1.com's SPF record. The 10th (really first) lookup was the initial query for latimes.com's SPF record. (The samples of delivery attempts I have are all from what appear to be infected machines and thus I don't see any legitimate mail being rejected.) -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** From hsantos@isdg.net Thu Jan 12 11:52:27 2012 Return-Path: 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 3AB7A21F855E for ; Thu, 12 Jan 2012 11:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_64=0.6] 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 Ea8gBB4AyLsu for ; Thu, 12 Jan 2012 11:52:26 -0800 (PST) Received: from ntbbs.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 11E0121F854B for ; Thu, 12 Jan 2012 11:52:25 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2481; t=1326397937; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=K5612UMsC6FW5XK1Lwtkm8xkb/k=; b=gvi9I0v8WTFjESmJX0QK VgRalyOFrSOf8odNrcu5rn9VTXOHaioa/PRDrLJmMpskumBBRBztrXyF3T2jV4b+ bUDdf5U/9MY0lfQ/w8oEzuJNT4l0sBlQlrnkqCadoEQs7CedO93RQEeRUZZLhcln S948LVdhg8fKKBnvarn2YhA= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 12 Jan 2012 14:52:17 -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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3894788261.36383.828; Thu, 12 Jan 2012 14:52:15 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2481; t=1326397759; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=uo/Y5Q+ YM/BbP3XdDUNBGb3OQyRFClLOATtnDl0rpBI=; b=n8CQp4mP2tSIpDaM1C5osS4 IlW+Mv6IpzG2LRZDLwGxUA6+zM5b4nex+nBPbMeAh1p2xw5tOlmUb+RzkMrmtOGm cNF19hOaiE99fzh6tpSzuFRU4FaOD29FippyETU7wasF2xk1ttCfkj+3e6CcJxw0 Jnd9QJSbN/rLemOeRlNQ= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 12 Jan 2012 14:49:19 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 198781564.4550.3260; Thu, 12 Jan 2012 14:49:18 -0500 Message-ID: <4F0F39EC.10504@isdg.net> Date: Thu, 12 Jan 2012 14:52:12 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <4EF8F336.8080508@gathman.org> <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> <4F0E7154.4080208@isdg.net> <29fba028-5881-4a04-95d4-227582a3801e@email.android.com> In-Reply-To: <29fba028-5881-4a04-95d4-227582a3801e@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Section 10.1 Processing Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 19:52:27 -0000 Scott Kitterman wrote: > > Hector Santos wrote: > > > Hector, > > I would encourage you to review the entire section again. The concept of recursion limits does not appear in RFC 4408. This was used for quite awhile in pre-4408 drafts of the spec while 4408 focuses more directly on lookup limits. > > I suspect you may be inadvertently conflating internal implementation design decisions in your code base that were made before 4408 was published with what's in the RFC. > There is some truth to this. For some things, I didn't immediate update the code when the RFC was finally published. But for SPF-BIF, I still think the developer implementation point needs to be made, because if it wasn't the first, it was the among the first bug reports we got related to certain abusive records with deep includes. This is very serious because most developers or programmers will naturally use recursive software designs where the #1 issue will be a stack limitation and that is the cat's meow for the Classic Buffer Overrun viruses. That is what they look for. Its a security concern that implementations SHOULD|MUST be aware of. I would also suggest that these two paragraphs: MTAs or other processors MAY also impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be "TempError". Domains publishing records SHOULD try to keep the number of "include" mechanisms and chained "redirect" modifiers to a minimum. indirectly cover the idea of redundant, recursive calls. In one form, system performance degrades and the total time elapsed can reach a high value. So the suggestion of having a global timer correlates to such issues, and for the 2nd paragraph, term "chained" can be viewed as form of "recursion." So while it may not specific state the term, in my engineering opinion, attention and guideline to recursive related possible overhead SHOULD|MUST be provided in SPF-BIF. For SPF, when a SPF-Proc() is written starting with the initial SPF-PROC() where its parsing reaches a INCLUDE and REDIRECT, its a natural recursive call to SPF-PROC() again. To avoid this stack limits, you need to either have a recursive limit or programmatically redesign the code to be non-recursive. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Thu Jan 12 12:57:28 2012 Return-Path: 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 C37241F0C47 for ; Thu, 12 Jan 2012 12:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] 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 92mEyj0fZcG0 for ; Thu, 12 Jan 2012 12:57:28 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CA2AC1F0C3D for ; Thu, 12 Jan 2012 12:57:27 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 117FA20E410A; Thu, 12 Jan 2012 15:57:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1326401847; bh=sNSuuRPt7c20WukPhmkcGqyfBj3ktNqXX5LtsklRU9Q=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ZKEs0/GTIJTLCGBPa3mqZBxkzlhzAPwUFrU3U3FlqDJ5iEMLVpJM+OdX6kYpSkjfz tFTgLZbCA4QpnvJwc/JRfbAKwYgQR8bhTmJvfnaHw3omaCC7pRuuDi2jGB1vv8w7/y /YEAtYXf2e9MKYo+xzx5APbN79jBUzhALK8mv0zY= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D923520E4091; Thu, 12 Jan 2012 15:57:26 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 12 Jan 2012 15:57:25 -0500 Message-ID: <2540212.kdzl8tTqEJ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4F0F39EC.10504@isdg.net> References: <29fba028-5881-4a04-95d4-227582a3801e@email.android.com> <4F0F39EC.10504@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 10.1 Processing Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 20:57:28 -0000 On Thursday, January 12, 2012 02:52:12 PM Hector Santos wrote: > Scott Kitterman wrote: > > Hector Santos wrote: > > > > > > Hector, > > > > I would encourage you to review the entire section again. The concept of > > recursion limits does not appear in RFC 4408. This was used for quite > > awhile in pre-4408 drafts of the spec while 4408 focuses more directly > > on lookup limits. > > > > I suspect you may be inadvertently conflating internal implementation > > design decisions in your code base that were made before 4408 was > > published with what's in the RFC. > There is some truth to this. For some things, I didn't immediate > update the code when the RFC was finally published. When I updated pyspf fo the RFC 4408 processing limits I left the recursion depth code in place. The RFC 4408 lookup based limits are tight enough that it was unlikely the recursion limit would ever be triggered, so I can understand how that works. > But for SPF-BIF, I still think the developer implementation point > needs to be made, because if it wasn't the first, it was the among the > first bug reports we got related to certain abusive records with deep > includes. This is very serious because most developers or programmers > will naturally use recursive software designs where the #1 issue will > be a stack limitation and that is the cat's meow for the Classic > Buffer Overrun viruses. That is what they look for. Its a security > concern that implementations SHOULD|MUST be aware of. The DNS lookup limits as currently specified address this concern as well. There isn't a need for specifying special recursion depth limits for interoperability purposes. The 10 DNS lookup limit for mechanisms/modifiers solves the problem as long as an implementation can handle a recursion depth of 10 (which is needed in any case). This doesn't preclude implementers from being smart about how the approach it. In the case of (once again) pyspf, we have a check for the trivial recursion loop of a domain including itself and immediately raise an error (the first include in the latimes.com record mentioned elsewhere in the thread has this kind of error). > I would also suggest that these two paragraphs: > > MTAs or other processors MAY also impose a limit on the maximum > amount of elapsed time to evaluate check_host(). Such a limit SHOULD > allow at least 20 seconds. If such a limit is exceeded, the result > of authorization SHOULD be "TempError". > > Domains publishing records SHOULD try to keep the number of "include" > mechanisms and chained "redirect" modifiers to a minimum. > > indirectly cover the idea of redundant, recursive calls. In one form, > system performance degrades and the total time elapsed can reach a > high value. So the suggestion of having a global timer correlates to > such issues, and for the 2nd paragraph, term "chained" can be viewed > as form of "recursion." They do, but so does: SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, ... Recursion is just a special case of too many lookups. I don't think it needs special treatment to support interoperability or security. Also the first paragraph you mention there is referring to such a global timer, so I think it's fine as is. > So while it may not specific state the term, in my engineering > opinion, attention and guideline to recursive related possible > overhead SHOULD|MUST be provided in SPF-BIF. I don't understand how recursion can be a problem for an implementation that fully implements the RFC 4408 processing limits. This is the relevant text from the last pre-MARID draft: SPF clients must be prepared to handle records that are set up incorrectly or maliciously. SPF clients MUST perform loop detection, limit SPF recursion, or both. If an SPF client chooses to limit recursion depth, then at least a total of 20 redirects and includes SHOULD be supported. (This number should be enough for even the most complicated configurations.) If a loop is detected, or if more than 20 subqueries are triggered, an SPF client MAY abort the lookup and return the result "unknown". Regular non-recursive lookups due to mechanisms like "a" and "mx" or due to modifiers like "exp" do not count toward this total. Since each include/redirect counts as a mechanism/modifier that needs a DNS lookup it's not possible to get to more than half this recursion limit if the RFC 4408 limits are used. > For SPF, when a SPF-Proc() is written starting with the initial > SPF-PROC() where its parsing reaches a INCLUDE and REDIRECT, its a > natural recursive call to SPF-PROC() again. To avoid this stack > limits, you need to either have a recursive limit or programmatically > redesign the code to be non-recursive. Yes, but that's an implementation detail and not an interoperabliity requirement. Scott K From hsantos@isdg.net Thu Jan 12 13:22:55 2012 Return-Path: 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 675C511E808A for ; Thu, 12 Jan 2012 13:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_64=0.6] 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 K-2c58llDip6 for ; Thu, 12 Jan 2012 13:22:54 -0800 (PST) Received: from mail.catinthebox.net (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4489511E8073 for ; Thu, 12 Jan 2012 13:22:54 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2641; t=1326403366; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=P96TNn9/4B++httsUFkMWHxBmHA=; b=Q5hqYJ/bYq2oFCybzz3f zYq8UZDfeMibKZVXz6JEbDZ95mPq7xQClEPsrAFyaLZIPTau6MI/3emFgFKW5Xwc 06C1cm2PXJ6b16m1n+1yMilKxHY/w8XIEQynV3upVPM2UIYNTWfGZHrqwXpy+Ri4 TdU+4+3F9ykHiUxdk/28sl4= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 12 Jan 2012 16:22:46 -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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3900218250.36383.3204; Thu, 12 Jan 2012 16:22:45 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2641; t=1326403191; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Sr+9CNL PVIxOsZ73KxuuFh8A49mCPgRylKETiElleKw=; b=sqw5lv4nicxH5zxWARjOsiE VVDN1uY/UKzuV4zhvE6Ss8mLQYEQXOLOApWwxNOz8+8LSEw6G+zBBiJmTTV/GTpH K1Bn5NQFGggxAODvY3xr0kNuX6+ANnRHy8FxlEHk/V61cfh5W+j1UAunIqkk0OLa HwRwYe24YqzBoY63soo8= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 12 Jan 2012 16:19:51 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 204213736.4557.2104; Thu, 12 Jan 2012 16:19:50 -0500 Message-ID: <4F0F4F24.8050901@isdg.net> Date: Thu, 12 Jan 2012 16:22:44 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <29fba028-5881-4a04-95d4-227582a3801e@email.android.com> <4F0F39EC.10504@isdg.net> <2540212.kdzl8tTqEJ@scott-latitude-e6320> In-Reply-To: <2540212.kdzl8tTqEJ@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Section 10.1 Processing Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 21:22:55 -0000 Scott Kitterman wrote: >> So while it may not specific state the term, in my engineering >> opinion, attention and guideline to recursive related possible >> overhead SHOULD|MUST be provided in SPF-BIF. > > I don't understand how recursion can be a problem for an implementation that > fully implements the RFC 4408 processing limits. This is the relevant text > from the last pre-MARID draft: > > SPF clients must be prepared to handle records that are set up > incorrectly or maliciously. SPF clients MUST perform loop detection, > limit SPF recursion, or both. If an SPF client chooses to limit > recursion depth, then at least a total of 20 redirects and includes > SHOULD be supported. (This number should be enough for even the most > complicated configurations.) Ahhhh, That's where we got our 20 limit from! :) > > If a loop is detected, or if more than 20 subqueries are triggered, > an SPF client MAY abort the lookup and return the result "unknown". > > Regular non-recursive lookups due to mechanisms like "a" and "mx" or > due to modifiers like "exp" do not count toward this total. > > Since each include/redirect counts as a mechanism/modifier that needs a DNS > lookup it's not possible to get to more than half this recursion limit if the > RFC 4408 limits are used. Maybe it is the current TEXT went from a draft Clear and Definitive developer understanding to a more vague description. The issue is recursion as that is how most designs will do it, so I am scratching my head as to why the precise technical term and problem description was altered/removed. Sure, you can get around it with a more complex non-recursive design, hence, technically there is no stack related limit, but now a worst case of requiring a global timer. Question, does pyspf implement a global timer? >> For SPF, when a SPF-Proc() is written starting with the initial >> SPF-PROC() where its parsing reaches a INCLUDE and REDIRECT, its a >> natural recursive call to SPF-PROC() again. To avoid this stack >> limits, you need to either have a recursive limit or programmatically >> redesign the code to be non-recursive. > > Yes, but that's an implementation detail and not an interoperabliity > requirement. The entire section is about Implementation requirements. It is an interoperability problem if 10 is used and a DOMAIN just happens to requires 11. So on the flip side, the section is also an implementation guideline for domain administrators to limit their records to 10 deep recursion levels. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Thu Jan 12 14:00:23 2012 Return-Path: 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 C93B421F85EA for ; Thu, 12 Jan 2012 14:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] 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 zfwjDMkqHjB3 for ; Thu, 12 Jan 2012 14:00:23 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3693C21F85A8 for ; Thu, 12 Jan 2012 14:00:19 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8B7E220E410A; Thu, 12 Jan 2012 17:00:18 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1326405618; bh=A1/Slc4ZyF3Jg9V1UMkLudbBDqCkglL+N9GmsklGsTE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=aLnZY+6EUgXAWiGAe8mOAbkwyBQtAF57jpsIhkj+FjLWUZ0NVjB1TUAZcLYihGR58 mMBBniT6LCdzowxftReEEj10uH0RcZawVy8FbjNt9pna/mV8iS/dVilXwNfK/l6W/j IQlzAV4MpercCbxowB7enniNo837o4BJtJPfzjKk= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6009720E4091; Thu, 12 Jan 2012 17:00:18 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 12 Jan 2012 17:00:16 -0500 Message-ID: <1630433.fJ5PUj5KCQ@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4F0F4F24.8050901@isdg.net> References: <2540212.kdzl8tTqEJ@scott-latitude-e6320> <4F0F4F24.8050901@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 10.1 Processing Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 22:00:23 -0000 On Thursday, January 12, 2012 04:22:44 PM Hector Santos wrote: > Scott Kitterman wrote: > >> So while it may not specific state the term, in my engineering > >> opinion, attention and guideline to recursive related possible > >> overhead SHOULD|MUST be provided in SPF-BIF. > > > > I don't understand how recursion can be a problem for an implementation > > that fully implements the RFC 4408 processing limits. This is the > > relevant text> > > from the last pre-MARID draft: > > SPF clients must be prepared to handle records that are set up > > incorrectly or maliciously. SPF clients MUST perform loop > > detection, > > limit SPF recursion, or both. If an SPF client chooses to limit > > recursion depth, then at least a total of 20 redirects and > > includes > > SHOULD be supported. (This number should be enough for even the > > most > > complicated configurations.) > > Ahhhh, That's where we got our 20 limit from! :) > > > If a loop is detected, or if more than 20 subqueries are > > triggered, > > an SPF client MAY abort the lookup and return the result > > "unknown". > > > > Regular non-recursive lookups due to mechanisms like "a" and "mx" > > or > > due to modifiers like "exp" do not count toward this total. > > > > Since each include/redirect counts as a mechanism/modifier that needs a > > DNS lookup it's not possible to get to more than half this recursion > > limit if the RFC 4408 limits are used. > > Maybe it is the current TEXT went from a draft Clear and Definitive > developer understanding to a more vague description. The issue is > recursion as that is how most designs will do it, so I am scratching > my head as to why the precise technical term and problem description > was altered/removed. Sure, you can get around it with a more complex > non-recursive design, hence, technically there is no stack related > limit, but now a worst case of requiring a global timer. Question, > does pyspf implement a global timer? The limits defined in RFC 4408 are not just about recursion. They are about limiting DNS lookups. They limit recursion even more than the old limits did, but they do other things too. The limits are difficult to understand because they are complex, but I think they are reasonable and there's no evidence they need to be different than they are. Once we get into the work of the group, I think it would be worthwhile to see if there is a clearer way to explain them. No, pyspf doesn't implement a global timer, it's per lookup. It probably should (it's on my TODO list). > >> For SPF, when a SPF-Proc() is written starting with the initial > >> SPF-PROC() where its parsing reaches a INCLUDE and REDIRECT, its a > >> natural recursive call to SPF-PROC() again. To avoid this stack > >> limits, you need to either have a recursive limit or programmatically > >> redesign the code to be non-recursive. > > > > Yes, but that's an implementation detail and not an interoperabliity > > requirement. > > The entire section is about Implementation requirements. It is an > interoperability problem if 10 is used and a DOMAIN just happens to > requires 11. So on the flip side, the section is also an > implementation guideline for domain administrators to limit their > records to 10 deep recursion levels. They are implementation requirements, but specifics of recursive versus non- recursive design and how to process records that are within the processing limits are implementation design and not requirements. I don't think we need to specify the means and methods of meeting those requirements. Scott K From msk@cloudmark.com Thu Jan 12 14:07:18 2012 Return-Path: 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 0F85D11E8073 for ; Thu, 12 Jan 2012 14:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 UpdbbHG3VD2j for ; Thu, 12 Jan 2012 14:07:17 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9584221F872D for ; Thu, 12 Jan 2012 14:07:17 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 12 Jan 2012 14:07:09 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 12 Jan 2012 14:07:16 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Thu, 12 Jan 2012 14:07:15 -0800 Thread-Topic: [spfbis] Section 10.1 Processing Limits Thread-Index: AczRdZbp8eAivtamRxijTLTneSMI0AAAOTPw Message-ID: References: <2540212.kdzl8tTqEJ@scott-latitude-e6320> <4F0F4F24.8050901@isdg.net> <1630433.fJ5PUj5KCQ@scott-latitude-e6320> In-Reply-To: <1630433.fJ5PUj5KCQ@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Section 10.1 Processing Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 22:07:18 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On > Behalf Of Scott Kitterman > Sent: Thursday, January 12, 2012 2:00 PM > To: spfbis@ietf.org > Subject: Re: [spfbis] Section 10.1 Processing Limits >=20 > They are implementation requirements, but specifics of recursive versus > non- recursive design and how to process records that are within the > processing limits are implementation design and not requirements. I > don't think we need to specify the means and methods of meeting those > requirements. In fact, we SHOULD NOT. :-) -MSK From hsantos@isdg.net Thu Jan 12 19:04:16 2012 Return-Path: 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 666D311E808E for ; Thu, 12 Jan 2012 19:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=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 GXrBHbgpvqsP for ; Thu, 12 Jan 2012 19:04:15 -0800 (PST) Received: from pop3.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7699F11E8074 for ; Thu, 12 Jan 2012 19:04:14 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3464; t=1326423852; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Jfr+iaju4rtx6TIagPtjB0eQPXM=; b=gQR0CIQoSp5mzA7hwq4/ DJYusjjV02Eh++fDRdG522oIXyDFFY8esbmkckvgZWlnhrqMGKzMOfjbiYFJmR1M s2BDHYR+Ud3zhtN2/Jg5y/OW305DslmQQgLaWPgJukQfwzkNYd2uygDP2frTt6Fq cHmfqerpX8ibQAnx0gXKVS0= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 12 Jan 2012 22:04:12 -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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3920703537.36383.3628; Thu, 12 Jan 2012 22:04:11 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3464; t=1326423677; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=IEXisK3 0YV3xU4fLCTVp2UMl5GSgdEQ/Z4kPJuQ2f9E=; b=rODyvUQqnQ9R/1Ex9sDUefS A3icZnEbeL+ygc93hx0D6T07dR/KpGwwDuFxOYExNfW3EyitHfzYuTdv8lPW2PN5 +1ueZxv3j8WlFX1FAMc8msqLAOd9zeI9UepOdKcwGL9JaD0JdhJh5dZnrsVP2GM8 c98HoMEaZ0cia6nEJyIU= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Thu, 12 Jan 2012 22:01:17 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 224699626.4582.6736; Thu, 12 Jan 2012 22:01:16 -0500 Message-ID: <4F0F9F29.2040008@isdg.net> Date: Thu, 12 Jan 2012 22:04:09 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <2540212.kdzl8tTqEJ@scott-latitude-e6320> <4F0F4F24.8050901@isdg.net> <1630433.fJ5PUj5KCQ@scott-latitude-e6320> In-Reply-To: <1630433.fJ5PUj5KCQ@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Section 10.1 Processing Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 03:04:16 -0000 Scott Kitterman wrote: >> HLS: >> The entire section is about Implementation requirements. It is an >> interoperability problem if 10 is used and a DOMAIN just happens to >> requires 11. So on the flip side, the section is also an >> implementation guideline for domain administrators to limit their >> records to 10 deep recursion levels. > > They are implementation requirements, but specifics of recursive versus non- > recursive design and how to process records that are within the processing > limits are implementation design and not requirements. I don't think we need > to specify the means and methods of meeting those requirements. Scott, I think we are being a little anal on the idea that I was advocating a specific coding method over another. Far from it. I do see your point of what you are saying; that the MUST 10 limit will cover all coding concerns and "SHOULD" be enough to avoid Stack overflows for recursive implementations. What I am stating is that the INCLUDE/REDIRECT is not only a DNS lookup, but also a high, if not a higher performance penalty than the DNS lookup, by the shear nature it may be done recursively. Going over section 10.1, here is what I suggest. In paragraph 6, 1st sentence, add the word combined SPF implementations MUST limit the _combined_ number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier. Based on that statement, we can possibly add a new sentence: This hard limitation implies SPF domain administrators are limited to SPF policy statements containing at most 10 mechanisms that perform DNS lookups, specifically; A, PTR and MX. I personally believe that a limit related to recursion different than the 10 combined limit is warranted. Many domains just start with a SPF with a bunch of includes, for example: Initial Lookup domain1: v=spf1 include:domain2 include:domain3 include:domain4 -all Lookup #1 domain2: v=spf1 include:domain5 include:domain6 include:domain7 -all Lookup #2 domain5: v=spf1 include:domain8 include:domain9 include:domain10 -all Lookup #3 domain8: v=spf1 include:domain11 include:domain12 include:domain13 -all Lookup #4 domain11: v=spf1 include:domain14 include:domain15 include:domain16 -all Lookup #5 domain14: v=spf1 include:domain17 include:domain18 include:domain19 -all Lookup #6 domain17: v=spf1 include:domain20 include:domain21 include:domain22 -all Lookup #7 domain20: v=spf1 include:domain23 include:domain24 include:domain25 -all Lookup #8 domain23: v=spf1 include:domain26 include:domain27 include:domain28 -all Lookup #9 domain26: v=spf1 include:domain29 include:domain30 include:domain31 -all Lookup #10 domain29: v=spf1 include:domain32 include:domain33 include:domain34 -all The above would the recursive or "chained" order of the include lookups. Sure, ridiculous, but we came across such abuse, rare, trapped, so you don't about it, but it's there. Perhaps, we should consider a lower limit for recursive INCLUDE/REDIRECT mechanisms. Finally, for MX and PTR records, we need to possibly state some practical limits and/or point of that limits in RR records return can fail a comparison under some scenarios. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From spf2@kitterman.com Thu Jan 12 21:18:20 2012 Return-Path: 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 39F6311E8081 for ; Thu, 12 Jan 2012 21:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 yUzd-vKwTVWX for ; Thu, 12 Jan 2012 21:18:19 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 51F1521F85A4 for ; Thu, 12 Jan 2012 21:18:19 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A201420E410A; Fri, 13 Jan 2012 00:18:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1326431897; bh=0UmteyDcPsPtUNHaG0XKdW8aMk4WxyKqW/1kGMUpc0s=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=DpN67W3uSwQ1m1/id1tOrVS5JdNVEABwjzDS0Xqa02iiJGz8umh7IXi+kw56e091v jjFu4daJLOXRFGIkiIWMv8gpHFESgPJtvO/hCnhYnF2DiEtxJagEkCk6yTqg5Ubadp BoD3db9vBnTLrLq3E61FkxyHs0y+tc2r2lGhDElY= Received: from scott-latitude-e6320.localnet (74-222-219-222.dyn.everestkc.net [74.222.219.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 71C0620E4091; Fri, 13 Jan 2012 00:18:17 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Jan 2012 00:18:15 -0500 Message-ID: <5878078.nU06rKeTyY@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <4F0F9F29.2040008@isdg.net> References: <1630433.fJ5PUj5KCQ@scott-latitude-e6320> <4F0F9F29.2040008@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 10.1 Processing Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 05:18:20 -0000 On Thursday, January 12, 2012 10:04:09 PM Hector Santos wrote: > Scott Kitterman wrote: > >> HLS: > >> The entire section is about Implementation requirements. It is an > >> interoperability problem if 10 is used and a DOMAIN just happens to > >> requires 11. So on the flip side, the section is also an > >> implementation guideline for domain administrators to limit their > >> records to 10 deep recursion levels. > > > > They are implementation requirements, but specifics of recursive versus > > non- recursive design and how to process records that are within the > > processing limits are implementation design and not requirements. I > > don't think we need to specify the means and methods of meeting those > > requirements. > > Scott, I think we are being a little anal on the idea that I was > advocating a specific coding method over another. Far from it. I do > see your point of what you are saying; that the MUST 10 limit will > cover all coding concerns and "SHOULD" be enough to avoid Stack > overflows for recursive implementations. What I am stating is that > the INCLUDE/REDIRECT is not only a DNS lookup, but also a high, if not > a higher performance penalty than the DNS lookup, by the shear nature > it may be done recursively. I disagree. To recurse or not to recurse is a choice for the implementer. It doesn't affect interoperability. > Going over section 10.1, here is what I suggest. > > In paragraph 6, 1st sentence, add the word combined > > SPF implementations MUST limit the _combined_ number of mechanisms > and modifiers that do DNS lookups to at most 10 per SPF check, > including any lookups caused by the use of the "include" mechanism > or the "redirect" modifier. > > Based on that statement, we can possibly add a new sentence: > > This hard limitation implies SPF domain administrators are > limited to SPF policy statements containing at most 10 > mechanisms that perform DNS lookups, specifically; A, PTR and MX. redirect and include would be on this list as they inevitably cause DNS lookups. > I personally believe that a limit related to recursion different than > the 10 combined limit is warranted. Many domains just start with a > SPF with a bunch of includes, for example: > > Initial Lookup domain1: > > v=spf1 include:domain2 include:domain3 include:domain4 -all > > Lookup #1 domain2: > > v=spf1 include:domain5 include:domain6 include:domain7 -all > > Lookup #2 domain5: > > v=spf1 include:domain8 include:domain9 include:domain10 -all > > Lookup #3 domain8: > > v=spf1 include:domain11 include:domain12 include:domain13 -all > > Lookup #4 domain11: > > v=spf1 include:domain14 include:domain15 include:domain16 -all > > Lookup #5 domain14: > > v=spf1 include:domain17 include:domain18 include:domain19 -all > > Lookup #6 domain17: > > v=spf1 include:domain20 include:domain21 include:domain22 -all > > Lookup #7 domain20: > > v=spf1 include:domain23 include:domain24 include:domain25 -all > > Lookup #8 domain23: > > v=spf1 include:domain26 include:domain27 include:domain28 -all > > Lookup #9 domain26: > > v=spf1 include:domain29 include:domain30 include:domain31 -all > > Lookup #10 domain29: > > v=spf1 include:domain32 include:domain33 include:domain34 -all > > The above would the recursive or "chained" order of the include > lookups. Sure, ridiculous, but we came across such abuse, rare, > trapped, so you don't about it, but it's there. I've seen records structured like this. As you've described it here it could easily exceed the 10 DNS lookup limit, so I continue to disagree that from an interoperabliity perspective anything about recursion is different than DNS lookups and needs any different limits. I think I've demonstrated the existing limits are stricter than what you were advocating for. Absent some actual operational issues the technical limits should stay as they are, but I do think they could be explained better. > Perhaps, we should consider a lower limit for recursive > INCLUDE/REDIRECT mechanisms. > > Finally, for MX and PTR records, we need to possibly state some > practical limits and/or point of that limits in RR records return can > fail a comparison under some scenarios. MX and PTR already have separate limits (10 each). Scott K From vesely@tana.it Fri Jan 13 03:34:49 2012 Return-Path: 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 B4ECB21F8575 for ; Fri, 13 Jan 2012 03:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.654 X-Spam-Level: X-Spam-Status: No, score=-4.654 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 goIW-vga77C0 for ; Fri, 13 Jan 2012 03:34:49 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id DFFE721F8573 for ; Fri, 13 Jan 2012 03:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326454487; bh=rLLkW/1IrwKzuCgqp+gDiAx03sKmqpFSdnXCeq3vRBI=; l=2387; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=SeiZ3qN4hEXJURCtJgHp90mdTnkxB2IUeEP2HoEvLFjeSBp6Y7/ppA/X3vxL4wugW Nwhkrhr2pOyFJWkbjvzRXY6ZPAehu5M2B5DURUC1oWpghXFvYTdd31EcVSg34y+mbo 7EHAXW7h7UMSHWEOCi0Gt88ReLugz8xbmvCY88Cw= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 13 Jan 2012 12:34:47 +0100 id 00000000005DC039.000000004F1016D7.00003EE8 Message-ID: <4F1016D6.8060908@tana.it> Date: Fri, 13 Jan 2012 12:34:46 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <2540212.kdzl8tTqEJ@scott-latitude-e6320> <4F0F4F24.8050901@isdg.net> <1630433.fJ5PUj5KCQ@scott-latitude-e6320> In-Reply-To: <1630433.fJ5PUj5KCQ@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] SPF metrics, was Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 11:34:49 -0000 On 12/Jan/12 23:00, Scott Kitterman wrote: > The limits are difficult to understand because they are complex, but I think > they are reasonable and there's no evidence they need to be different than they > are. Once we get into the work of the group, I think it would be worthwhile > to see if there is a clearer way to explain them. > > No, pyspf doesn't implement a global timer, it's per lookup. It probably > should (it's on my TODO list). SPF doesn't seem to provide a computationally complete language, however complex check_host() may be. Thus, it should be feasible to evaluate an SPF record statically, up to DNS hiccups, and measure its prominent characteristics. For example, given a domain name, one could try and compute the following: * number of terms appearing, including recursion, * range of results that can be actually obtained, * default result, * number and type of IPs that can possibly result in a "pass", * number of terms actually evaluated (average), * number of necessary lookups (average), * number of necessary lookups that are cacheable (average), * TTL of cacheable data (average), * number of necessary lookups requiring a TCP session (average), * response time taken for the lookups (average), * number of unreachable terms, * number of reachable unknown modifiers, * number of reachable unknown mechanisms, * other errors? What else? Local macros can hinder such computation, but it is still possible to try "postmaster" or similar heuristics. Ditto for {%ir}. Such a dictionary of metrics may lead to a better understanding of the spec. It will teach how to publish better SPF records. That specification can be a (reusable) part of the SPF experiment description mentioned as the second deliverable. I'd assign top score to a domain that tells "pass" for a tiny number of IPs only, within UDP size, having one or more days of cache, and without any further lookup. Bottom score for domains that always return PermError, requiring 10 or more uncacheable TCP lookups for doing so. Beyond the simple extreme cases, it is difficult to provide weights that allow to end up with a single number --the SPF score-- for a given domain. I don't think we should delve into specifying precise weights, but some other independent service provider might want to do so, and it may result in a Good Thing (TM). From hsantos@isdg.net Fri Jan 13 09:15:30 2012 Return-Path: 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 BB83721F844B for ; Fri, 13 Jan 2012 09:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.469, 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 eiyl4mMSsp8U for ; Fri, 13 Jan 2012 09:15:29 -0800 (PST) Received: from mail.santronics.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5074A21F85BB for ; Fri, 13 Jan 2012 09:15:24 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2449; t=1326474918; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=NUZid18lQGeuFtYWJo8uZ33qQ1c=; b=DcvlQNtiTLk2BB2jpiXP uwP+SzkLBjF09PhY+890wrSIzygxXJDAUlJSBNQ1duAuj5f3yZE4oQCIWN3KQwno 3eIl96HKDxS5it7KizqzPHlLU/hPHBp5oGBSMkL120ARLMiogRg8f/PW8gr0QZB1 wdNwgt2Ll/0TzfQMFrcjrLs= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Jan 2012 12:15:18 -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 3971769341.36383.2928; Fri, 13 Jan 2012 12:15:17 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2449; t=1326474740; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=97hmDoE evf0zTWmVbw3ErfcncsthxYU1MXidyfCji6c=; b=NYWqf5EGf+NTdvwQ6Q0wdhA J51jOpzz3d4eguAC2vRLDRuNzGvvEUN7TUsIwK3PSafJh8BghAOFoCkRBNOnY78J qy2TWDymyyB2BT3Jg8xj4rP/uN/LLqomSxM9F1w1g9Kn06jJ7m5j4yISfRlEriUD B/KbwEZ56oXR8r10IZhM= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Jan 2012 12:12: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 275763283.4963.3964; Fri, 13 Jan 2012 12:12:19 -0500 Message-ID: <4F1066A3.90000@isdg.net> Date: Fri, 13 Jan 2012 12:15:15 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <1630433.fJ5PUj5KCQ@scott-latitude-e6320> <4F0F9F29.2040008@isdg.net> <5878078.nU06rKeTyY@scott-latitude-e6320> In-Reply-To: <5878078.nU06rKeTyY@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Section 10.1 Processing Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 17:15:30 -0000 Scott Kitterman wrote: > On Thursday, January 12, 2012 10:04:09 PM Hector Santos wrote: > > I disagree. To recurse or not to recurse is a choice for the implementer. It > doesn't affect interoperability. I guess that is why disable DNS Recursion is an option and it can have cause interoperability issues in variant results. >> Based on that statement, we can possibly add a new sentence: >> >> This hard limitation implies SPF domain administrators are >> limited to SPF policy statements containing at most 10 >> mechanisms that perform DNS lookups, specifically; A, PTR and MX. > > redirect and include would be on this list as they inevitably cause DNS > lookups. +1. This hard limitation implies SPF domain administrators are limited to SPF policy statements containing at most 10 mechanisms that perform DNS lookups, specifically; A, PTR, MX, INCLUDE and REDIRECT. > I've seen records structured like this. As you've described it here it could > easily exceed the 10 DNS lookup limit, so I continue to disagree that from an > interoperabliity perspective anything about recursion is different than DNS > lookups and needs any different limits. > > I think I've demonstrated the existing limits are stricter than what you were > advocating for. Absent some actual operational issues the technical limits > should stay as they are, but I do think they could be explained better. If systems are going to limit by the # of directives, then its reasonable to look at a different lookup order such as resolving parts or the entire record first, before recursive calls are made, e.g.; v=spf1 include:domain2 ip4:1.2.3.4 ip4:5.6.7.8 ptr:mx.domain2.com -all I may want to do the no overhead rules, i.e. IP4, first to avoid short changing a valid result before the 10 limit is reached. >> Perhaps, we should consider a lower limit for recursive >> INCLUDE/REDIRECT mechanisms. >> >> Finally, for MX and PTR records, we need to possibly state some >> practical limits and/or point of that limits in RR records return can >> fail a comparison under some scenarios. > > MX and PTR already have separate limits (10 each). IMO, 10 is unreasonable low to address the larger domains that have MX expanded results over 10. No way I will limit this to 10 and not expect to see false positives/negatives. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Fri Jan 13 10:05:44 2012 Return-Path: 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 BD19021F8474 for ; Fri, 13 Jan 2012 10:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, NORMAL_HTTP_TO_IP=0.001] 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 mHWCF-Qj3fCA for ; Fri, 13 Jan 2012 10:05:41 -0800 (PST) Received: from mail.santronics.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEB821F8440 for ; Fri, 13 Jan 2012 10:05:39 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3839; t=1326477933; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=d4Jn0hICpPg33SJxl6HaNJdW2K0=; b=pB6f+gLB+Fg/CQkAu1Rw fPOeWWcrUedKPCPHpUlGjckU/lTL1S4djTyUEVXCXl0lVBL5B0R3iojUKeeEckeD sOaHlSy1RQREpLxl2vsZtWNLHnfVAy5nKAhgH8GAOnwoJA2DwEndmWuTYhcUjYWC O+dc+fy6RuAg1PdVZoAcFEU= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Jan 2012 13:05:33 -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 3974784435.36383.3236; Fri, 13 Jan 2012 13:05:32 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3839; t=1326477757; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DBDd4nR kmIB9CvBpyuVb6jQR7gqqTpCWRHWF4n/FHTY=; b=zjMMfOn0JLYVRbWUz3fqvtT VAAVnR9KW5yjMMh7WXOKQ2oNHx95J7YVJkCr34Q1e8ryKkwBlGJlmxVOg9M+u+Sf zmviSzdnajt+Pao5dSfem7ka2E1HnVvuMDKdq6uciFghKVT7C2lG/Gy86gU7uFxM VELcXLGEt0s5r4RZZNLo= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Jan 2012 13:02:37 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 278779876.4969.2632; Fri, 13 Jan 2012 13:02:36 -0500 Message-ID: <4F10726B.8090507@isdg.net> Date: Fri, 13 Jan 2012 13:05:31 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <1630433.fJ5PUj5KCQ@scott-latitude-e6320> <4F0F9F29.2040008@isdg.net> <5878078.nU06rKeTyY@scott-latitude-e6320> <4F1066A3.90000@isdg.net> In-Reply-To: <4F1066A3.90000@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Section 10.1 Processing Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 18:05:44 -0000 Hector Santos wrote: >>> Finally, for MX and PTR records, we need to possibly state some >>> practical limits and/or point of that limits in RR records return can >>> fail a comparison under some scenarios. >> >> MX and PTR already have separate limits (10 each). > > IMO, 10 is unreasonable low to address the larger domains that have MX > expanded results over 10. No way I will limit this to 10 and not expect > to see false positives/negatives. A following to reflect what I stated offlist to another participant discussing the limit. It should be keep in mind there is a different between a SMTP client doing a normal MX lookup versus what SPF requires for an MX lookup. For SMTP client, it is not required to expand the entire set of MX host. This may be a factor in an SMTP client queuing algorithms, but overall, when doing an MX lookup, you MAY or MAY NOT get the IP records already expanded for you. That depends on your DNS server, it may be a caching or its uplink is a DNS cached server. The SMTP may get first example, 2-3 MX Host records, and only expand the first one (another DNS lookup) to begin the outbound mail session and the odds are high it can make the trip in this set of IPs without the additional complete DNS lookups to fully expand the MX records. But for SPF, you have to choice but to do non-delay, full MX expansion, otherwise the potential is high to not be able to get the IP necessary to do the comparison with the client's connecting IP address. Limiting this to 10 resultant records is, in my engineering opinion, extremely too low with a higher chance of causing SPF failures. Of course, only the larger domains will be affected. AOL.COM would be one with a full expanded set of 19 IP addresses, but fortunately, in this case, it doesn't apply because their SPF is: v=spf1 ptr:mx.aol.com ?all and for their valid IP clients, it returns only 1 host record. But for a domain server with virtual domain hosting, returning more than 10 should not be unexpected. nslookup -query=ptr 208.247.131.9 9.131.247.208.in-addr.arpa name = groups.winserver.com 9.131.247.208.in-addr.arpa name = catinthebox.net 9.131.247.208.in-addr.arpa name = pop3.winserver.com 9.131.247.208.in-addr.arpa name = mail.catinthebox.net 9.131.247.208.in-addr.arpa name = ftp.catinthebox.net 9.131.247.208.in-addr.arpa name = secure.winserver.com 9.131.247.208.in-addr.arpa name = ntbbs.winserver.com 9.131.247.208.in-addr.arpa name = news.winserver.com 9.131.247.208.in-addr.arpa name = ntbbs.santronics.com 9.131.247.208.in-addr.arpa name = mail.winserver.com 9.131.247.208.in-addr.arpa name = listserv.winserver.com 9.131.247.208.in-addr.arpa name = winserver.com 9.131.247.208.in-addr.arpa name = mail.santronics.com 9.131.247.208.in-addr.arpa name = dkim.winserver.com On a related note, does the ABNF, allow for multiple domains for a mechanism? For example, if I wanted a SPF record for the above, could I use something like this? v=spf1 ptr:winserver.com,catinthebox.com,santronics.com -all or would need to be done in three calls? v=spf1 ptr:winserver.com ptr:catinthebox.com ptr:santronics.com -all Anyway, I believe 10 RR records is to short, especially for SPF MX lookups and I would to suggest that we either expand the SPF-BIF discussion about this and/or make new recommendations. Something like perhaps: Limit of 32 for MX expanded IP records returns (DNS 4 bytes records) Limit of 16 for PTR host domain record (DNS string records) The 16 is a SWAG for PTR and have no issue with some other number or keeping it at 10 which assumes a statistical average 51.2 byte size of domain strings. But for MX, 10 is way too short. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dotis@mail-abuse.org Fri Jan 13 15:31:59 2012 Return-Path: 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 5882621F84FF for ; Fri, 13 Jan 2012 15:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 betyLDmC1uSy for ; Fri, 13 Jan 2012 15:31:58 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7405E21F84FE for ; Fri, 13 Jan 2012 15:31:58 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 9EFCA1740094 for ; Fri, 13 Jan 2012 23:31:57 +0000 (UTC) Message-ID: <4F10BEED.7050207@mail-abuse.org> Date: Fri, 13 Jan 2012 15:31:57 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 23:31:59 -0000 On 1/11/12 2:39 PM, Derek Diget wrote: > > On Jan 11, 2012 at 17:17 -0500, Hector Santos wrote: =>Section 10.1 > Processing Limits, covers the security idea of limits. But it =>only > mentions one hard limit of 10 for MX and PTR. It recommends a > unspecified =>minimum for others like INCLUDE which is more of a > concern because of its =>recursive nature. We have a limit of 20 > here. Probably more than enough to =>allow a domain to general an > include recursion level of 20! Each of these =>directive whether with > macros or not, needs to have limits. => =>So in my view, it will > probably be a good idea to avoid the "guessing game" =>and begin to > add semantics about specific recommended limits. => =>Doug is > suggesting of changing the 10 for MX/PTR to maybe 5. Where did 10 > =>come from to begin with? I presume is what was some SMTP client > were already =>doing when sending out mail - they have a MX expansion > limit of 10. Maybe the =>10 come from the author's experience with > this. 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. :^( The original concept was to permit any amount that could fit within any number of SPF records where only recursion was limited to 20. Several expressed concern about the amount of traffic a recursion approach might cause. Testing back in 2006 came across several libraries still using recursion as a limit, and some limiting hosts to the number returned within a single DNS transaction for a requested RRset, and the 5 host name limit used by Wayne instead of the 10 indicated in the draft. > I have been reading this thread and wanting to chime in... > > I have always read the first sentence of the 3rd paragraph of RFC > 4408 section 10.1 (starts with "SPF implementations MUST limit") to > mean that an SPF record that requires more that 10 DNS lookups to be > a PermError and the SPF library should not do a 11th lookup. > Period/end-stop. Dear Derek, The mechanism and modification limit is expressed in section 10.1 ,-- SPF implementations MUST limit the number of _mechanisms_ and _modifiers_ that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier. '- Please note the term "mechanism" and not DNS transaction or imprecise lookup that might imply the existence of an intervening agent. "include" is a mechanism and "redirect" is a modifier that is counted as a mechanism. The lookup limit expressed in section 5.4 "mx" ,-- This mechanism matches if is one of the MX hosts for a domain name. MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] check_host() first performs an MX lookup on the . Then it performs an address lookup on _each_ MX name returned. The is compared to each returned IP address. To prevent Denial of Service (DoS) attacks, more than 10 MX names MUST NOT be looked up during the evaluation of an "mx" mechanism (see Section 10 ). If any address matches, the mechanism matches. '-- Each "mx" mechanisms can separately invoke address resolution transactions over a maximum of 10 host names. As the dos draft demonstrated, a compliant library processed 10 mechanisms where each mechanism in turn induced 10 subsequent DNS transactions to resolve each host's IP address set. Tallying these DNS transactions is 10 times ( 1 mx rrset + 10 host/a) or 10 times 11 for 110. Of course, one must include the first transaction for the initial SPF record. This bring the total DNS transactions used to resolve a single email address to 111. This is no where near 10 many keep suggesting. > The MX limit that is mentioned in later paragraphs is still > constrained by the first sentence's (10 lookup) limit. I would > almost say that the 4th paragraph ('When evaluating the "mx"') is > redundant to the 3rd paragraph except for the mention of the %{p} > macro. > > > (I can't speak for code writers of the MTA we use, but I think that > is the behavior I have seen. 11 DNS lookup causes a PermError to be > returned by check_host() ). Perhaps you were confused by the term mechanism. A mechanism such as "mx" or "ptr" performs DNS transactions to obtain RRsets and then up to 10 subsequent transactions for each element of the RRset. In other words, 110 DNS transactions. This is made more dangerous when transactions are based upon hosts defined by email-address local-parts. As such, it would be wrong to suggest SPF results are for the entire domain or that they can be cached. The local-part concept runs afoul of Repute definitions or efforts to combine the different domain results. Regards, Doug Otis From hsantos@isdg.net Fri Jan 13 17:42:55 2012 Return-Path: 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 944C321F860E for ; Fri, 13 Jan 2012 17:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.457, 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 zYchuC7Ux39e for ; Fri, 13 Jan 2012 17:42:54 -0800 (PST) Received: from listserv.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2626921F860D for ; Fri, 13 Jan 2012 17:42:53 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4156; t=1326505364; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=r1/n8v7xKJAV8+h47Kxh20H+g10=; b=MmTGl3DmJ2DDUPFesId1 qfLZG0pXvPJ8lJUWwsE3/uhStSfKZrJHGiuKOiFgKOMKwlvS3wDp9ve8JWPpaUlt JM/iqIU3yBT0VhhnPlngapj8xf5/pRWsc2ZbuJ/nu1KfoEA+RsMwr0Q3aj6/s85K hfO/XahaobogpxRqTfxf0Ow= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Jan 2012 20:42:44 -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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 4002214949.36383.3656; Fri, 13 Jan 2012 20:42:43 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4156; t=1326505188; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+v+tdpo 83O09AmX/xDECSG2/iAhLp62IMdIPdCE/RjU=; b=AQxsskauF0blIY4+OAFeAkC 3GJWYGniHlzdpAOS5Y/5aHy97jQUNond2/f6OeJeIZeCqP3FTcbC8zn64vFG7M4c 86Geolbg91B/8nP/W5FlWGl86S23tYfJjFGPE0j/uCQL1zizAAfmtqEm167Z7WVs oaGo88Xej1TEFv4XqCD8= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 13 Jan 2012 20:39:48 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 306210829.5019.2680; Fri, 13 Jan 2012 20:39:47 -0500 Message-ID: <4F10DD94.8040905@isdg.net> Date: Fri, 13 Jan 2012 20:42:44 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> <4F10BEED.7050207@mail-abuse.org> In-Reply-To: <4F10BEED.7050207@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 01:42:55 -0000 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? That said, what we have (in our package) is a macro-based filtering language that includes a macro called DIP for DOMAIN::IP association. Its a lightweight LMAP rule that sysops can add to their filters. We recommend to add them for KNOWN transactions that do not have SPF records and only do so if its clear to them that a DIP would accurately apply. These are the DIP rules I have added over the years for our SMTP server: ;------------------------------------------------------------ Reason DIP whitelisted ;------------------------------------------------------------ accept if %DIP% = above.proper.com[208.184.76.39] accept if %DIP% = bbsnets.com[66.8.157.90] accept if %DIP% = dlois.com[216.220.225.104] accept if %DIP% = fbg.collection.com[71.40.6.42] accept if %DIP% = fbg.collection.com[71.40.6.43] accept if %DIP% = hello.sd.dreamhost.com[66.33.201.150] accept if %DIP% = ietf.org[132.151.6.22] accept if %DIP% = imc.org[208.184.76.39] accept if %DIP% = isdg.net[208.247.131.9] accept if %DIP% = jck.com[209.187.148.211] accept if %DIP% = lists.dsafe.org[66.33.206.23] accept if %DIP% = lists.php.net[216.92.131.4] accept if %DIP% = lists.xml.org[209.202.168.102] accept if %DIP% = lists.xml.org[209.202.168.106] accept if %DIP% = mail.imc.org[207.182.41.81] accept if %DIP% = mail.imc.org[208.184.76.39] accept if %DIP% = mail.songbird.com[72.52.113.17] accept if %DIP% = maximus.com[12.150.181.2] accept if %DIP% = mmx.engelschall.com[195.27.130.252] accept if %DIP% = nic.fr[192.134.7.248] accept if %DIP% = orgill.com[204.118.96.135] accept if %DIP% = republico.estv.ipv.pt[193.137.7.30] accept if %DIP% = tbsp.com[173.196.180.194] accept if %DIP% = tclbbs.com[68.252.52.41] accept if %DIP% = tclbbs.com[68.252.52.42] accept if %DIP% = tclbbs.com[68.252.52.43] accept if %DIP% = tclbbs.com[68.252.52.44] accept if %DIP% = tclbbs.com[68.252.52.45] accept if %DIP% = tclbbs.com[68.252.52.46] accept if %DIP% = v2.listbox.com[207.8.214.5] accept if %DIP% = v2.listbox.com[207.8.214.6] accept if %DIP% = v2.listbox.com[208.58.1.195] accept if %DIP% = wingate.com[202.180.113.230] accept if %DIP% = ww-bbs.com[63.168.37.2] accept if %DIP% = www1.ietf.org[132.151.6.22] Note, these are ACCEPTS, so there is no harm per se compared to DIP Reject rules. Similarly, for EHLO/HELP LMAP checks, we provide active examples in the default filter script file for rules that apply to us: ;------------------------------------------------------------ Reason HELO/EHLO mismatch ;------------------------------------------------------------ ; The following rules basically says that only the machine ; at 208.247.131.* are allowed to use the domains listed ; as part of the HELO/EHLO command. These are specifically ; for SSI. You should add your own domains with the IP address ; of where WCSMTP is running using similar rejection rules. Reject if .santronics.com in .%CDN% and %CIP% !in 208.247.131.* Reject if .winserver.com in .%CDN% and %CIP% !in 208.247.131.* Reject if .isdg.net in .%CDN% and %CIP% !in 208.247.131.* Reject if .catinthebox.net in .%CDN% and %CIP% !in 208.247.131.* Again these "default", SPF-like rules SHOULD only applied where there is precise knowledge. I can't envision a general "SPF Default" rule applicable to all non-SPF domains. Is there such a thing? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From dotis@mail-abuse.org Sat Jan 14 06:27:10 2012 Return-Path: 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 69BEC21F85F6 for ; Sat, 14 Jan 2012 06:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 C9pZdcHe4tqa for ; Sat, 14 Jan 2012 06:27:09 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id B53F421F85E6 for ; Sat, 14 Jan 2012 06:27:09 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 32D0F17400FC for ; Sat, 14 Jan 2012 14:27:08 +0000 (UTC) Message-ID: <4F1190BB.9080202@mail-abuse.org> Date: Sat, 14 Jan 2012 06:27:07 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> <4F10BEED.7050207@mail-abuse.org> <4F10DD94.8040905@isdg.net> In-Reply-To: <4F10DD94.8040905@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 14:27:10 -0000 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. When a guess by thousands of recipient libraries fail to provide consistent results, as it was for t-online.de, users believed the fault was with t-online.de, not realizing the actions of SPF foo. As a result, this created a "defacto" rule for those not publishing SPF records, "Do not publish more than 5 hosts in your MX RRset." > That said, what we have (in our package) is a macro-based filtering > language that includes a macro called DIP for DOMAIN::IP association. > Its a lightweight LMAP rule that sysops can add to their filters. > We recommend to add them for KNOWN transactions that do not have SPF > records and only do so if its clear to them that a DIP would > accurately apply. These are the DIP rules I have added over the > years for our SMTP server: The concern is not with sysops using macros, although authenticated sources will provide better consistency and security. The concern is that SPF allows _any_ domain to run SPF macros leveraging the powerful resources of recipient's email service providers. Use of local-part macros means SPF results are NOT cache-able and always require repeated macro execution. This is true even for cached SPF records! Whether it is 10 or 100 transactions per message that might be generated, these transactions represent a FREE attack for any malefactor. These additional transactions are unlikely noticed or logged by email service providers. Their trigger is any email message that forwarded the malefactor's Mail From parameter as required by SMTP. When a malefactor's SPF record targets some victim domain, messages sent to thousands of different domains will trigger their Distributed Denial of Service attack with a high level of amplification. An attack where victims never see the messages, and where those reflecting the attack will likely remain unaware of their role. None of the messages or SPF records need to contain the victim's domain since even this can be synthesized by SPF macros. Virtually all other services authenticate with a brief exchange cryptographically verified within a few transactions that: 1) factors are cache-able (spf + local-part macros NOT cache-able) 2) results are cache-able (spf + local-part macros NOT cache-able) 3) minimal demand on recipients (NOT cache-able and 100+ transactions/msg) After the high resource expenditure, the email provider reflecting their resources remains an enigma, and only their IP address have been authorized. The domain involved could be one of the 100K new seen daily. > Again these "default", SPF-like rules SHOULD only applied where there > is precise knowledge. I can't envision a general "SPF Default" rule > applicable to all non-SPF domains. Is there such a thing? Unfortunately, many consider making a guess is okay. All of this risk, guesswork, and wasteful use of resources disappears with the use of normal server authentication. Email service providers need to AUTHENTICATE to protect users, their reputations, and to function properly with IPv6. Regards, Doug Otis From hsantos@isdg.net Wed Jan 18 02:47:00 2012 Return-Path: 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 ; 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 ; 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 ; 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 Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From pgladstone@cisco.com Wed Jan 18 06:40:32 2012 Return-Path: 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 20F0321F87FD for ; Wed, 18 Jan 2012 06:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] 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 r+qn6zbySH9j for ; Wed, 18 Jan 2012 06:40:31 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3464721F87FA for ; Wed, 18 Jan 2012 06:40:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=1658; q=dns/txt; s=iport; t=1326897631; x=1328107231; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=GT8zrjy0D3foZslgy1ar//WAiPiXh8WFROPR7tBLAuU=; b=nBXqjT8dBBBCSR9biI7Xb6QB2Xcc0eD3OTJG7GtUsgtcVz2wczyTLxeS Di4ojCIXUT7rYv/cMKtW0bhwId058/yFQGNLV3FHAabV/CSoY0wVwQo9V BxRbDjaeCr2lm+dMVs7dM9oRLaY0FjZwf9oDi1ie22XGGhF3LR2wppjEe 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAB/ZFk9Io8UY/2dsb2JhbABBA4UEp0GCBoFyAQEBBBIBEBVADwILGAICBRYLAgIJAwIBAgEJPBMGAgEBHqIEAYxikgYEgSuICQEBCAQNFAIBAgEBDQUEEQUBBgEBBgEFByUBAgEBBQMBAQEBAhYVAwEGDAcCAgMdAwEGCQIBDQEBAwsCCwILAwEBCYExAQEFAgMHAQEBAgEBAQEcAgYBRwWCBoEWBIg7jFiFVY0P X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="3677531" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 18 Jan 2012 14:40:29 +0000 Received: from [161.44.106.143] (dhcp-161-44-106-143.cisco.com [161.44.106.143]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0IEeSfS019583 for ; Wed, 18 Jan 2012 14:40:29 GMT Message-ID: <4F16D9DB.6040700@cisco.com> Date: Wed, 18 Jan 2012 09:40:27 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> <4F10BEED.7050207@mail-abuse.org> <4F10DD94.8040905@isdg.net> <4F1190BB.9080202@mail-abuse.org> <4F16A2FB.3070709@isdg.net> In-Reply-To: <4F16A2FB.3070709@isdg.net> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 14:40:32 -0000 On 1/18/2012 5:46 AM, Hector Santos wrote: > 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. > I think that the question could be rephrased as: For a particular receiving MTA, for all mail senders who do not publish an SPF record, does the addition of "a mx/24 ~all" improve spam detection accuracy or not? It is clear that using this record will cause all spam to be marked as ~. Depending on your spam detection algorithm, this may be the level that you would select if there was no SPF processing. If this is the case, then the "a mx/24" record will only improve the situation. Philip -- Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ From spf2@kitterman.com Wed Jan 18 07:05:08 2012 Return-Path: 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 48BD621F8707 for ; Wed, 18 Jan 2012 07:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=-0.860, BAYES_20=-0.74] 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 ScmNfdzbp08F for ; Wed, 18 Jan 2012 07:05:07 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDEF21F86FC for ; Wed, 18 Jan 2012 07:05:07 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6274420E40A4; Wed, 18 Jan 2012 10:05:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1326899106; bh=tNYuNbxUnPlZp1ig7MhgokEiPpJWaXFkr8jECIqa3/k=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=eupLE9XUUooxUdGzzZ1vifLOkR5XSK9Mh0FkUM0MBXM+QxUlDIv/H6WE94CrMsTP9 rXl+iPs+MKhfT+yTP+hZt/oSiNmyzvxPylf+vpLvhxGy6iRYOphTFMx+kGARIpubya cVTC+C975YUkrrC9FnGku6MENDVtUkt8Oxg+oeCM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4901420E4081; Wed, 18 Jan 2012 10:05:06 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 18 Jan 2012 10:05:05 -0500 Message-ID: <60329510.PUQKVUEzYr@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <4F16A2FB.3070709@isdg.net> References: <4F1190BB.9080202@mail-abuse.org> <4F16A2FB.3070709@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 15:05:08 -0000 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 From msk@cloudmark.com Wed Jan 18 10:21:12 2012 Return-Path: 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 EAFE411E8085 for ; Wed, 18 Jan 2012 10:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 TRmsIZq+EumY for ; Wed, 18 Jan 2012 10:21:11 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCF311E8074 for ; Wed, 18 Jan 2012 10:21:10 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 18 Jan 2012 10:21:00 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 18 Jan 2012 10:21:09 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Wed, 18 Jan 2012 10:21:08 -0800 Thread-Topic: [spfbis] Local macros strike again, was Suggestion... Thread-Index: AczVzobEfQKw/pyVQQGwb8vQr4mLNAAPubSw Message-ID: References: <4EF8F336.8080508@gathman.org> <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> <4F10BEED.7050207@mail-abuse.org> <4F10DD94.8040905@isdg.net> <4F1190BB.9080202@mail-abuse.org> <4F16A2FB.3070709@isdg.net> In-Reply-To: <4F16A2FB.3070709@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 18:21:12 -0000 > -----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... >=20 > > 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. >=20 > Who? >=20 > This must be completed isolated. It's not. A Google search for "best guess SPF" comes up with numerous reco= rds, and I've seen it referenced in white papers. And I know for a fact th= at Gmail uses it. The best definition I've seen is here: http://www.openspf.net/FAQ/Best_gues= s_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 exist= s someplace. -MSK From hsantos@isdg.net Fri Jan 20 00:40:23 2012 Return-Path: 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 7AC1421F85F9 for ; Fri, 20 Jan 2012 00:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_50=0.001] 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 8YkVuj2iy6ub for ; Fri, 20 Jan 2012 00:40:18 -0800 (PST) Received: from mail.santronics.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4433121F85F6 for ; Fri, 20 Jan 2012 00:40:17 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3736; t=1327048810; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=YIyS44ymwNsjAHSKms+LsQ54xIA=; b=oan+c90A4z5v98Hu14JJ p92/FyVCyqJgrjg7zk/EserxBK87BovZlLi+nbOQD/erlSiU1XG6xouJPJaSvNTL dTYSEt+TX5Hte/EUrjghbi6R0ofrATz5GE+Yht9oflnjx0m7Ms4a/flKG7mN/Wvc YC9nskic0hxDCo78uI/3ZcY= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 20 Jan 2012 03:40:10 -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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 250687931.44950.3388; Fri, 20 Jan 2012 03:40:09 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3736; t=1327048624; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=xPnAEAH v/fY1wWiyaLOJBaQps5q2diF30tzqkC2Poyk=; b=xVdL6yDk7DrjCBLWUHmyaYZ UmKw4BHVqFlbDE7eI7BCmNEYo6/gl2S4K+Wr8UFsAHCZRMQBZB1mHoZkictZY3Fu eoW7cOegMBpsNQCAGExEr23PyS0ADVTTeafguvAouWX1y3S1I3beGHkXzqKDuGM3 Y9jL22jiefvwpPPOwxQc= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 20 Jan 2012 03:37:04 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 849647064.6255.3804; Fri, 20 Jan 2012 03:37:03 -0500 Message-ID: <4F192869.2060101@isdg.net> Date: Fri, 20 Jan 2012 03:40:09 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <4F1190BB.9080202@mail-abuse.org> <4F16A2FB.3070709@isdg.net> <60329510.PUQKVUEzYr@scott-latitude-e6320> In-Reply-To: <60329510.PUQKVUEzYr@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 08:40:23 -0000 Scott Kitterman wrote: >> 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. Well, I recall something about, but since it only made sense to me from a LOCAL POLICY and accumulated KNOWN of domain information, not applied to anonymous system, we must of been on different wave lengths. There is no logic when its applied to anonymous senders and the only conceivable rule is one based on an integrated multi-behavior MTA sender/receiver "All-In-One" machine/network. In other words, something like our own system that is a single MTA with multiple rules, receiver/router/sender. Its a MSA when the user authenticates and mail is received, its a MDA when the user DOES NOT authenticate for local mail only reception and a thread does the routing for remote mail feeding it to the sender thread(s). So such a rule would apply to us, but I assume it to be the case for other systems. I agree, if such a MX/24 best guess rule is applied, it can only be used, at best, for passing. But if one tries to work a fail or soft results, IMO, that is completely wrong to do since there is simply no requirement for the sender/receiver to be associated via MX. MX is for receiving only. Its not about sending. I recall the IETF-SMTP crowd a while back making a strong point of this to me when I was winging an ideal of using MX names formatted with sender IP address/mask information - a way to get information about the senders using an existing set of information most likely to exist for correct SMTP setups. I only thought about it because our own system is all-in-one multi-threaded receiver/sender/router. So for 99% of our SMTP customers, the sender IP is the going to be among the MX IPs they have setup. > The most that 4408bis might want to deal with the practice is to explicitly > tell people not to make up SPF records for senders. +1, good idea because it doesn't make sense for anonymous senders. However, I do see value when you known the sender but they don't have an SPF record and you know for sure they have a fixed DOMAIN::IP association as I pointed out to Doug with DIP rules. Just a method to white list known senders with known domain/ip associations. I don't know if that should mentioned or not. But its not SPF, IMO. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Fri Jan 20 01:06:26 2012 Return-Path: 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 6385621F84D0 for ; Fri, 20 Jan 2012 01:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.496, 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 jk1m1aOnRK4v for ; Fri, 20 Jan 2012 01:06:21 -0800 (PST) Received: from mail.santronics.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0040121F858A for ; Fri, 20 Jan 2012 01:06:18 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=773; t=1327050376; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=8gR+8d/0Prs6Z1ewRnrIdv3aGPU=; b=aQ90lVU6MvofVb/LBNZi T07grk/kvi0q3QhOCNzcjgTfg3iHvsWiifRoqy2otqC1AXSOXf31RMPKFPe9lgr9 gfpnRvaPh7c90CEMtkJKbVFJzD9Plgg6YBPPPev5yNycpJg+WOnRrXft4uezFsFW GwzyknB8h2gSCFgxUw6nILI= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 20 Jan 2012 04:06:16 -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 beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 252253073.44950.2664; Fri, 20 Jan 2012 04:06:15 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=773; t=1327050187; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=h9ZhrdT aft7dmpi1kLjiRMMG/aGGKRI6VfGdciwu4SU=; b=awwPtnDJzQ+DGBXKw8+DuO9 XI+u3jH2PQXXYWn77rloJHe2YCnbEFquUHBLga5jFez3ZivCAj45wBV7/FuHvINA +ykOKkyye3d78eI9ml30Qyfj0UqY/Bf8jsFSqUAPSWJ5hhBb6AIlXZBmmH2Mhb89 IIp8VCfOqJBfFQ6soTIM= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 20 Jan 2012 04:03:07 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 851209798.6257.3600; Fri, 20 Jan 2012 04:03:06 -0500 Message-ID: <4F192E82.2090000@isdg.net> Date: Fri, 20 Jan 2012 04:06:10 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4F1190BB.9080202@mail-abuse.org> <4F16A2FB.3070709@isdg.net> <60329510.PUQKVUEzYr@scott-latitude-e6320> <4F192869.2060101@isdg.net> In-Reply-To: <4F192869.2060101@isdg.net> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 09:06:26 -0000 Hector Santos wrote: > There is no logic when its applied to anonymous senders and the only > conceivable rule is one based on an integrated multi-behavior MTA > sender/receiver "All-In-One" machine/network. In other words, something > like our own system that is a single MTA with multiple rules, > receiver/router/sender. Its a MSA when the user authenticates and mail > is received, its a MDA when the user DOES NOT authenticate for local > mail only reception and a thread does the routing for remote mail > feeding it to the sender thread(s). So such a rule would apply to us, > but I assume it to be the case for other systems. Correction: "but I can't assume ....." -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Fri Jan 20 02:02:30 2012 Return-Path: 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 8BD0521F856C for ; Fri, 20 Jan 2012 02:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.485, 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 cGWo6CTqv2eF for ; Fri, 20 Jan 2012 02:02:25 -0800 (PST) Received: from ntbbs.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6567421F855B for ; Fri, 20 Jan 2012 02:02:24 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2269; t=1327053736; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=J1yL4S9fkYKatAdpwcKc5Q743ME=; b=N9uxYqACo4r1ddbnPxEu x3Z/jXFMj0VtZI0eAlaQxtF8EKma5cWQhE+30V1K33n7niBx357uftwCesU5oEdI 0Pfc7BF6++BdOBsJlfU0upwakYncgYr3ztngllH5bRcslD3Pz+Hf2TaMPtoNnmjG OpT5f2dLhQo2j5lsRcLY3eY= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 20 Jan 2012 05:02:16 -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 255613163.44950.2420; Fri, 20 Jan 2012 05:02:15 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2269; t=1327053549; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2y++ZUU vizxikWSN9L5Js5HcQ2s3nYsTMSSZeJZG34I=; b=UvPOJPpfWP/dwbOBwTvimG0 SvQ4DwbA8/BGUo6KzeQnYuEsY5RACSfome41ItBI/VjAmdzL/CBOcGa1qTw4sUlO ZK/CrbYqCrQ4ukFoUOU0UTp6ooL5Vqhx7LT0WRNKv5Nj96Ms+k+ASPb3tRB9kmoe CD3dcX3t9xby3C9P+Ecs= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for spfbis@ietf.org; Fri, 20 Jan 2012 04:59:09 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 854572064.6261.6124; Fri, 20 Jan 2012 04:59:08 -0500 Message-ID: <4F193BA5.3020903@isdg.net> Date: Fri, 20 Jan 2012 05:02:13 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> <4F10BEED.7050207@mail-abuse.org> <4F10DD94.8040905@isdg.net> <4F1190BB.9080202@mail-abuse.org> <4F16A2FB.3070709@isdg.net> <4F16D9DB.6040700@cisco.com> In-Reply-To: <4F16D9DB.6040700@cisco.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 10:02:30 -0000 Philip Gladstone wrote: >> Hector Santos: >> I just don't see why you think this has any value. >> > I think that the question could be rephrased as: > > For a particular receiving MTA, for all mail senders who do not publish > an SPF record, does the addition of "a mx/24 ~all" improve spam > detection accuracy or not? > > It is clear that using this record will cause all spam to be marked as > ~. My Opinion. I would think an ? (Neutral) would more closer follow technical expectations. A Softfail (~) presumes a specific operational SMTP setup for the sender's receiver network being integrated in some fashion and since this is not a requirement, presuming a "level" of failure would be, IMO, erroneous if its to be reported as a SoftFail and there was never an official domain declaration, nor expectation, for this practice - a form of misrepsentation and tort. > Depending on your spam detection algorithm, this may be the level > that you would select if there was no SPF processing. If this is the > case, then the "a mx/24" record will only improve the situation. IMO, only to get a PASS, at best, which can only yield a data point indicating the sender/receiver network is the same or related via the "a mx/24" rule. What value does this type of sender/receiver operational knowledge offer? IMO, anything less than a PASS and more than unknown/neutral, i.e, soft fail, would have to be determined using some non-SPF logic. Perhaps an MX IP "RBL" check or perhaps an CBV on the return path which MUST NOT be invalid per 5321. So it seems to me, this is more about "leveraging" SPF reporting for some form of "Failure" checking entirely unrelated to SPF. Maybe the question is how much does a "A MX/24" rule apply today as compared to yester-years? One can suggest that with multi-core and faster OS/hardware, tons of virtual memory, the TCO can be lowered by scaling up (more CPU) and reducing scaling out (less machines). In this vain, I can see this rule being increasingly more applicable or imaginable to be true using a Pareto 80% of the time, but its still not a requirement for systems to be setup like this. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com From hsantos@isdg.net Sat Jan 21 21:55:51 2012 Return-Path: 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 ; 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 ; 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 ; 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 Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "spfbis@ietf.org" References: <4EF8F336.8080508@gathman.org> <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> <4F10BEED.7050207@mail-abuse.org> <4F10DD94.8040905@isdg.net> <4F1190BB.9080202@mail-abuse.org> <4F16A2FB.3070709@isdg.net> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From pgladstone@cisco.com Mon Jan 23 08:18:19 2012 Return-Path: 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 7D20E21F84A6 for ; Mon, 23 Jan 2012 08:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] 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 epezkchG1C2x for ; Mon, 23 Jan 2012 08:18:18 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A7CA221F84A5 for ; Mon, 23 Jan 2012 08:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=3002; q=dns/txt; s=iport; t=1327335498; x=1328545098; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=tst9L+6du16OBP3uKHLHN+ex+eVLjWutx9mFqxy0/JU=; b=BmpKzoqTMH2Qi6dFl44R7lODSP+pD67S4UZ6Y1rHRGa6bvwgPprkNNUr BAp7yT+yDDETr0cG6XeNs83fJ9n1U2JCYPQ8FJ1jHew0TgFW2yJidsBBh MOPjsSJUwotRkLEsf4umkfxBj0LiR3GjeIw8nyjJdpw84XaMFza04BP+w o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMCHHU+tJXG9/2dsb2JhbABAA4UJqR+BBYFyAQEBBAEBAQ8BEBU2Cg0CAgsRBAEBAQICBRYIAwICCQMCAQIBCQwfCQgTBgIBAR6HYpohAYxjkR4EgSuHVgWCBoEWBIg7jF6FVo0W X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="53173877" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 23 Jan 2012 16:18:18 +0000 Received: from [10.117.107.26] (rtp-pgladsto-8919.cisco.com [10.117.107.26]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0NGIGqV031874 for ; Mon, 23 Jan 2012 16:18:17 GMT Message-ID: <4F1D8848.4090206@cisco.com> Date: Mon, 23 Jan 2012 11:18:16 -0500 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4EF8F336.8080508@gathman.org> <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> <4F10BEED.7050207@mail-abuse.org> <4F10DD94.8040905@isdg.net> <4F1190BB.9080202@mail-abuse.org> <4F16A2FB.3070709@isdg.net> <4F1BA4C2.9010705@isdg.net> In-Reply-To: <4F1BA4C2.9010705@isdg.net> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 16:18:19 -0000 There is significant value in distinguishing neutral from positive. This is when this signal is an input into an anti-spam system. A positive SPF eval will (typically) allow slightly spammier looking emails through, whereas a neutral would be slightly stricter. Philip On 1/22/2012 12:55 AM, Hector Santos wrote: > 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 >> >> > -- Philip Gladstone Distinguished Engineer Product Development pgladstone@cisco.com Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ From WebMaster@Commerco.Net Mon Jan 23 10:04:08 2012 Return-Path: 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 99E7F21F86EB for ; Mon, 23 Jan 2012 10:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 H9ewPQEg--oC for ; Mon, 23 Jan 2012 10:04:04 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 253BA21F86EF for ; Mon, 23 Jan 2012 10:04:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=ZDr+7pzLNvG+TtJnoTBr6GTbVl7HGxeCwOv7oCgrR3nQXOCg0OYOz1I/r4pYH49EkheQglcTPRKjfOExfOF+W0fGD69Xg3bTWV46Rretyb6YO5mR/d99xOiDdg9cx3WX5g2uNndW2AQaUioLXY2iH9y9bRt7hLJvcfx04QlO5UQ= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Mon, 23 Jan 2012 18:04:02 +0000 Message-ID: <4F1DA10C.1030201@Commerco.Net> Date: Mon, 23 Jan 2012 11:03:56 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <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> <4F10BEED.7050207@mail-abuse.org> <4F10DD94.8040905@isdg.net> <4F1190BB.9080202@mail-abuse.org> <4F16A2FB.3070709@isdg.net> <4F1BA4C2.9010705@isdg.net> <4F1D8848.4090206@cisco.com> In-Reply-To: <4F1D8848.4090206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:04:08 -0000 Perhaps it is also important to remember that SPF is not really an anti spam system per se, rather it is a standard which primarily confirms that a domain name has indeed been permitted by its holders to send messages from a defined set of MTAs. Obviously, SPF does have some uses as regards reducing spam in situations where a bad guy may be hijacking a domain name for their spam and thus besmirching the reputation of the domain name in the eyes of the receivers of said spam. So, if a spammer sends a message via a domain which they actually do hold (and thus can control DNS and consequentially create appropriate SPF or TXT records), their mail would certainly be legitimate from an SPF standpoint. The value of SPF in this case is that the spammer cannot then go on to claim that they were not the originators of the mail, or that somehow their mail servers were hijacked by some unknown bad guy. A positive SPF eval should always confirm that the sending domain name was permitted to send, by DNS configuration, a message via the MTA from which the message came. Thus, all the intended valid email for a domain name should make it through to the receiving MTA, while additional MTA processing would be needed to address the spammier looking email which made it through, as it was before SPF ever existed. Best, Alan M. On 1/23/2012 9:18 AM, Philip Gladstone wrote: > There is significant value in distinguishing neutral from positive. This > is when this signal is an input into an anti-spam system. A positive SPF > eval will (typically) allow slightly spammier looking emails through, > whereas a neutral would be slightly stricter. > > Philip > > On 1/22/2012 12:55 AM, Hector Santos wrote: >> 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 >>> >>> >> > From presnick@qualcomm.com Tue Jan 31 22:29:17 2012 Return-Path: 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 28ED521F853A for ; Tue, 31 Jan 2012 22:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 usdaaWduoFLi for ; Tue, 31 Jan 2012 22:29:16 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3499C21F852D for ; Tue, 31 Jan 2012 22:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1328077756; x=1359613756; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F28DBB7.5070101@qualcomm.com>|Date:=20We d,=201=20Feb=202012=2000:29:11=20-0600|From:=20Pete=20Res nick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|Subject:=20U pdated=20charter=20-=20final=20review|Content-Type:=20tex t/plain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=3OP9rROuvxoazlGWWceXuxdnSa1i3FedTiGkQ+G5yqo=; b=Qmz5LXVVlXWZ2wLwiaWqOH6XEDepNUVrCY8V9Aclzb0UoSToInRlfGlh Ot4ROd4eYrbKwOTVznOqC7J9N22jM9pJlCZtZoiP/qmDRg7M8X7VxTJ5f nW106g1BB7NJHbL+ydMAdCoCEtXfLyKJi4zXuZtDh5PQKZ3fKoH5nsolH M=; X-IronPort-AV: E=McAfee;i="5400,1158,6606"; a="159553192" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 31 Jan 2012 22:29:14 -0800 X-IronPort-AV: E=Sophos;i="4.71,599,1320652800"; d="scan'208";a="248443334" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 31 Jan 2012 22:29:14 -0800 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 31 Jan 2012 22:29:13 -0800 Message-ID: <4F28DBB7.5070101@qualcomm.com> Date: Wed, 1 Feb 2012 00:29:11 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 06:29:17 -0000 All, I have made some updates to the charter based on feedback during IESG review. If I can sneak it onto the Thursday telechat this week, I might, but the IESG might be none too pleased for me to put it on so late, so it may wait two more weeks. We'll see. Please review the below and see if there is anything that makes your head explode. pr --- Working Group Name: SPF Update (SPFBIS) IETF Area: Applications Area Chair(s): TBD Applications Area Director(s): Pete Resnick Peter Saint-Andre Applications Area Advisor: Pete Resnick Mailing Lists: General Discussion:spfbis@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/spfbis Archive: http://www.ietf.org/mail-archive/web/spfbis/ Description of Working Group: The Sender Policy Framework (SPF, RFC4408) specifies the publication of a DNS record which states that a listed IP address is authorized to send mail on behalf of the listing domain name's owner. SMTP servers extract the domain name in the SMTP "MAIL FROM" or "HELO" command for confirming this authorization. The protocol has had Experimental status for some years and has become widely deployed. This working group will summarize the result of the experiment and revise the specification, based on deployment experience and listed errata, and will seek Standards Track status for the protocol. The MARID working group considered two specifications for publication of email-sending authorization: Sender-ID, which eventually became RFC4405, RFC4406 and RFC4407, and SPF, which eventually became RFC4408, all in the end published under Experimental status. By using IP addresses, both protocols specify authorization in terms of path, though unlike SPF, Sender-ID uses domain names found in the header of the message rather than the envelope. The two protocols rely on the same policy publication mechanism, namely a specific TXT resource record in the DNS. This creates a basic ambiguity about the interpretation of any specific instance of the TXT record. Because of this, there were concerns about conflicts between the two in concurrent operation. The IESG note prepended to RFC 4405 through RFC 4408 defined an experiment with SPF and Sender-ID, and invited an expression of community consensus in the period following the publication of those specifications. Both technologies initially enjoyed widespread deployment. Since that time, broad SPF use has continued, whereas use of Sender-ID has slackened. Furthermore, SPF's linkage to the envelope (as opposed to Sender-ID's linkage to identifiers in the message content) has proven sufficient among operators. Formation of the SPF Update Working Group is predicated on three assumptions: 1. The SPF/Sender-ID experiment has concluded. 2. SPF has been a qualified success, warranting further development. 3. Sender-ID has had less success, and no further development is justified. The working group will produce a document describing the course of the SPF/Sender-ID experiment, thus bringing that experiment to a formal conclusion. The group will complete additional work on SPF (described below), but will not complete additional work on the Sender-ID specification. Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. Specifically out-of-scope for this working group: * Revisiting past technical arguments where consensus was reached in the MARID working group, except where review is reasonably warranted based on operational experience. * Discussion of the merits of SPF. * Discussion of the merits of Sender-ID in preference to SPF. * Extensions to the SPF protocols. * Removal of existing features that are in current use. Discussion of extensions to the SPF protocols or removal of existing features shall only be discussed after completion of current charter items in anticipation of rechartering the working group. An initial draft of an updated SPF specification document is draft-kitterman-4408bis. The working group may choose to use this document as a basis for their specification. Goals and Milestones: Aug 2012: A document describing the SPF/Sender-ID experiment and its conclusions to the IESG for publication. Dec 2012: A standards track document defining SPF, based on RFC4408 and as amended above, to the IESG for publication. -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From msk@cloudmark.com Tue Jan 31 22:50:49 2012 Return-Path: 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 65FA321F8565 for ; Tue, 31 Jan 2012 22:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 U306zFBbtFLB for ; Tue, 31 Jan 2012 22:50:49 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id F348A21F84E7 for ; Tue, 31 Jan 2012 22:50:48 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 31 Jan 2012 22:50:48 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 31 Jan 2012 22:50:48 -0800 From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Date: Tue, 31 Jan 2012 22:50:51 -0800 Thread-Topic: [spfbis] Updated charter - final review Thread-Index: AczgqtQdlg5OP4UMTGqKhxDl40KKqQAAvY8A Message-ID: References: <4F28DBB7.5070101@qualcomm.com> In-Reply-To: <4F28DBB7.5070101@qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 06:50:49 -0000 > -----Original Message----- > From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf = Of Pete Resnick > Sent: Tuesday, January 31, 2012 10:29 PM > To: spfbis@ietf.org > Subject: [spfbis] Updated charter - final review >=20 > Please review the below and see if there is anything that makes your > head explode. Looks okay to me. -MSK From WebMaster@Commerco.Net Tue Jan 31 23:54:22 2012 Return-Path: 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 30EF021F85C9 for ; Tue, 31 Jan 2012 23:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 e6ouDZVAtSsH for ; Tue, 31 Jan 2012 23:54:21 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3851B21F85C6 for ; Tue, 31 Jan 2012 23:54:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=P/VxqOWfaF3DNYn7K4zL12oYBJF4XXmYHg2y8jmbCrPmjZM9BzSB7E05UJ25P734KxvFUR/6gVdF85NAWz0J4RMyxJiH/AFRW9OrAHblSLzFu7djYwUOhmCijd50RwA2OQ67LCD/Zip0XV8T6/Yng8io8m024+xh2QoQ7gQYh9A= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.3) with ESMTP (EHLO [10.240.241.49]) for ; Wed, 01 Feb 2012 07:54:17 +0000 Message-ID: <4F28EFA3.6040705@Commerco.Net> Date: Wed, 01 Feb 2012 00:54:11 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <4F28DBB7.5070101@qualcomm.com> In-Reply-To: <4F28DBB7.5070101@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] Updated charter - final review X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 07:54:22 -0000 Looks good, thank you. Alan M. On 1/31/2012 11:29 PM, Pete Resnick wrote: > All, > > I have made some updates to the charter based on feedback during IESG > review. If I can sneak it onto the Thursday telechat this week, I might, > but the IESG might be none too pleased for me to put it on so late, so > it may wait two more weeks. We'll see. > > Please review the below and see if there is anything that makes your > head explode. > > pr > > --- > > Working Group Name: > SPF Update (SPFBIS) > > IETF Area: > Applications Area > > Chair(s): > TBD > > Applications Area Director(s): > Pete Resnick > Peter Saint-Andre > > Applications Area Advisor: > Pete Resnick > > Mailing Lists: > General Discussion:spfbis@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/spfbis > Archive: http://www.ietf.org/mail-archive/web/spfbis/ > > Description of Working Group: > The Sender Policy Framework (SPF, RFC4408) specifies the publication > of a DNS record which states that a listed IP address is authorized > to send mail on behalf of the listing domain name's owner. SMTP > servers extract the domain name in the SMTP "MAIL FROM" or "HELO" > command for confirming this authorization. The protocol has had > Experimental status for some years and has become widely deployed. > This working group will summarize the result of the experiment and > revise the specification, based on deployment experience and listed > errata, and will seek Standards Track status for the protocol. > > The MARID working group considered two specifications for > publication of email-sending authorization: Sender-ID, which > eventually became RFC4405, RFC4406 and RFC4407, and SPF, which > eventually became RFC4408, all in the end published under > Experimental status. By using IP addresses, both protocols specify > authorization in terms of path, though unlike SPF, Sender-ID uses > domain names found in the header of the message rather than the > envelope. > > The two protocols rely on the same policy publication mechanism, > namely a specific TXT resource record in the DNS. This creates a > basic ambiguity about the interpretation of any specific instance of > the TXT record. Because of this, there were concerns about > conflicts between the two in concurrent operation. The IESG note > prepended to RFC 4405 through RFC 4408 defined an experiment with > SPF and Sender-ID, and invited an expression of community consensus > in the period following the publication of those specifications. > > Both technologies initially enjoyed widespread deployment. Since > that time, broad SPF use has continued, whereas use of Sender-ID has > slackened. Furthermore, SPF's linkage to the envelope (as opposed > to Sender-ID's linkage to identifiers in the message content) has > proven sufficient among operators. > > Formation of the SPF Update Working Group is predicated on three > assumptions: > > 1. The SPF/Sender-ID experiment has concluded. > > 2. SPF has been a qualified success, warranting further development. > > 3. Sender-ID has had less success, and no further development is justified. > > The working group will produce a document describing the course of > the SPF/Sender-ID experiment, thus bringing that experiment to a > formal conclusion. The group will complete additional work on SPF > (described below), but will not complete additional work on the > Sender-ID specification. > > Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language. > > Specifically out-of-scope for this working group: > > * Revisiting past technical arguments where consensus was reached in > the MARID working group, except where review is reasonably > warranted based on operational experience. > > * Discussion of the merits of SPF. > > * Discussion of the merits of Sender-ID in preference to SPF. > > * Extensions to the SPF protocols. > > * Removal of existing features that are in current use. > > Discussion of extensions to the SPF protocols or removal of > existing features shall only be discussed after completion of > current charter items in anticipation of rechartering the working > group. > > An initial draft of an updated SPF specification document is > draft-kitterman-4408bis. The working group may choose to use this > document as a basis for their specification. > > Goals and Milestones: > Aug 2012: A document describing the SPF/Sender-ID experiment > and its conclusions to the IESG for publication. > > Dec 2012: A standards track document defining SPF, > based on RFC4408 and as amended above, > to the IESG for publication. >