From superuser@gmail.com Fri Feb 1 11:34:05 2013 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 5EF3921E8044 for ; Fri, 1 Feb 2013 11:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+WvTQTT1T0t for ; Fri, 1 Feb 2013 11:34:04 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 56D3721E8041 for ; Fri, 1 Feb 2013 11:34:04 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so985977wib.3 for ; Fri, 01 Feb 2013 11:34:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OKrt/VJLDf2N8XxYPlrM9s5K9yECpWJTbI6pVDEbE3c=; b=KEPNLz9TisZtvpDoo8zc9Dgjt8miQh2oCWQ5sr/5FfS+Om82vISaI4qUdri6fdfH8+ IDKjp776TiEjm2RW9SjYGjBqtXWpZ0rAFtAbJcgy2f4J0gymYdOKsLbg2Ch1KsfTwQ5k D+algZfbKOrzQIuY2lvfTALJ6VNCLPO4ZqNOiaa7hD/l1GYRnlqp2RjJssKDLbz8d1qo QMXJWyYdJbhq7PqAWui/DaAz8Lk4k8/jjOLB/FgLEPNnwX7/I+GqL/CR3AhXepfMEdGe 2LwUGPeZ2DUfoODDAf3akZFAEtI6xcLTHYEE2Qy8nox4lUdS6haFvO7N4KWZlFo48oUu e6vw== MIME-Version: 1.0 X-Received: by 10.194.174.196 with SMTP id bu4mr23766762wjc.35.1359747243409; Fri, 01 Feb 2013 11:34:03 -0800 (PST) Received: by 10.180.164.43 with HTTP; Fri, 1 Feb 2013 11:34:03 -0800 (PST) In-Reply-To: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> Date: Fri, 1 Feb 2013 11:34:03 -0800 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=089e0149331a6d81f504d4aed3cd Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 01 Feb 2013 19:34:05 -0000 --089e0149331a6d81f504d4aed3cd Content-Type: text/plain; charset=ISO-8859-1 Is there a particular way the chairs would like us to tackle these on the mailing list? Are we waiting for Scott to propose changes to address each of them for the next version? Just wondering, -MSK On Thu, Jan 31, 2013 at 6:02 AM, S Moonesamy wrote: > Hello, > > According to the SPFBIS WG Charter the working group was scheduled to > submit draft-ietf-spfbis-4408bis for publication in December 2012. Here is > the list of open issues [1]: > > #22 RFC 4408: Section 2.5.7 PermError on invalid domains after macro > expansion > > #24 RFC 4408: Reasonable DNS error limits > > #29 RFC 4408: Section 2.5.4 - mark on fail > > #34 Throw a temperror - Section 5.2 > > #35 authorized_spf domain name - Section 9.1.1 > > #36 RFC 2119 key words > > #37 spf classic > > #38 Deprecated > > #39 Temporary errors implied as only caused by DNS errors > > #40 Wildcard records > > #41 Multiple DNS errors > > #42 Record Evaluation > > #43 New requirement for mx: or ptr records > > #44 Section 5.4 does not mention requirement in section 4.6.4 > > #45 Section 5.5 steps > > #46 DNS reply in Section 5.7 > > #47 domain-spec > > #48 Section 8.1 - macro defs > > #49 IANA registry for SPF modifiers > > #50 Terminology > > #51 Remove A-R from 4408bis > > #52 Section 8.1 *Macro Definitions > > #53 Possible ABNF nit with Received-SPF > > #54 Section 9.2.1 of 4408bis > > #55 Section 9.2.2 Forwarding Services and Aliases > > #56 Section 9.2.2 Forwarding Services and Aliases > > #57 x-* fields in 4408bis > > #58 Local policy in 4408bis > > #59 Remove section 9.1.1 DNS Resource Considerations > > #6 RFC 4408 Section 10.1 - Processing limits needs clarification and > reorganization > > #33 Marked Failed Mail Exposure > > Regards, > S. Moonesamy > > 1. http://trac.tools.ietf.org/wg/**spfbis/trac/report/1 > > ______________________________**_________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/**listinfo/spfbis > --089e0149331a6d81f504d4aed3cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is there a particular way the chairs would like us to= tackle these on the mailing list?=A0 Are we waiting for Scott to propose c= hanges to address each of them for the next version?

Just wondering,=

-MSK


On Thu, Jan 31, 2013 at 6:02 AM, S Moonesamy &= lt;sm+ietf@elands= ys.com> wrote:
Hello,

According to the SPFBIS WG Charter the working group was scheduled to submi= t draft-ietf-spfbis-4408bis for publication in December 2012. =A0Here is th= e list of open issues [1]:

#22 RFC 4408: Section 2.5.7 PermError on invalid domains after macro expans= ion

#24 RFC 4408: Reasonable DNS error limits

#29 RFC 4408: Section 2.5.4 - mark on fail

#34 Throw a temperror - Section 5.2

#35 authorized_spf domain name - Section 9.1.1

#36 RFC 2119 key words

#37 spf classic

#38 Deprecated

#39 Temporary errors implied as only caused by DNS errors

#40 Wildcard records

#41 Multiple DNS errors

#42 Record Evaluation

#43 New requirement for mx: or ptr records

#44 Section 5.4 does not mention requirement in section 4.6.4

#45 Section 5.5 steps

#46 DNS reply in Section 5.7

#47 domain-spec

#48 Section 8.1 - macro defs

#49 IANA registry for SPF modifiers

#50 Terminology

#51 Remove A-R from 4408bis

#52 Section 8.1 *Macro Definitions

#53 Possible ABNF nit with Received-SPF

#54 Section 9.2.1 of 4408bis

#55 Section 9.2.2 Forwarding Services and Aliases

#56 Section 9.2.2 Forwarding Services and Aliases

#57 x-* fields in 4408bis

#58 Local policy in 4408bis

#59 Remove section 9.1.1 DNS Resource Considerations

#6 RFC 4408 Section 10.1 - Processing limits needs clarification and reorga= nization

#33 Marked Failed Mail Exposure

Regards,
S. Moonesamy

1. http://trac.tools.ietf.org/wg/spfbis/trac/report/1

_______________________________________________
spfbis mailing list
spfbis@ietf.org = https://www.ietf.org/mailman/listinfo/spfbis

--089e0149331a6d81f504d4aed3cd-- From spf2@kitterman.com Fri Feb 1 11:36:39 2013 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 3FE7421E8044 for ; Fri, 1 Feb 2013 11:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P1OyddE2vvg for ; Fri, 1 Feb 2013 11:36:38 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E9CF221E8041 for ; Fri, 1 Feb 2013 11:36:37 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0435F20E4164; Fri, 1 Feb 2013 14:36:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1359747397; bh=V7nFrw7dNv5UiYYCXFi56aX6irZvMiOTZ7H++xzGotU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UVqkMomKiaa/sV1WkCmIKa4zshj6D9QU85byNLXP07uYma5ki/RzviiRzJC8dieOx hyU+YEuoiXDbjPFk8Nh449lM/ugDUhU68Ye2robmbI8cbuGhhPMEGPY30clSBXQhbV XEJEcVA2UsyJ7eAs6JPZI1A3PSGhGfLBsDhHNn1Q= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DE67A20E401D; Fri, 1 Feb 2013 14:36:36 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 01 Feb 2013 14:36:36 -0500 Message-ID: <3072379.n4VWjZEzyv@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 01 Feb 2013 19:36:39 -0000 I had anticipated working through this issues next week and making proposals or asking for discussion as seemed appropriate. Scott K On Friday, February 01, 2013 11:34:03 AM Murray S. Kucherawy wrote: > Is there a particular way the chairs would like us to tackle these on the > mailing list? Are we waiting for Scott to propose changes to address each > of them for the next version? > > Just wondering, > > -MSK > > On Thu, Jan 31, 2013 at 6:02 AM, S Moonesamy wrote: > > Hello, > > > > According to the SPFBIS WG Charter the working group was scheduled to > > submit draft-ietf-spfbis-4408bis for publication in December 2012. Here > > is > > the list of open issues [1]: > > > > #22 RFC 4408: Section 2.5.7 PermError on invalid domains after macro > > expansion > > > > #24 RFC 4408: Reasonable DNS error limits > > > > #29 RFC 4408: Section 2.5.4 - mark on fail > > > > #34 Throw a temperror - Section 5.2 > > > > #35 authorized_spf domain name - Section 9.1.1 > > > > #36 RFC 2119 key words > > > > #37 spf classic > > > > #38 Deprecated > > > > #39 Temporary errors implied as only caused by DNS errors > > > > #40 Wildcard records > > > > #41 Multiple DNS errors > > > > #42 Record Evaluation > > > > #43 New requirement for mx: or ptr records > > > > #44 Section 5.4 does not mention requirement in section 4.6.4 > > > > #45 Section 5.5 steps > > > > #46 DNS reply in Section 5.7 > > > > #47 domain-spec > > > > #48 Section 8.1 - macro defs > > > > #49 IANA registry for SPF modifiers > > > > #50 Terminology > > > > #51 Remove A-R from 4408bis > > > > #52 Section 8.1 *Macro Definitions > > > > #53 Possible ABNF nit with Received-SPF > > > > #54 Section 9.2.1 of 4408bis > > > > #55 Section 9.2.2 Forwarding Services and Aliases > > > > #56 Section 9.2.2 Forwarding Services and Aliases > > > > #57 x-* fields in 4408bis > > > > #58 Local policy in 4408bis > > > > #59 Remove section 9.1.1 DNS Resource Considerations > > > > #6 RFC 4408 Section 10.1 - Processing limits needs clarification and > > reorganization > > > > #33 Marked Failed Mail Exposure > > > > Regards, > > S. Moonesamy > > > > 1. > > http://trac.tools.ietf.org/wg/**spfbis/trac/report/1 > tf.org/wg/spfbis/trac/report/1> > > > > ______________________________**_________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/**listinfo/spfbis > n/listinfo/spfbis> From sm@elandsys.com Fri Feb 1 11:53:47 2013 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 2185E21E804E for ; Fri, 1 Feb 2013 11:53:47 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkaffbtTIltH for ; Fri, 1 Feb 2013 11:53:46 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CF421E804C for ; Fri, 1 Feb 2013 11:53:45 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.156.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r11JrN8D013268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2013 11:53:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359748419; bh=Q6EeMvWmTpwZIo/4Zuxw9dlw9my+bx7hJwr+ftfnuL0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dFKd+C9Vh7LzbDXA1ThLPhJwHxZ+3Vy2us+xwFFn/7/JWeCJEzAfMGtXJJfBUD/LQ jyhJR0qw1BSE8Oyz0r29YKYedDR2+5kx2ehUPup2zOTnFgSl6H4b3PkIaj/pmKJRpB 4UuhOwZ5M7/goO3qjmkUnUS20dOOWSoeMMPenVZA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1359748419; i=@elandsys.com; bh=Q6EeMvWmTpwZIo/4Zuxw9dlw9my+bx7hJwr+ftfnuL0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1QsongubmkokWlnhwPAFZz1G+LPWk1O9lXmgawBNeLevxQm0cduDrMqxzvDfm5k7a LFtG1SMHSdJC4ZajeLtv7dAS0G2y7TVJr33ooX4R/xu0qRle8ftM4FspJ/IigT1fYP 3FD8S6mVN040JE5K3HaLNfJbq3TIjIiMnMWib1S8= Message-Id: <6.2.5.6.2.20130201114045.059e92a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Feb 2013 11:52:58 -0800 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 01 Feb 2013 19:53:47 -0000 Hi Murray, At 11:34 01-02-2013, Murray S. Kucherawy wrote: >Is there a particular way the chairs would like us to tackle these >on the mailing list? Are we waiting for Scott to propose changes to >address each of them for the next version? My individual opinion is to pick the issues you can help to solve, suggest text, and the working group can discuss about it. I would suggest keeping it to one issue per thread as it makes it easier to track the discussion. If everybody takes on a few issues it would help speed up the work. Regards, S. Moonesamy From sm@resistor.net Fri Feb 1 14:59:18 2013 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 61DDA21E8063 for ; Fri, 1 Feb 2013 14:59:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iluZ3Aei7NO7 for ; Fri, 1 Feb 2013 14:59:17 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F6821E8041 for ; Fri, 1 Feb 2013 14:59:16 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r11Mx4Ij003268 for ; Fri, 1 Feb 2013 14:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359759548; bh=QckyH5e05L774g+Q9m8sT1HKTl0cJ41UaLab7wLQtRE=; h=Date:To:From:Subject:In-Reply-To:References; b=ItRPyN/gIvP5MGZMzRDa9ukWWFHWHFYbydKQNcT64Kljk2SEkg3a78JLFHhFxB7We dDDPVgwMhDLpQ9wuZgK+Ap+tlddHqsY+9nWsbju6nP4b/Cwqd1I+Ea2Sr6e2fAcEat sG617KMGyL6satP/q/GBiirC1Oiu89DNXmbvA3yc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359759548; i=@resistor.net; bh=QckyH5e05L774g+Q9m8sT1HKTl0cJ41UaLab7wLQtRE=; h=Date:To:From:Subject:In-Reply-To:References; b=YQDGxLlsqKSGg1ugOA+vFEhOwYzF6jh3i6nA8ngjHZ0+Gjnq5TTsiZ430T2VkZHRW 41dN19TgCzCg0OiqtlVItTKrvucJqT3bFpSWZJWxtJhTpP6m1X7N5mKvCpJ3nJIMIe jBDeq12JCd044bt3NkY+KlWPTKtDA4J0x6UGuxoE= Message-Id: <6.2.5.6.2.20130201143900.0a0537f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Feb 2013 14:40:07 -0800 To: spfbis@ietf.org From: SM In-Reply-To: <23214846.35DP7DaIiD@scott-latitude-e6320> References: <064.92cae4f8f546fe214929d9bfc7eb9d5d@tools.ietf.org> <6.2.5.6.2.20120828225739.09cf4508@elandnews.com> <23214846.35DP7DaIiD@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #37: spf classic 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, 01 Feb 2013 22:59:19 -0000 At 19:52 29-08-2012, Scott Kitterman wrote: >I cleaned it up a bit. > > > Section 1.1 requires a clean-up. > >Please review the next draft when it's published and provide recommendations >if you believe additional changes are needed. I don't see any mention of "spf classic" in draft-ietf-spfbis-4408bis-09. I'll suggest closing Issue #37. Regards, S. Moonesamy From sm@elandsys.com Fri Feb 1 14:59:22 2013 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 32A5821E8089 for ; Fri, 1 Feb 2013 14:59:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfqSZ8e+d7qv for ; Fri, 1 Feb 2013 14:59:21 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF3621E808A for ; Fri, 1 Feb 2013 14:59:21 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.156.161]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r11Mx9Qn011237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Feb 2013 14:59:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359759560; bh=Ocqq239J2c+L17Yz9ERl1u+J7NUU4AArRauiq/iWdcQ=; h=Date:To:From:Subject:In-Reply-To:References; b=znq6DqFYyssAhhwwVEjGA2hxqCMsLVwhDFld1DhN02pV0A/YQ4UAe/dB07/s5wQQ1 sMTmYQ90AazbHDZcIJjSz4RQf+bju5paUrYMdfYfOANhg+OeCFe19rSwkHzcJxpBwt aiHBFyjHLmcvlp7wAOSh8DAYy17jCqL9Bmu/9NX0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1359759560; i=@elandsys.com; bh=Ocqq239J2c+L17Yz9ERl1u+J7NUU4AArRauiq/iWdcQ=; h=Date:To:From:Subject:In-Reply-To:References; b=CNlZTnEQyeM1TpiypbPcaRNObD56VK8Yfx68nTvTfJCdUXBhPLP5jZWwHAMvgj20i ZjFm95I7CFop5cAgBft8Hep8Sr0rtv5PQxIGkzvJ09H7JNH93beOjlsMujxTr54JSY MvnwRE8YFH8IG2YdgU+l7PVBJx8TSw0/ZwFsgKaE= Message-Id: <6.2.5.6.2.20130201143305.0a1d5fb0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Feb 2013 14:36:47 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <064.27d993b3cb7210e6425eb39657584b46@tools.ietf.org> <6.2.5.6.2.20120906154516.0aba3a18@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #57: x-* fields in 4408bis 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, 01 Feb 2013 22:59:22 -0000 At 15:19 06-09-2012, Scott Kitterman wrote: >I removed the "X dash" before the initial working group draft based >on based on that BCP. Since they are by definition non-standard, I >don't think it's got any interoperability implications. Scott Kitterman made the above changes last year. To start the discussion, I'll suggest that Issue #57 be closed. Regards, S. Moonesamy From superuser@gmail.com Mon Feb 4 14:13:39 2013 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 A107B21F8B26 for ; Mon, 4 Feb 2013 14:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEh1asLyBe8j for ; Mon, 4 Feb 2013 14:13:39 -0800 (PST) Received: from mail-we0-x22c.google.com (we-in-x022c.1e100.net [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 003D221F84CE for ; Mon, 4 Feb 2013 14:13:38 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so5330900wey.3 for ; Mon, 04 Feb 2013 14:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kmtOh7rWf+oPcoV3kuMp3pdvOmmloyiDIhKeX4UKKoA=; b=Zz2DD7ITK9ECFFIUYOyjbG5RJq9Z8usI/Xd0HUejV4/QD2HvHlriSThxvnYrM1hxFU 4OHnZkaVpX5Wo+EJSfIveUQCS/1ZaCCUISIeiUkI/pENSjGFbjjDig1Hod4yOh/6kX8l 4UY8wWOa2E7RyJV3cWrAcr9zLWDuq4ClhgWHniuUrPiCr2cP67WT4pZc4WK+HGKfGNBZ JM14Hmm2W/96D5T1CPf0BMc+4B2V9rSLApgwk4rKez89yUEBgdcelf5zuXTgZrINjne6 LVV3sCVYnkSjLrEfgPwHIzp7eWSEeW/0cHy2RD0sW5gY9JDJ3XvpbWQuTuLIPZSH7ozk BSCQ== MIME-Version: 1.0 X-Received: by 10.180.86.36 with SMTP id m4mr13172181wiz.5.1360016017946; Mon, 04 Feb 2013 14:13:37 -0800 (PST) Received: by 10.180.164.43 with HTTP; Mon, 4 Feb 2013 14:13:37 -0800 (PST) In-Reply-To: <6.2.5.6.2.20130201143305.0a1d5fb0@resistor.net> References: <064.27d993b3cb7210e6425eb39657584b46@tools.ietf.org> <6.2.5.6.2.20120906154516.0aba3a18@elandnews.com> <6.2.5.6.2.20130201143305.0a1d5fb0@resistor.net> Date: Mon, 4 Feb 2013 14:13:37 -0800 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d0442859ca377df04d4ed679d Cc: "spfbis@ietf.org" Subject: Re: [spfbis] #57: x-* fields in 4408bis 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, 04 Feb 2013 22:13:39 -0000 --f46d0442859ca377df04d4ed679d Content-Type: text/plain; charset=ISO-8859-1 +1 On Fri, Feb 1, 2013 at 2:36 PM, S Moonesamy wrote: > At 15:19 06-09-2012, Scott Kitterman wrote: > >> I removed the "X dash" before the initial working group draft based on >> based on that BCP. Since they are by definition non-standard, I don't >> think it's got any interoperability implications. >> > > Scott Kitterman made the above changes last year. To start the > discussion, I'll suggest that Issue #57 be closed. > > Regards, > S. Moonesamy > ______________________________**_________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/**listinfo/spfbis > --f46d0442859ca377df04d4ed679d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1


On Fri, Feb 1, 2013 at 2:36 PM, S Moonesamy <sm+ietf@e= landsys.com> wrote:
At 15:19 06-09-2012, Scott= Kitterman wrote:
I removed the "X dash" before the initial working group draft bas= ed on based on that BCP. =A0Since they are by definition non-standard, I do= n't think it's got any interoperability implications.

Scott Kitterman made the above changes last year. =A0To start the discussio= n, I'll suggest that Issue #57 be closed.

Regards,
S. Moonesamy
_______________________________________________
spfbis mailing list
spfbis@ietf.org = https://www.ietf.org/mailman/listinfo/spfbis

--f46d0442859ca377df04d4ed679d-- From spf2@kitterman.com Tue Feb 5 07:17:26 2013 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 36DA821F8440 for ; Tue, 5 Feb 2013 07:17:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8YO1DnPg0A8 for ; Tue, 5 Feb 2013 07:17:25 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 435FB21F845D for ; Tue, 5 Feb 2013 07:17:17 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 61EDB20E40D6; Tue, 5 Feb 2013 10:17:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360077436; bh=N1RMWoQ3kwM0ywVDcAkDEM/XZyDpphL6j3bIfMSU8z8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hExtOEDaDN8TmQt92BroiLxUxLWAfjyvFUod0bWZlC9aSaqKDWfsTH+nYUX6UREv9 K4b7EBlQtuykgVzArMrCQdot1Yme4gruO1Y7cDFEwWjVux9AkC4nCs87YnTJrbbuN2 xBzMlNOrIj9FcCJ33pN+BJzqVI8XW+LAexIo6iHM= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3836520E40B2; Tue, 5 Feb 2013 10:17:15 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 10:17:14 -0500 Message-ID: <1439058.EEqD6QKl4d@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <20130116121209.GD41685@verdi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Delivering Mail Producing a 'Fail' Result - was Re: Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 15:17:26 -0000 On Wednesday, January 16, 2013 03:06:05 PM Murray S. Kucherawy wrote: > Operators are ultimately the ones that implement local policy, so I think > it's reasonable to place the focus there. It's unlikely that end users > will read this and/or try to understand it. That said, I don't have a > problem with the alternative text proposed by John. > > I think the point in the last paragraph of the proposed 11.7 needs to > remain, however. I'm working through issues for the next revision and this is one of them. I think we should stick with Murray's originally proposed text for this new security consideration: > Operators that choose to deliver mail for which SPF produces a "fail" > result need to understand that they are admitting content that is > explicitly not authorized by the purported sender. While there are > known failure modes that can be considered "false negatives", the > distincg choice to admit those messages increases end-user exposure > to likely harm. This is especially true for domains belonging to > known good actors that are typically well-behaved; unauthorized mail > from those sources might well be subjected to much higher skepticism > and content analysis. > > SPF does not, however, include the capacity for identifying good > actors from bad ones, nor does it handle the concept of known actors > versus unknown ones. Those notions are out of scope for this > specification. Here's John Leslie's proposed alternative: " Many operators have found that email for which SPF produces a "fail" " result is nonetheless email which end-users depend upon receiving, " and deliver it despite the "fail" result. This practice is permitted. " There are things the end-user can do which will distinguish SPF " "fail" email which they do want from SPF "fail" email they don't " want. " " Nonetheless, there are SPF publishers that really want an SPF "fail" " to prevent delivery. SPF does not and cannot promise that. However, " both operators and end-users should clearly understand that most " SPF "fail" emails deserve to be rejected, and a significant number " of them can cause harm. SPF "fail" emails from senders which are " typically well-behaved probably deserve much higher skepticism " and automated content-analysis. I prefer the original language (and will use it unless I get overruled). I think that the proposed alternative reads less like a security consideration. Additionally, I don't like putting things in terms of permitted practice. We've tried to minimize receiver policy for reasons that aren't worth re- hashing and so talking about practices permitted for the receiver is a bit out of step with what we're trying to communicate overall. Scott K From spf2@kitterman.com Tue Feb 5 07:35:50 2013 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 0780621F874E for ; Tue, 5 Feb 2013 07:35:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsb9jsblJ33N for ; Tue, 5 Feb 2013 07:35:49 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7F17221F8734 for ; Tue, 5 Feb 2013 07:35:49 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0B09520E40D6; Tue, 5 Feb 2013 10:35:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360078549; bh=A6to9KdRo25fi6Ew7oex/qg+l4tMR7sa3Wmvq3YW6sQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kMdTF2lxjxfOXZQZiOEOfPSp+laWTqYI0fBNjZU6RpDkzlncZ0CHhhqNumD3jukDp dxllPyaQrbr9dogo7VrHb23JL5Fm9cthcLtMMAyJy9Bpd5o87vvizg0kINFa7Z1QLr nbHXFgw6fN6T8+BGP8U1iYltHnQ10jHZ9G6rdquE= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D8B3320E40B2; Tue, 5 Feb 2013 10:35:48 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 10:35:46 -0500 Message-ID: <1443624.jLaNURLjtu@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130131065211.0a323f48@resistor.net> References: <20130125143603.GA11573@mx1.yitter.info> <1397680.5mhf1dVE2p@scott-latitude-e6320> <6.2.5.6.2.20130131065211.0a323f48@resistor.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] #24: RFC 4408: Reasonable DNS error 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: Tue, 05 Feb 2013 15:35:50 -0000 On Thursday, January 31, 2013 06:53:55 AM S Moonesamy wrote: > Hi Scott, > > At 06:22 31-01-2013, Scott Kitterman wrote: > >I think it will be resolved with the next revision. I think we've > >discussed it sufficiently. Next week looks to be good for me to take a > >stab at making progress on the remaining issues. > > Thanks for the feedback. This is what I've put in my local copy of the to revision 10 (line breaks are better in the draft): > The published SPF record for a given domain name SHOULD remain > small enough that the results of a query for it will fit within > 512 octets. This UDP limit is defined in target="RFC1035"/> > section 2.3.4. This will keep even older DNS implementations > from > falling over to TCP. Since the answer size is dependent on many > things outside the scope of this document, it is only possible > to > give this guideline: If the combined length of the DNS name and > the text of all the records of a given type is under 450 octets, > then DNS answers ought to fit in UDP packets. Records that are > too long to fit in a single UDP packet could be silently ignored > by SPF > verifiers due to firewall and other issues that cause DNS over > TCP > to be less reliable than DNS over UDP. > > Note that when computing the sizes for replies to queries of the > TXT > format, one has to take into account any other TXT records > published > at the domain name. Similarly, the sizes for replies to all > queries > related to SPF have to be evaluated to fit in a single UDP > packet. I believe it addresses the specific concern raised without driving into a lot of detail about how one operates DNS. Scott K From spf2@kitterman.com Tue Feb 5 07:43:57 2013 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 4B74321F86A2 for ; Tue, 5 Feb 2013 07:43:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztbU-Bn26xMT for ; Tue, 5 Feb 2013 07:43:56 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AEA6521F8558 for ; Tue, 5 Feb 2013 07:43:56 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4A82320E40D6; Tue, 5 Feb 2013 10:43:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360079034; bh=0prLs1R0T2+JWMcfUwowT7s3GelY1WYVeKj/1wqNL6k=; h=From:To:Subject:Date:In-Reply-To:References:From; b=K1Dd3+G7ir4pKy7Jmp7+QaguWkxCUFTUvb0wjpyuJNIxy6Ew5XR9r6Ef02Npq9ISM DrtA7dbVrYpOCvz3Z/agWTVeOhIvMGLYRrjMc1CBO7zONPaAWX/kYb4h4Iv/UdGzVD rFGB0gdb3B2fOtWwR+qk0U1TPSbrFrv/y360Wc/k= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2353A20E40B2; Tue, 5 Feb 2013 10:43:53 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 10:43:52 -0500 Message-ID: <12146425.RE9Yz5NdO9@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130201143900.0a0537f8@resistor.net> References: <064.92cae4f8f546fe214929d9bfc7eb9d5d@tools.ietf.org> <23214846.35DP7DaIiD@scott-latitude-e6320> <6.2.5.6.2.20130201143900.0a0537f8@resistor.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] #37: spf classic 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, 05 Feb 2013 15:43:57 -0000 On Friday, February 01, 2013 02:40:07 PM SM wrote: > At 19:52 29-08-2012, Scott Kitterman wrote: > >I cleaned it up a bit. > > > > > Section 1.1 requires a clean-up. > > > >Please review the next draft when it's published and provide > >recommendations if you believe additional changes are needed. > > I don't see any mention of "spf classic" in > draft-ietf-spfbis-4408bis-09. I'll suggest closing Issue #37. I've closed this. Scott K From spf2@kitterman.com Tue Feb 5 07:45:25 2013 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 BF94521F8716 for ; Tue, 5 Feb 2013 07:45:25 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AM9Dmj9gZY0 for ; Tue, 5 Feb 2013 07:45:25 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5618721F86EB for ; Tue, 5 Feb 2013 07:45:25 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D8E9620E40D6; Tue, 5 Feb 2013 10:45:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360079124; bh=YpDn0hSHmsUQCuXhOfAtobzWgTsTB3N7ttcMvr4zS8Y=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SDnH8VCPNXQ8+x2kvnEPLp/g79+lhVq5UZPEBbJCUBosZ81HOZNajsBhCxc2y4R4q AbD3KKTtfnrW5ywL59jotMrYFgUm6H/BJz6xORzZ4slyZWKn9u1Si7FsO3ehJ67ZxY mgDbYcDxVvAgc90Tgm1sTz0siCOIDUzH7G2jYcrE= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BC5AF20E40B2; Tue, 5 Feb 2013 10:45:24 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 10:45:23 -0500 Message-ID: <4566886.KSJvzryDKE@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130201143305.0a1d5fb0@resistor.net> References: <064.27d993b3cb7210e6425eb39657584b46@tools.ietf.org> <6.2.5.6.2.20130201143305.0a1d5fb0@resistor.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] #57: x-* fields in 4408bis 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, 05 Feb 2013 15:45:25 -0000 On Friday, February 01, 2013 02:36:47 PM S Moonesamy wrote: > At 15:19 06-09-2012, Scott Kitterman wrote: > >I removed the "X dash" before the initial working group draft based > >on based on that BCP. Since they are by definition non-standard, I > >don't think it's got any interoperability implications. > > Scott Kitterman made the above changes last year. To start the > discussion, I'll suggest that Issue #57 be closed. Closed. Scott K From spf2@kitterman.com Tue Feb 5 08:06:21 2013 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 6317F21F892E for ; Tue, 5 Feb 2013 08:06:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7D-3WUzAUcS for ; Tue, 5 Feb 2013 08:06:21 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 983D221F88ED for ; Tue, 5 Feb 2013 08:06:20 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8EE5620E40D6; Tue, 5 Feb 2013 11:06:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360080376; bh=bdMCmsBmS8eaKIVz3+vjmMyk0OBQg60k71eqMtRCqj0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hLgjmLj98uLeEqzHoM3jwGLyW/OzbbA5QX3uD4tvb/RJq/1oe87KodTJ3B1K0HgrK +8JusNnmfoQhKZSd4gc7/eCROFhlQeYZV6tvRe/H5FZQ/Znrjz9b1S1aJwoZNGu+Sn 1mKRk0c6ceI/rFRAF4TK5AvRrCQUdHmFvn8evH1Y= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 671AC20E40B2; Tue, 5 Feb 2013 11:06:16 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 11:06:14 -0500 Message-ID: <1578854.VyNH6jkY9q@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 05 Feb 2013 16:06:21 -0000 On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote: > #22 RFC 4408: Section 2.5.7 PermError on invalid domains after macro > expansion > > #29 RFC 4408: Section 2.5.4 - mark on fail > > #34 Throw a temperror - Section 5.2 > > #35 authorized_spf domain name - Section 9.1.1 Closed these as they were fixed in earlier drafts. Scott K From spf2@kitterman.com Tue Feb 5 08:08:00 2013 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 5173621F88FC for ; Tue, 5 Feb 2013 08:08:00 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e5H3y9b5RGS for ; Tue, 5 Feb 2013 08:07:59 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A5A7021F88B2 for ; Tue, 5 Feb 2013 08:07:59 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 330E220E40D6; Tue, 5 Feb 2013 11:07:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360080479; bh=+PmvO0nvhIarSuzedJUoIug1v8lob81h9VqypI0L9eo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gAJsGHhharvwcRC8bCEBwYPYazWslSW/9TcPUMZPpF7XmucCYaYy37Wl2cAua/ZR4 QFau6BX2ChNimBmYb4X2XIWX5cYhOpOTZIXuHEUWtcmKDFBR/nlVNgIQbeeWp1kiuv 10HQ9nbSej6CkFweWfJu9rdh0nBZ4Zs7Pq8SENVM= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0A70320E40B2; Tue, 5 Feb 2013 11:07:58 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 11:07:57 -0500 Message-ID: <1669628.jrorNbgmGu@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 05 Feb 2013 16:08:00 -0000 On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote: > #36 RFC 2119 key words I went back through and tried to address this before the reorg. I would appreciate (using the 4408 -> 08 diff I posted) if someone would review this item. The text of the issue is: > Overall, when RFC 4408 was drafted, care was taken to capitalize RFC 2119 > keywords, and use the lower case words as regular English meaning. While > most of the lower case words have been changed to synonyms, a few have been > changed into RFC 2119 keywords. I think most (but sadly, not all) of these > capitalizations are wrong. Scott K From hsantos@isdg.net Tue Feb 5 08:55:12 2013 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 D3BB121F88B4 for ; Tue, 5 Feb 2013 08:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.118 X-Spam-Level: X-Spam-Status: No, score=-102.118 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoqC0nqcqOio for ; Tue, 5 Feb 2013 08:55:10 -0800 (PST) Received: from dkim.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 88DE121F86E7 for ; Tue, 5 Feb 2013 08:55:06 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4709; t=1360083288; h=Received:Received: Message-ID:From:To:Subject:Date:Organization:List-ID; bh=yuzqwQ+ 2qadRj9hzB8Mer/zbKoA=; b=n/jzoTzEbmu+ts/Ty5HlBEIBFFw1ssG2eqCHbB6 cFTfU4jH2+YPyFu6T6mMQtAU7Rf2NFyiLzgJmnhDO2NfcychR6VVMkExq2iz0K1g CrWIXQPl/HqdsVwIw3qucMVUxQ3agT6r+Q63mTcrRmr5S9P9b6AUkqQQ7vYE8hHK WT/Y= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 05 Feb 2013 11:54:48 -0500 Received: from main2 ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3220020629.24643.1408; Tue, 05 Feb 2013 11:54:48 -0500 Message-ID: From: "Hector Santos" To: "Scott Kitterman" , References: <1440164.CoAgXWpN1C@scott-latitude-e6320><20130116121209.GD41685@verdi> <1439058.EEqD6QKl4d@scott-latitude-e6320> Date: Tue, 5 Feb 2013 11:53:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was Re: Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 16:55:12 -0000 I am ok with MK's text except for the 2nd paragraph. I think a simple = remove is OK since I think the spec is precisely about establishing a = client/server protocol which inherently includes a sender and receiver = policy framework. =20 Ultimately, please do not weaken the -ALL policy, industry wide from = small to large, from low to high value domains have comes to expect to = mean one thing - they are the exclusive mail handlers (senders) and any = deviation from the mail delivery behavior as detected by the SPF = protocol supportive receiver is a very deterministic security condition = for rejection. It has nothing to do with what a receiver will ultimately = do but a good SPEC simply need to lay out the design options one can = follow to handle both the backend automation and any possible ergonomic = UI design necessary.=20 I personally consider this as a normal project management practice = product liability issues that do include the legal considerations that = are possible for malpractice and/or tort, i.e. allowing a -ALL failed = transaction to be passed to users as an inherent legal risk. I am not = suggesting that the BIS consider this realistic thoughts, but the BIS = design will be fundamental in allowing it to be done probably without = all the subjective opinions. -- HLS ----- Original Message -----=20 From: "Scott Kitterman" To: Sent: Tuesday, February 05, 2013 10:17 AM Subject: [spfbis] Delivering Mail Producing a 'Fail' Result - was Re: = Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt > On Wednesday, January 16, 2013 03:06:05 PM Murray S. Kucherawy wrote: >> Operators are ultimately the ones that implement local policy, so I = think >> it's reasonable to place the focus there. It's unlikely that end = users >> will read this and/or try to understand it. That said, I don't have = a >> problem with the alternative text proposed by John. >>=20 >> I think the point in the last paragraph of the proposed 11.7 needs to >> remain, however. >=20 > I'm working through issues for the next revision and this is one of = them. >=20 > I think we should stick with Murray's originally proposed text for = this new=20 > security consideration: >=20 >> Operators that choose to deliver mail for which SPF produces a = "fail" >> result need to understand that they are admitting content that is >> explicitly not authorized by the purported sender. While there = are >> known failure modes that can be considered "false negatives", the >> distincg choice to admit those messages increases end-user = exposure >> to likely harm. This is especially true for domains belonging to >> known good actors that are typically well-behaved; unauthorized = mail >> from those sources might well be subjected to much higher = skepticism >> and content analysis. >> =20 >> SPF does not, however, include the capacity for identifying good >> actors from bad ones, nor does it handle the concept of known = actors >> versus unknown ones. Those notions are out of scope for this >> specification. >=20 > Here's John Leslie's proposed alternative: >=20 > " Many operators have found that email for which SPF produces a "fail" > " result is nonetheless email which end-users depend upon receiving, > " and deliver it despite the "fail" result. This practice is = permitted. > " There are things the end-user can do which will distinguish SPF > " "fail" email which they do want from SPF "fail" email they don't > " want. > "=20 > " Nonetheless, there are SPF publishers that really want an SPF "fail" > " to prevent delivery. SPF does not and cannot promise that. However, > " both operators and end-users should clearly understand that most > " SPF "fail" emails deserve to be rejected, and a significant number > " of them can cause harm. SPF "fail" emails from senders which are > " typically well-behaved probably deserve much higher skepticism > " and automated content-analysis. >=20 > I prefer the original language (and will use it unless I get = overruled). I=20 > think that the proposed alternative reads less like a security = consideration. =20 > Additionally, I don't like putting things in terms of permitted = practice. =20 > We've tried to minimize receiver policy for reasons that aren't worth = re- > hashing and so talking about practices permitted for the receiver is a = bit out=20 > of step with what we're trying to communicate overall. >=20 > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From spf2@kitterman.com Tue Feb 5 09:06:30 2013 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 AEEB121F8941 for ; Tue, 5 Feb 2013 09:06:30 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCVgpBWW4RuO for ; Tue, 5 Feb 2013 09:06:30 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 123AA21F8880 for ; Tue, 5 Feb 2013 09:06:30 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8425B20E40D6; Tue, 5 Feb 2013 12:06:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360083989; bh=y9qjQ5oNNQllPlNu905iws4VYdXD7awkkZTmx7slggs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kttoa2zM1m5zudOhz/jbij6gwsnlB7Lms7XxC0blZtOVKsMErPD2VHf4nNpfNdY7n EWQ8E+BVb9DJl7e+iTm4HJs7KTMfCpry+219EClS7qJyZ+nC29g0MEqNacIczg7McN Y5JQbGcIXGDkOgRnK+8ZtQfgbmAQNuYYmAsHmIDE= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5ACD020E40B2; Tue, 5 Feb 2013 12:06:20 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 12:06:18 -0500 Message-ID: <18382376.hIpMDkXD4i@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 05 Feb 2013 17:06:30 -0000 On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote: > #43 New requirement for mx: or ptr records Issue: > in section 4.6.4, there is a new requirement that there must not be more > than 10 records for mx: or ptr:. This completely wrong for ptr: because a > spammer could choose to send spam from a host with more than 10 PTR > records, thus forcing a domain's SPF record to return permerror, instead of > fail. If anything, more than 10 PTR records should cause the ptr: mechanism > to automatically not-match. It should also be made clear that the %{p} > macro is valid no matter how many PTR records are returned. Proposed new text for 4.6.4 (in my local copy): > 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. If more than 10 "mx" records are returned for this > further lookup, a permerror MUST be returned. If more than 10 "ptr" > records are returned for this further lookup (either due to use of > a "ptr" mechanisms, or the %{p} macro) processing MUST be terminated > after 10 records. This limit is per mechanism or macro in the > record and in addition to the lookup limits above. Comments please. If no one objects, I'll include it. Scott K From spf2@kitterman.com Tue Feb 5 09:30:13 2013 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 AFF6621F8A1D for ; Tue, 5 Feb 2013 09:30:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR8Z51hDxpv1 for ; Tue, 5 Feb 2013 09:30:07 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8A74D21F89A4 for ; Tue, 5 Feb 2013 09:30:07 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 18BBE20E40D6; Tue, 5 Feb 2013 12:30:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360085407; bh=Rb2SHbXwduzB0aDXEQgvZbOy2W0H94V75+ggfXpRScI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=n5O7nHCcrpYNTmYlPYaWbrZ1o+0Mo9pPPYudzYyFh7VznU7tqN8TBtzBynNumo4NL Z8/2NHzkjD3T13yaIXKjyt8s14e/flGeUNVrP3kVtbXVR/FeI2gCzrQ8DvvXwWSZGH LkCRQ2drwqtWV9vZmjGr+VUeTXGpojTL1nLKkSJc= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EA32220E40B2; Tue, 5 Feb 2013 12:30:06 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 12:30:05 -0500 Message-ID: <2045033.dBgdao1sTi@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <1439058.EEqD6QKl4d@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] Delivering Mail Producing a 'Fail' Result - was Re: Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 17:30:13 -0000 On Tuesday, February 05, 2013 11:53:20 AM Hector Santos wrote: > I am ok with MK's text except for the 2nd paragraph. I think a simple > remove is OK since I think the spec is precisely about establishing a > client/server protocol which inherently includes a sender and receiver > policy framework. While the second paragraph may be sufficiently obvious to members of the working group, I think for a naive reader of the spec, it's an important thing to communicate. I'd prefer to leave it. Scott K From dotzero@gmail.com Tue Feb 5 09:38:07 2013 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 9FBC321F859B for ; Tue, 5 Feb 2013 09:38:07 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CyUlZATPL6c for ; Tue, 5 Feb 2013 09:38:07 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9E80E21F8599 for ; Tue, 5 Feb 2013 09:38:06 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id gg6so444524lbb.27 for ; Tue, 05 Feb 2013 09:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UeeyZ5hRfCKNX3TqJDdyTDnuJmhTsjcigHJ0X03GEsQ=; b=hzq0aO1muz6Ct7h9cfi3w/HuYSmiVFVlCU5W5T7muy4zRS2Pud1V030VL/sKvfPBlk ebkjcozlcRzcJCfZNm7VuCZcrUpvbRC0kq4+8feLHWg9Ve2ZpRrACBqi2GpXa/UVjTHh IF/6IqtkWdbIe90R7D5RsN0RXT+h9VY5EQfr/dqg+44ELcr8d/1Z7/DPoED2hHZHLKWd 2HBU46CAP4MjfuT3VULlM96Y8fhp1Q3h6sJmK3jYb1gaixzVRISPTC4Pf3/stnoKx/ZM PYEBWecYucNtfN4HU20uDwuQblZ/JZ/wXdQJd6fbgvi0CPpqv+bcyzO9S7Glt/pJRIOv 9ebQ== MIME-Version: 1.0 X-Received: by 10.152.144.202 with SMTP id so10mr24004992lab.9.1360085885488; Tue, 05 Feb 2013 09:38:05 -0800 (PST) Received: by 10.112.180.105 with HTTP; Tue, 5 Feb 2013 09:38:05 -0800 (PST) In-Reply-To: <2045033.dBgdao1sTi@scott-latitude-e6320> References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <1439058.EEqD6QKl4d@scott-latitude-e6320> <2045033.dBgdao1sTi@scott-latitude-e6320> Date: Tue, 5 Feb 2013 12:38:05 -0500 Message-ID: From: Dotzero To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was Re: Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 17:38:07 -0000 +1 to Scott's comment about leaving the second paragraph in. On Tue, Feb 5, 2013 at 12:30 PM, Scott Kitterman wrote: > On Tuesday, February 05, 2013 11:53:20 AM Hector Santos wrote: >> I am ok with MK's text except for the 2nd paragraph. I think a simple >> remove is OK since I think the spec is precisely about establishing a >> client/server protocol which inherently includes a sender and receiver >> policy framework. > > While the second paragraph may be sufficiently obvious to members of the working > group, I think for a naive reader of the spec, it's an important thing to > communicate. I'd prefer to leave it. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Tue Feb 5 10:00:51 2013 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 BD09821F88E3 for ; Tue, 5 Feb 2013 10:00: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QptV4qs4+8Ii for ; Tue, 5 Feb 2013 10:00:50 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 811AA21F88E6 for ; Tue, 5 Feb 2013 10:00:50 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EE91520E40D6; Tue, 5 Feb 2013 13:00:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360087250; bh=v93JmFdMeOtnAauKHICo2bDV07udf4xYrcfQDTYSD7Q=; h=From:To:Subject:Date:From; b=dD9JK/0Cdlo0BbWgbH7YsRR8xTW1zfS+CTji9QcyrgRy5So1pD/IXNaqGkrnNC2rt dcdOKo1Uoc2YBmGFNvcOc4X+IHw+pm/MNFRb5eGzRkT6Y/ij9xh8iVMmYnhrlEnQ7r RzD7TSywWvky9YER48K3dolw4TG92V4GM1bWj8Vw= Received: from scott-latitude-e6320.localnet (unknown [66.39.207.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C8CDC20E40B2; Tue, 5 Feb 2013 13:00:49 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 13:00:47 -0500 Message-ID: <18634195.xKHCPc4tqs@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Ticket #47 domain-spec 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, 05 Feb 2013 18:00:51 -0000 I think this needs discussion before I include one of the two proposed=20= solutions in a draft. http://trac.tools.ietf.org/wg/spfbis/trac/ticket/47 Suggested text: bis-06: The domain-spec is expanded as per Section 8. The resulting domain = name is=20 used for a DNS A RR lookup. If any A record is returned, this mechanism= =20 matches. The lookup type is A even when the connection type is IPv6. new: The domain-spec is expanded as per Section 8. The resulting domain = name is=20 used for a DNS A RR lookup (even when the connection type is IPv6). If = any A=20 record is returned, this mechanism matches, otherwise the mechanism doe= sn't=20 match. or new: The domain-spec is expanded as per Section 8. The resulting domain = name is=20 used for a DNS A RR lookup (even when the connection type is IPv6). If = any A=20 record is returned, this mechanism matches. In all other cases (no A re= cords,=20 DNS error, etc.), the mechanism doesn't match. =E2=80=8Bhttp://www.ietf.org/mail-archive/web/spfbis/current/msg02371.h= tml As I read it the second alternative specifies that a DNS error is treat= ed as a=20 no match, but the first does not. I believe we want the first as we do= n't want=20 to hide DNS failures, but I'm not sure. Scott K From john@jlc.net Tue Feb 5 11:28:34 2013 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 1013321F8697 for ; Tue, 5 Feb 2013 11:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.854 X-Spam-Level: X-Spam-Status: No, score=-105.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1FMat0vNKjX for ; Tue, 5 Feb 2013 11:28:33 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 486A321F8753 for ; Tue, 5 Feb 2013 11:28:33 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 79FF533C2A; Tue, 5 Feb 2013 14:28:33 -0500 (EST) Date: Tue, 5 Feb 2013 14:28:33 -0500 From: John Leslie To: Scott Kitterman Message-ID: <20130205192833.GA11629@verdi> References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <20130116121209.GD41685@verdi> <1439058.EEqD6QKl4d@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1439058.EEqD6QKl4d@scott-latitude-e6320> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was Re: Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 19:28:34 -0000 Scott Kitterman wrote: > > I think we should stick with Murray's originally proposed text for this new > security consideration: > >> Operators that choose to deliver mail for which SPF produces a "fail" >> result need to understand that they are admitting content that is >> explicitly not authorized by the purported sender. While there are >> known failure modes that can be considered "false negatives", the >> distincg choice to admit those messages increases end-user exposure >> to likely harm. This is especially true for domains belonging to >> known good actors that are typically well-behaved; unauthorized mail >> from those sources might well be subjected to much higher skepticism >> and content analysis. >> >> SPF does not, however, include the capacity for identifying good >> actors from bad ones, nor does it handle the concept of known actors >> versus unknown ones. Those notions are out of scope for this >> specification. > > Here's John Leslie's proposed alternative: > >" Many operators have found that email for which SPF produces a "fail" >" result is nonetheless email which end-users depend upon receiving, >" and deliver it despite the "fail" result. This practice is permitted. >" There are things the end-user can do which will distinguish SPF >" "fail" email which they do want from SPF "fail" email they don't >" want. >" >" Nonetheless, there are SPF publishers that really want an SPF "fail" >" to prevent delivery. SPF does not and cannot promise that. However, >" both operators and end-users should clearly understand that most >" SPF "fail" emails deserve to be rejected, and a significant number >" of them can cause harm. SPF "fail" emails from senders which are >" typically well-behaved probably deserve much higher skepticism >" and automated content-analysis. > > I prefer the original language (and will use it unless I get overruled). Hmmm... Scott is a Document Editor: he should suggest text, not demand that WGCs call a consensus... > I think that the proposed alternative reads less like a security > consideration. Fine: I really don't care how it's wordsmithed. > Additionally, I don't like putting things in terms of permitted > practice. I really don't care if "permitted" is wordsmithed out. > We've tried to minimize receiver policy for reasons that aren't > worth re-hashing and so talking about practices permitted for the > receiver is a bit out of step with what we're trying to communicate > overall. IMHO, delivering SPF "fail" email with appropriate headers _is_ permitted, no matter how much some of us dislike it. Regardless, it is _done_ and will continue to be done -- because end-users demand it. I think it important to say that SPF _cannot_ promise non-delivery of email that receives an SPF "fail"; and it is not helpful to "blame" service providers who do so. -- John Leslie From ajs@anvilwalrusden.com Tue Feb 5 11:43:19 2013 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 4DEE521F87BB for ; Tue, 5 Feb 2013 11:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIjeK5yvQgaA for ; Tue, 5 Feb 2013 11:43:18 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id BDA2A21F84F2 for ; Tue, 5 Feb 2013 11:43:18 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B1FB18A031 for ; Tue, 5 Feb 2013 19:43:17 +0000 (UTC) Date: Tue, 5 Feb 2013 14:43:16 -0500 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130205194315.GI27306@mx1.yitter.info> References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <20130116121209.GD41685@verdi> <1439058.EEqD6QKl4d@scott-latitude-e6320> <20130205192833.GA11629@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130205192833.GA11629@verdi> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was Re: Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 19:43:19 -0000 On Tue, Feb 05, 2013 at 02:28:33PM -0500, John Leslie wrote: > Scott Kitterman wrote: > > I prefer the original language (and will use it unless I get overruled). > > Hmmm... Scott is a Document Editor: he should suggest text, not > demand that WGCs call a consensus... As chair, FWIW, I did not read Scott's message as demanding a consensus call. He expressed a strong preference for one version, and said that was what he was going to do but left open the possibility that the WG could tell him otherwise. I think this is fine. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Tue Feb 5 11:52:47 2013 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 CBA9E21F862A for ; Tue, 5 Feb 2013 11:52:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVOkwt8kSHnt for ; Tue, 5 Feb 2013 11:52:46 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EC50721F8430 for ; Tue, 5 Feb 2013 11:52:44 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 469FD20E40D6; Tue, 5 Feb 2013 14:52:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360093964; bh=l/bZy80ge97tAx66M2NwkGQ989gRmBhHdoXslL1rfEc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FniAQ98bjNgRQVtdaqXqKKtgWqf2uLqFbDUgIah0arLXFUYkz1GSV7+cC1XxWV5cf 5cds00bymPS9Qclh236P97bWs0FVg/xk/R6W7M4d9tM8UtmCKpG4qLI7iWngGh7iis BNZ4CejHid7o0iB05tdSpjurkr3f6AhIhY3aueyI= Received: from scott-latitude-e6320.localnet (93.sub-70-195-1.myvzw.com [70.195.1.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 15C2920E40B2; Tue, 5 Feb 2013 14:52:43 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 14:52:36 -0500 Message-ID: <2767281.ojtCsoQIih@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <20130205192833.GA11629@verdi> References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <1439058.EEqD6QKl4d@scott-latitude-e6320> <20130205192833.GA11629@verdi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was Re: Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 19:52:47 -0000 On Tuesday, February 05, 2013 02:28:33 PM John Leslie wrote: > Scott Kitterman wrote: > > I think we should stick with Murray's originally proposed text for this > > new > > > > security consideration: > >> Operators that choose to deliver mail for which SPF produces a "fail" > >> result need to understand that they are admitting content that is > >> explicitly not authorized by the purported sender. While there are > >> known failure modes that can be considered "false negatives", the > >> distincg choice to admit those messages increases end-user exposure > >> to likely harm. This is especially true for domains belonging to > >> known good actors that are typically well-behaved; unauthorized mail > >> from those sources might well be subjected to much higher skepticism > >> and content analysis. > >> > >> SPF does not, however, include the capacity for identifying good > >> actors from bad ones, nor does it handle the concept of known actors > >> versus unknown ones. Those notions are out of scope for this > >> specification. > > > > Here's John Leslie's proposed alternative: > >" Many operators have found that email for which SPF produces a "fail" > >" result is nonetheless email which end-users depend upon receiving, > >" and deliver it despite the "fail" result. This practice is permitted. > >" There are things the end-user can do which will distinguish SPF > >" "fail" email which they do want from SPF "fail" email they don't > >" want. > >" > >" Nonetheless, there are SPF publishers that really want an SPF "fail" > >" to prevent delivery. SPF does not and cannot promise that. However, > >" both operators and end-users should clearly understand that most > >" SPF "fail" emails deserve to be rejected, and a significant number > >" of them can cause harm. SPF "fail" emails from senders which are > >" typically well-behaved probably deserve much higher skepticism > >" and automated content-analysis. > > > > I prefer the original language (and will use it unless I get overruled). > > Hmmm... Scott is a Document Editor: he should suggest text, not > demand that WGCs call a consensus... I didn't mean this as a consensus call. I have an opinion and I'm curious what other people think. I know I don't ask for a consensus call nor do I get to judge if rough consensus or not. I don't think that means I'm obligated to work in a vacuum. > > I think that the proposed alternative reads less like a security > > consideration. > > Fine: I really don't care how it's wordsmithed. > > > Additionally, I don't like putting things in terms of permitted > > practice. > > I really don't care if "permitted" is wordsmithed out. > > > We've tried to minimize receiver policy for reasons that aren't > > worth re-hashing and so talking about practices permitted for the > > receiver is a bit out of step with what we're trying to communicate > > overall. > > IMHO, delivering SPF "fail" email with appropriate headers _is_ > permitted, no matter how much some of us dislike it. Regardless, it > is _done_ and will continue to be done -- because end-users demand > it. > > I think it important to say that SPF _cannot_ promise non-delivery > of email that receives an SPF "fail"; and it is not helpful to "blame" > service providers who do so. I know it's permitted, but I don't see value saying so in this consideration. I think it's reasonably clear that SPF cannot promise non-delivery for fail mail. Security is about risk versus benefit. Many operators see the risks over rejecting on fail as outweighed by the benefits. The new security consideration only points out that there are risks related to not rejecting (which is what I think a security consideration should do). I don't think it blames anyone for anything. Operators are responsible for the choices they make and this is an area where we can't provide a universal solution. Scott K From hsantos@isdg.net Tue Feb 5 12:08:19 2013 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 2974921F86EA for ; Tue, 5 Feb 2013 12:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.818 X-Spam-Level: X-Spam-Status: No, score=-101.818 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxSptsllxmQh for ; Tue, 5 Feb 2013 12:08:18 -0800 (PST) Received: from ftp.catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 16F0A21F86E1 for ; Tue, 5 Feb 2013 12:08:17 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2409; t=1360094891; h=Received:Received: Message-ID:From:To:Subject:Date:Organization:List-ID; bh=yRXXOF/ W8J7fdU4IQoJh7h6pt3c=; b=OrXTH/bqb+ue4nVESktrHT+WYK+7pNE6P7/NiT1 lOaN2TkwSlzCbGYcdzu41NBvpMnJJEilw+9v5ykXiMpFQdLCWbJoCru6mk6KVp3T T6CHiSuSk4L0MPYjuL7BMSDERSpQKYI5qLHY5Zhhxmg3s73Efo4s0f/vQKBCZQIl qWPQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 05 Feb 2013 15:08:11 -0500 Received: from main2 ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3231623250.24643.4012; Tue, 05 Feb 2013 15:08:10 -0500 Message-ID: From: "Hector Santos" To: "Scott Kitterman" , References: <1440164.CoAgXWpN1C@scott-latitude-e6320><1439058.EEqD6QKl4d@scott-latitude-e6320> <2045033.dBgdao1sTi@scott-latitude-e6320> Date: Tue, 5 Feb 2013 15:06:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was Re:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 20:08:19 -0000 I don't believe the 2nd paragraph is correct, technically or logically. = It provides a falsehood about the SPF protocol, a sense of wasted = purpose to support or publish -ALL which is not a figment of our = imaginations - its in HIGH USE and there are two basic protocol actions: REJECT=20 MARK (can be symnonous to separation) For many people, even the naive, that can be very clear and precise for = naive administrators and/or naive developers. What you are doing, and I am highly concern with, is the idea with the = "naive" market (whatever that means, different audidence of BIS = readers?) doesn't have to do anything in being a fully compliant SPF = Receiver. This will water down the -ALL policy, the confidence in its usage of = what is expected by receivers to FILTER. What you (the text) is saying: Forget all that, its out of scope. What is in scope is=20 to REPORT the result and if you don't want to do anything with it, = thats also, IN SCOPE. =20 Very confusing and ultimately, in my view, a SPF-KILLER. It will lower = the incentive to support SPF. It hurts SPF. I say that because we saw = it happen with DKIM when POLICY was watered down (deemed out of scope) = and removed. That is essentially what is going on here and I am very = concern about it. I can't support a BIS that marginalizes the -ALL = policy in any way, shape or form. -- HLS ----- Original Message -----=20 From: "Scott Kitterman" To: Sent: Tuesday, February 05, 2013 12:30 PM Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was = Re:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt > On Tuesday, February 05, 2013 11:53:20 AM Hector Santos wrote: >> I am ok with MK's text except for the 2nd paragraph. I think a = simple >> remove is OK since I think the spec is precisely about establishing a >> client/server protocol which inherently includes a sender and = receiver >> policy framework. =20 >=20 > While the second paragraph may be sufficiently obvious to members of = the working=20 > group, I think for a naive reader of the spec, it's an important thing = to=20 > communicate. I'd prefer to leave it. >=20 > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From spf2@kitterman.com Tue Feb 5 12:15:31 2013 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 ADD3921F881C for ; Tue, 5 Feb 2013 12:15:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mecNB+gsejqT for ; Tue, 5 Feb 2013 12:15:14 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A906121F8645 for ; Tue, 5 Feb 2013 12:15:14 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 331AD20E40D6; Tue, 5 Feb 2013 15:15:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360095314; bh=RRCceQqNNNUHJfXMUpRjF7H3dr7PG9cnGkKGxUe9GqM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fcJBHAKSR2yV63QjsTReVezsySirx3K6aL8Dpu0BK5kM261V1R9k6TjcMB03p5aI4 xHQNmFkM9gPRzeLAQ44pq8TSzABRCtqSjgv52xV4tZqMkojfhrBLGU2ZmIV+O7fO8E rUbMmwGpC9OgvxmHHOcHNz9Fm5WHXVBhJDkT1ZH0= Received: from scott-latitude-e6320.localnet (93.sub-70-195-1.myvzw.com [70.195.1.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 04C1A20E40B2; Tue, 5 Feb 2013 15:15:13 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 15:15:12 -0500 Message-ID: <5865342.GP9k02oU8y@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <2045033.dBgdao1sTi@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] Delivering Mail Producing a 'Fail' Result - was Re:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 20:15:31 -0000 Please give me the section number of RFC 4408 where it defines how SPF determines good actors from bad ones? If you can find that, we might have something to discuss. Scott K On Tuesday, February 05, 2013 03:06:43 PM Hector Santos wrote: > I don't believe the 2nd paragraph is correct, technically or logically. It > provides a falsehood about the SPF protocol, a sense of wasted purpose to > support or publish -ALL which is not a figment of our imaginations - its in > HIGH USE and there are two basic protocol actions: > > REJECT > MARK (can be symnonous to separation) > > For many people, even the naive, that can be very clear and precise for > naive administrators and/or naive developers. > > What you are doing, and I am highly concern with, is the idea with the > "naive" market (whatever that means, different audidence of BIS readers?) > doesn't have to do anything in being a fully compliant SPF Receiver. > > This will water down the -ALL policy, the confidence in its usage of what is > expected by receivers to FILTER. > > What you (the text) is saying: > > Forget all that, its out of scope. What is in scope is > to REPORT the result and if you don't want to do anything with it, > thats also, IN SCOPE. > > Very confusing and ultimately, in my view, a SPF-KILLER. It will lower the > incentive to support SPF. It hurts SPF. I say that because we saw it > happen with DKIM when POLICY was watered down (deemed out of scope) and > removed. That is essentially what is going on here and I am very concern > about it. I can't support a BIS that marginalizes the -ALL policy in any > way, shape or form. > > -- > HLS > > ----- Original Message ----- > From: "Scott Kitterman" > To: > Sent: Tuesday, February 05, 2013 12:30 PM > Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was > Re:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt > > On Tuesday, February 05, 2013 11:53:20 AM Hector Santos wrote: > >> I am ok with MK's text except for the 2nd paragraph. I think a simple > >> remove is OK since I think the spec is precisely about establishing a > >> client/server protocol which inherently includes a sender and receiver > >> policy framework. > > > > While the second paragraph may be sufficiently obvious to members of the > > working group, I think for a naive reader of the spec, it's an important > > thing to communicate. I'd prefer to leave it. > > > > Scott K > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From hsantos@isdg.net Tue Feb 5 12:45:12 2013 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 E676621F85AB for ; Tue, 5 Feb 2013 12:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHALNNT4Qc5U for ; Tue, 5 Feb 2013 12:45:12 -0800 (PST) Received: from mail.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D0E3021F853D for ; Tue, 5 Feb 2013 12:45:11 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5330; t=1360097107; h=Received:Received: Message-ID:From:To:Subject:Date:Organization:List-ID; bh=rwCpfA3 Hs/UHvRZLvlAyEULJ3Js=; b=B3OPCHp4HAxQ4VOma0a4X0ydHuwLHEygIfDJISO hspdE2AxPaJWFvm/QOYq5ckQh2lw/+xxGLfI9bQqbC8SV9ueefV775FpodLfMWtc oqgwH7/p1Wi5ugeShm62EKzmZFReJJa4XnH021uyE8zGLVw52GOi80hnoJnM3mtA HZag= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 05 Feb 2013 15:45:07 -0500 Received: from main2 ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3233839385.24643.3356; Tue, 05 Feb 2013 15:45:07 -0500 Message-ID: <5A537618C0C343AC8BB0457FDC6A2001@addom.santronics.com> From: "Hector Santos" To: References: <1440164.CoAgXWpN1C@scott-latitude-e6320><2045033.dBgdao1sTi@scott-latitude-e6320> <5865342.GP9k02oU8y@scott-latitude-e6320> Date: Tue, 5 Feb 2013 15:43:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 20:45:13 -0000 I don't think this is the question to ask and with all due respect, an = unfair one to impose knowing there is no answer to it unless we wish to = begin discussion for the definition of GOOD vs BAD. This is part of the confusion of "Reputation" and "Scoring" being = injected into the protocol - the Message Evaluation Component or Agent = (MEA)** as it being considered, but we need to first change the mindset = to a REPORTING instead of rejection.=20 Good or BAD are inherent terms in SPF, and specifically for -ALL, since = it declares with a high certainty who are "GOOD" or "VALID: senders as = oppose to "BAD" or "WRONG" ones. In fact, I suggest some may even = extend that to a BAD/GOOD Reputation concept, just not the one most are = thinking about using some 3rd party with a combined DKIM component. No, with SPF, the -ALL, and thats all I speak of, thats a deterministic = (On/Off, not Fuzzy) quality, not a heuristic, fuzzy quality althougt = thats not to say it can part of some proprietary secret formula. IMO, it is not out of scope for BIS to discuss -ALL REJECTION or MARKING = technical protocol ideas. Just lay it out - don't suggest it out of = scope thus it can't be discussed. People, especially "naive" ones do = need direction I would think. ** The MEA is implementation specific. We know that, but there is a = GENERAL guideline that SPF needs to lay out - thats part of the scope. = That includes, REJECT or MARKING and even doing nothing, but that goes = for all protocols - to do nothing. It wouldn't make sense to repeat that = here because you can cleanly lay it out as a in-scope logic: REJECT MARK (REPORT) / SEPARATION MARK (REPORT) / DO NOTHING Naive readers will like to know what needs to be done for supporting SPF = from an receiver standpoint and for documenting what an -ALL policy can = offer domains. Thanks ----- Original Message -----=20 From: "Scott Kitterman" To: Sent: Tuesday, February 05, 2013 3:15 PM Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - = wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt > Please give me the section number of RFC 4408 where it defines how SPF = > determines good actors from bad ones? If you can find that, we might = have=20 > something to discuss. >=20 > Scott K >=20 > On Tuesday, February 05, 2013 03:06:43 PM Hector Santos wrote: >> I don't believe the 2nd paragraph is correct, technically or = logically. It >> provides a falsehood about the SPF protocol, a sense of wasted = purpose to >> support or publish -ALL which is not a figment of our imaginations - = its in >> HIGH USE and there are two basic protocol actions: >>=20 >> REJECT >> MARK (can be symnonous to separation) >>=20 >> For many people, even the naive, that can be very clear and precise = for >> naive administrators and/or naive developers. >>=20 >> What you are doing, and I am highly concern with, is the idea with = the >> "naive" market (whatever that means, different audidence of BIS = readers?) >> doesn't have to do anything in being a fully compliant SPF Receiver. >>=20 >> This will water down the -ALL policy, the confidence in its usage of = what is >> expected by receivers to FILTER. >>=20 >> What you (the text) is saying: >>=20 >> Forget all that, its out of scope. What is in scope is >> to REPORT the result and if you don't want to do anything with = it, >> thats also, IN SCOPE. >>=20 >> Very confusing and ultimately, in my view, a SPF-KILLER. It will = lower the >> incentive to support SPF. It hurts SPF. I say that because we saw = it >> happen with DKIM when POLICY was watered down (deemed out of scope) = and >> removed. That is essentially what is going on here and I am very = concern >> about it. I can't support a BIS that marginalizes the -ALL policy in = any >> way, shape or form. >>=20 >> -- >> HLS >>=20 >> ----- Original Message ----- >> From: "Scott Kitterman" >> To: >> Sent: Tuesday, February 05, 2013 12:30 PM >> Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was >> Re:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt >> > On Tuesday, February 05, 2013 11:53:20 AM Hector Santos wrote: >> >> I am ok with MK's text except for the 2nd paragraph. I think a = simple >> >> remove is OK since I think the spec is precisely about = establishing a >> >> client/server protocol which inherently includes a sender and = receiver >> >> policy framework. >> >=20 >> > While the second paragraph may be sufficiently obvious to members = of the >> > working group, I think for a naive reader of the spec, it's an = important >> > thing to communicate. I'd prefer to leave it. >> >=20 >> > Scott K >> > _______________________________________________ >> > spfbis mailing list >> > spfbis@ietf.org >> > https://www.ietf.org/mailman/listinfo/spfbis >>=20 >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From superuser@gmail.com Tue Feb 5 12:45:40 2013 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 E032A21F86F2 for ; Tue, 5 Feb 2013 12:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=1.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcarOuBnUSy1 for ; Tue, 5 Feb 2013 12:45:38 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5F121F85B3 for ; Tue, 5 Feb 2013 12:45:35 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id e12so512435wge.22 for ; Tue, 05 Feb 2013 12:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yRQEqwxRGgvRAxBa6YiGwtuLu/F3+wA2C9/89ygsXds=; b=XCDwruHNHsnYEe1N3ywHFyIcxBXpvW6yoQSGJxMhduOEb9eFfkOUbn5g71ITKimJ7t Ge0xFH0L4DZ0dzcZIndatn07gw95Yb+qgHpiqYLSGpcoRgZpkjndF5JtjF9jSSHaESyZ X2kaxUWX6s78tMEmyG/ffpV0FSl0gL4F2keabx/MkN/qzOvORpq1QbWiiBE2itewZx4T xnAGnbG+zSK/AMDAmdSP3EomSIlvyoYSYo+Tm37VcRXoq1oXTzzxg6Vb86yc8iVhj4gl lzQX9f5/eTFH14t+CFWUE/uDv48gLwyKOcK3XGWFgrlLmpx6UJszS56Yme8QAwTxxIUE a1yg== MIME-Version: 1.0 X-Received: by 10.180.75.110 with SMTP id b14mr747233wiw.21.1360097134762; Tue, 05 Feb 2013 12:45:34 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 12:45:34 -0800 (PST) In-Reply-To: <1443624.jLaNURLjtu@scott-latitude-e6320> References: <20130125143603.GA11573@mx1.yitter.info> <1397680.5mhf1dVE2p@scott-latitude-e6320> <6.2.5.6.2.20130131065211.0a323f48@resistor.net> <1443624.jLaNURLjtu@scott-latitude-e6320> Date: Tue, 5 Feb 2013 12:45:34 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043be22893d97c04d5004aae Cc: "spfbis@ietf.org" Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error 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: Tue, 05 Feb 2013 20:45:41 -0000 --f46d043be22893d97c04d5004aae Content-Type: text/plain; charset=ISO-8859-1 Looks good to me. -MSK On Tue, Feb 5, 2013 at 7:35 AM, Scott Kitterman wrote: > On Thursday, January 31, 2013 06:53:55 AM S Moonesamy wrote: > > Hi Scott, > > > > At 06:22 31-01-2013, Scott Kitterman wrote: > > >I think it will be resolved with the next revision. I think we've > > >discussed it sufficiently. Next week looks to be good for me to take a > > >stab at making progress on the remaining issues. > > > > Thanks for the feedback. > > This is what I've put in my local copy of the to revision 10 (line breaks > are > better in the draft): > > > The published SPF record for a given domain name SHOULD > remain > > small enough that the results of a query for it will fit > within > > 512 octets. This UDP limit is defined in > target="RFC1035"/> > > section 2.3.4. This will keep even older DNS implementations > > from > > falling over to TCP. Since the answer size is dependent on > many > > things outside the scope of this document, it is only > possible > > to > > give this guideline: If the combined length of the DNS name > and > > the text of all the records of a given type is under 450 > octets, > > then DNS answers ought to fit in UDP packets. Records that > are > > too long to fit in a single UDP packet could be silently > ignored > > by SPF > > verifiers due to firewall and other issues that cause DNS > over > > TCP > > to be less reliable than DNS over UDP. > > > > Note that when computing the sizes for replies to queries of > the > > TXT > > format, one has to take into account any other TXT records > > published > > at the domain name. Similarly, the sizes for replies to all > > queries > > related to SPF have to be evaluated to fit in a single UDP > > packet. > > I believe it addresses the specific concern raised without driving into a > lot > of detail about how one operates DNS. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d043be22893d97c04d5004aae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Looks good to me.

-MSK


On Tue, Feb 5, 2013 a= t 7:35 AM, Scott Kitterman <spf2@kitterman.com> wrote:
On Thursday, January 31, 2= 013 06:53:55 AM S Moonesamy wrote:
> Hi Scott,
>
> At 06:22 31-01-2013, Scott Kitterman wrote:
> >I think it will be resolved with the next revision. =A0I think we&= #39;ve
> >discussed it sufficiently. =A0Next week looks to be good for me to= take a
> >stab at making progress on the remaining issues.
>
> Thanks for the feedback.

This is what I've put in my local copy of the to revision 10 (lin= e breaks are
better in the draft):

> =A0 =A0 =A0 =A0 =A0 =A0 The published SPF record for a given domain na= me SHOULD remain
> =A0 =A0 =A0 =A0 =A0 =A0 small enough that the = results of a query for it will fit within
> =A0 =A0 =A0 =A0 =A0 =A0 512 octets. =A0This UDP limit is defined in &l= t;xref
> =A0 =A0 =A0 =A0 =A0 =A0 target=3D"RFC1035"/>
> =A0 =A0 =A0 =A0 =A0 =A0 section 2.3.4. =A0This= will keep even older DNS implementations
> =A0 =A0 =A0 =A0 =A0 =A0 from
> =A0 =A0 =A0 =A0 =A0 =A0 falling over to TCP. =A0Since the answer size = is dependent on many
> =A0 =A0 =A0 =A0 =A0 =A0 things outside the scope of this document, it = is only possible
> =A0 =A0 =A0 =A0 =A0 =A0 to
> =A0 =A0 =A0 =A0 =A0 =A0 give this guideline: If the combined length of= the DNS name and
> =A0 =A0 =A0 =A0 =A0 =A0 the text of all the records of a given t= ype is under 450 octets,
> =A0 =A0 =A0 =A0 =A0 =A0 then DNS answers ought to fit in UDP packets. = =A0Records that are
> =A0 =A0 =A0 =A0 =A0 =A0 too =A0long to fit in a sing= le UDP packet could be silently ignored
> =A0 =A0 =A0 =A0 =A0 =A0 by =A0SPF
> =A0 =A0 =A0 =A0 =A0 =A0 verifiers due to firewall and other issues tha= t cause DNS over
> =A0 =A0 =A0 =A0 =A0 =A0 TCP
> =A0 =A0 =A0 =A0 =A0 =A0 to be less reliable than DNS over UDP.
>
> =A0 =A0 =A0 =A0 =A0 =A0 Note that when computing the sizes for r= eplies to queries of the
> =A0 =A0 =A0 =A0 =A0 =A0 TXT
> =A0 =A0 =A0 =A0 =A0 =A0 format, one has to take into account any other= TXT records
> =A0 =A0 =A0 =A0 =A0 =A0 published
> =A0 =A0 =A0 =A0 =A0 =A0 at the domain name. =A0Similarly, the sizes fo= r replies to all
> =A0 =A0 =A0 =A0 =A0 =A0 queries
> =A0 =A0 =A0 =A0 =A0 =A0 related to SPF have to be evaluated to fit in = a single UDP
> =A0 =A0 =A0 =A0 =A0 =A0 packet.

I believe it addresses the specific concern raised without driving into a l= ot
of detail about how one operates DNS.

Scott K
___________________________________= ____________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--f46d043be22893d97c04d5004aae-- From dotzero@gmail.com Tue Feb 5 12:59:19 2013 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 38EFF21F8654 for ; Tue, 5 Feb 2013 12:59:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZ8y6kq0e1nZ for ; Tue, 5 Feb 2013 12:59:18 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 915A021F8609 for ; Tue, 5 Feb 2013 12:59:17 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id l12so593065lbo.5 for ; Tue, 05 Feb 2013 12:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=IxgS+wPQoVm1abFmvkz7G6g8Fx0ne+B9s7bypxaVDuI=; b=LghtbwASgtp5wVo/NeQvs8EV8eLQOrK/yK230ILR5gIOfzTsY3jPCLsYCJDwRxcj0o cWGcdYcKIqzGe67/BW1H+DokjO7MSr8xLExaR3+gv3wddaUmnQRHU4gf/igkxsM562hc NfZ3PnurDy90mwBSpWuDClM1xHmxRT4WAVNltdSN0j83h0dR1PUhxckhTKlViHw5ZIM1 I7klRws2u7ehZcjS6PjfwP5ryMXSolznFwmtRLS1YyRf4E5n1mCRLUyFLqbs8/+hfGPV esmqudiDxKoXOUXKuSVOzklf66SBFgLkD3itL9LU4+4gK0z3NjZ/DjWC2hcygg/hZYCd k3nA== MIME-Version: 1.0 X-Received: by 10.112.29.201 with SMTP id m9mr10419911lbh.96.1360097956522; Tue, 05 Feb 2013 12:59:16 -0800 (PST) Received: by 10.112.180.105 with HTTP; Tue, 5 Feb 2013 12:59:16 -0800 (PST) In-Reply-To: <5A537618C0C343AC8BB0457FDC6A2001@addom.santronics.com> References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <2045033.dBgdao1sTi@scott-latitude-e6320> <5865342.GP9k02oU8y@scott-latitude-e6320> <5A537618C0C343AC8BB0457FDC6A2001@addom.santronics.com> Date: Tue, 5 Feb 2013 15:59:16 -0500 Message-ID: From: Dotzero To: Hector Santos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 20:59:19 -0000 On Tue, Feb 5, 2013 at 3:43 PM, Hector Santos wrote: > I don't think this is the question to ask and with all due respect, an un= fair one to impose knowing there is no answer to it unless we wish to begin= discussion for the definition of GOOD vs BAD. > GOOD and BAD are irrelevent. Either it validates or it does not. The use of "?", "~", "-" and "+" at the end of an SPF record communicates the strictness of the published record. It tells us about authorization, not goodness or badness. > This is part of the confusion of "Reputation" and "Scoring" being injecte= d into the protocol - the Message Evaluation Component or Agent (MEA)** as = it being considered, but we need to first change the mindset to a REPORTING= instead of rejection. > Not at all. > Good or BAD are inherent terms in SPF, and specifically for -ALL, since i= t declares with a high certainty who are "GOOD" or "VALID: senders as oppos= e to "BAD" or "WRONG" ones. In fact, I suggest some may even extend that t= o a BAD/GOOD Reputation concept, just not the one most are thinking about u= sing some 3rd party with a combined DKIM component. > GOOD and BAD are not inherent terms in SPF much as you would like them to be. VALID is not the same as GOOD. > No, with SPF, the -ALL, and thats all I speak of, thats a deterministic (= On/Off, not Fuzzy) quality, not a heuristic, fuzzy quality althougt thats n= ot to say it can part of some proprietary secret formula. > You would like the reporting option to go away yet there it is in black and white. > IMO, it is not out of scope for BIS to discuss -ALL REJECTION or MARKING = technical protocol ideas. Just lay it out - don't suggest it out of scope = thus it can't be discussed. People, especially "naive" ones do need directi= on I would think. > Hector, there are some things I agree with you on but you have been beating this drum for years without gaining traction. Different mailbox providers (validators) will choose different ways of handling SPF outcomes. To demand that they only do it "your" way (reject) is IMHO quite simply a non-starter. > ** The MEA is implementation specific. We know that, but there is a GENER= AL guideline that SPF needs to lay out - thats part of the scope. That incl= udes, REJECT or MARKING and even doing nothing, but that goes for all proto= cols - to do nothing. It wouldn't make sense to repeat that here because yo= u can cleanly lay it out as a in-scope logic: > > REJECT > MARK (REPORT) / SEPARATION > MARK (REPORT) / DO NOTHING > > Naive readers will like to know what needs to be done for supporting SPF = from an receiver standpoint and for documenting what an -ALL policy can off= er domains. > > Thanks > > ----- Original Message ----- > From: "Scott Kitterman" > To: > Sent: Tuesday, February 05, 2013 3:15 PM > Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - wasRe:F= wd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt > > >> Please give me the section number of RFC 4408 where it defines how SPF >> determines good actors from bad ones? If you can find that, we might ha= ve >> something to discuss. >> >> Scott K >> >> On Tuesday, February 05, 2013 03:06:43 PM Hector Santos wrote: >>> I don't believe the 2nd paragraph is correct, technically or logically.= It >>> provides a falsehood about the SPF protocol, a sense of wasted purpose = to >>> support or publish -ALL which is not a figment of our imaginations - it= s in >>> HIGH USE and there are two basic protocol actions: >>> >>> REJECT >>> MARK (can be symnonous to separation) >>> >>> For many people, even the naive, that can be very clear and precise for >>> naive administrators and/or naive developers. >>> >>> What you are doing, and I am highly concern with, is the idea with the >>> "naive" market (whatever that means, different audidence of BIS readers= ?) >>> doesn't have to do anything in being a fully compliant SPF Receiver. >>> >>> This will water down the -ALL policy, the confidence in its usage of wh= at is >>> expected by receivers to FILTER. >>> >>> What you (the text) is saying: >>> >>> Forget all that, its out of scope. What is in scope is >>> to REPORT the result and if you don't want to do anything with it= , >>> thats also, IN SCOPE. >>> >>> Very confusing and ultimately, in my view, a SPF-KILLER. It will lower = the >>> incentive to support SPF. It hurts SPF. I say that because we saw it >>> happen with DKIM when POLICY was watered down (deemed out of scope) and >>> removed. That is essentially what is going on here and I am very conce= rn >>> about it. I can't support a BIS that marginalizes the -ALL policy in an= y >>> way, shape or form. >>> >>> -- >>> HLS >>> >>> ----- Original Message ----- >>> From: "Scott Kitterman" >>> To: >>> Sent: Tuesday, February 05, 2013 12:30 PM >>> Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was >>> Re:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt >>> > On Tuesday, February 05, 2013 11:53:20 AM Hector Santos wrote: >>> >> I am ok with MK's text except for the 2nd paragraph. I think a simp= le >>> >> remove is OK since I think the spec is precisely about establishing = a >>> >> client/server protocol which inherently includes a sender and receiv= er >>> >> policy framework. >>> > >>> > While the second paragraph may be sufficiently obvious to members of = the >>> > working group, I think for a naive reader of the spec, it's an import= ant >>> > thing to communicate. I'd prefer to leave it. >>> > >>> > Scott K >>> > _______________________________________________ >>> > spfbis mailing list >>> > spfbis@ietf.org >>> > https://www.ietf.org/mailman/listinfo/spfbis >>> >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From hsantos@isdg.net Tue Feb 5 13:19:16 2013 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 2BCD721F868B for ; Tue, 5 Feb 2013 13:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.883 X-Spam-Level: X-Spam-Status: No, score=-101.883 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1Y8G06CA7Hl for ; Tue, 5 Feb 2013 13:19:15 -0800 (PST) Received: from mail.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CC0C221F8688 for ; Tue, 5 Feb 2013 13:19:14 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=8620; t=1360099145; h=Received:Received: Message-ID:From:To:Subject:Date:Organization:List-ID; bh=OsUQCxQ LIYanf/KdLm/oXVjKQWc=; b=GxMb5pm1ykwbJIc0CtYWP3ZIu1B9LCBDDxv+2yg fjPH1yWRpJGEeTP/9hQa4Ut0n4YZiK+qxq4caIj7ks9nVReO/qSnOVkV4YeVSO1N wAb/GGGAESaM6QqiteBKA4Sp8Q62bbDz4c76TFvCZ7xVx+AgBLdPkByBtJ+jccmW gNmQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 05 Feb 2013 16:19:05 -0500 Received: from main2 ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3235876243.24643.2132; Tue, 05 Feb 2013 16:19:03 -0500 Message-ID: <80C559CF24EA462499FF54693F264B85@addom.santronics.com> From: "Hector Santos" To: "Dotzero" References: <1440164.CoAgXWpN1C@scott-latitude-e6320><2045033.dBgdao1sTi@scott-latitude-e6320><5865342.GP9k02oU8y@scott-latitude-e6320><5A537618C0C343AC8BB0457FDC6A2001@addom.santronics.com> Date: Tue, 5 Feb 2013 16:17:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Cc: spfbis@ietf.org Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 21:19:16 -0000 Thats an unfair uncategorization that is not reflective in our product = lines. To suggest I am demanding my way (reject) is also defaming as = well as it is not true. Yes, I am strong advocate for deterministic protocols and what I am = briefing about is a technical specification layout, not a subjective = concept, that is already inherent in the protocol and always was. Of = course, anyone can do whatever they want. But that needs to be laid out = and it usually comes in terms of options provided to the operator to use = (or even program himself). But thats all in-scope, and for -ALL, thats=20 REJECT MARK as it was defined for RFC4408. All I wanted is for MARK to be clearly defined (issue #29) and if it = isn't, then it would be a protocol security loophole. At at minimum, in = my technical view, it is engineering requirement to match the protocol = functionality of two options when its related to security. It is = prudent that this be done. I don't think I am wrong and believe it is appealable to have a market = of -ALL Domains now possibly having a renewed SPFBIS specification = watered down with new implementations (by naive readers as stated as the = target readers). Highly detectable -ALL transactions is no longer the = case with the movement towards reporting. Thats a change, which is = fine, just lay it out very clearly. Its all in scope. I don't wish to see that happen with SPF as it similarily did with DKIM = - wasted DO NOTHING processing for the single exclusive strong policy, = in this case -ALL. ----- Original Message -----=20 From: "Dotzero" To: "Hector Santos" Cc: Sent: Tuesday, February 05, 2013 3:59 PM Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - = wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt > On Tue, Feb 5, 2013 at 3:43 PM, Hector Santos = wrote: >> I don't think this is the question to ask and with all due respect, = an unfair one to impose knowing there is no answer to it unless we wish = to begin discussion for the definition of GOOD vs BAD. >> >=20 > GOOD and BAD are irrelevent. Either it validates or it does not. The > use of "?", "~", "-" and "+" at the end of an SPF record communicates > the strictness of the published record. It tells us about > authorization, not goodness or badness. >=20 >> This is part of the confusion of "Reputation" and "Scoring" being = injected into the protocol - the Message Evaluation Component or Agent = (MEA)** as it being considered, but we need to first change the mindset = to a REPORTING instead of rejection. >> >=20 > Not at all. >=20 >> Good or BAD are inherent terms in SPF, and specifically for -ALL, = since it declares with a high certainty who are "GOOD" or "VALID: = senders as oppose to "BAD" or "WRONG" ones. In fact, I suggest some may = even extend that to a BAD/GOOD Reputation concept, just not the one most = are thinking about using some 3rd party with a combined DKIM component. >> >=20 > GOOD and BAD are not inherent terms in SPF much as you would like them > to be. VALID is not the same as GOOD. >=20 >> No, with SPF, the -ALL, and thats all I speak of, thats a = deterministic (On/Off, not Fuzzy) quality, not a heuristic, fuzzy = quality althougt thats not to say it can part of some proprietary secret = formula. >> >=20 > You would like the reporting option to go away yet there it is in > black and white. >=20 >> IMO, it is not out of scope for BIS to discuss -ALL REJECTION or = MARKING technical protocol ideas. Just lay it out - don't suggest it = out of scope thus it can't be discussed. People, especially "naive" ones = do need direction I would think. >> >=20 > Hector, there are some things I agree with you on but you have been > beating this drum for years without gaining traction. Different > mailbox providers (validators) will choose different ways of handling > SPF outcomes. To demand that they only do it "your" way (reject) is > IMHO quite simply a non-starter. >=20 >> ** The MEA is implementation specific. We know that, but there is a = GENERAL guideline that SPF needs to lay out - thats part of the scope. = That includes, REJECT or MARKING and even doing nothing, but that goes = for all protocols - to do nothing. It wouldn't make sense to repeat that = here because you can cleanly lay it out as a in-scope logic: >> >> REJECT >> MARK (REPORT) / SEPARATION >> MARK (REPORT) / DO NOTHING >> >> Naive readers will like to know what needs to be done for supporting = SPF from an receiver standpoint and for documenting what an -ALL policy = can offer domains. >> >> Thanks >> >> ----- Original Message ----- >> From: "Scott Kitterman" >> To: >> Sent: Tuesday, February 05, 2013 3:15 PM >> Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - = wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt >> >> >>> Please give me the section number of RFC 4408 where it defines how = SPF >>> determines good actors from bad ones? If you can find that, we = might have >>> something to discuss. >>> >>> Scott K >>> >>> On Tuesday, February 05, 2013 03:06:43 PM Hector Santos wrote: >>>> I don't believe the 2nd paragraph is correct, technically or = logically. It >>>> provides a falsehood about the SPF protocol, a sense of wasted = purpose to >>>> support or publish -ALL which is not a figment of our imaginations = - its in >>>> HIGH USE and there are two basic protocol actions: >>>> >>>> REJECT >>>> MARK (can be symnonous to separation) >>>> >>>> For many people, even the naive, that can be very clear and precise = for >>>> naive administrators and/or naive developers. >>>> >>>> What you are doing, and I am highly concern with, is the idea with = the >>>> "naive" market (whatever that means, different audidence of BIS = readers?) >>>> doesn't have to do anything in being a fully compliant SPF = Receiver. >>>> >>>> This will water down the -ALL policy, the confidence in its usage = of what is >>>> expected by receivers to FILTER. >>>> >>>> What you (the text) is saying: >>>> >>>> Forget all that, its out of scope. What is in scope is >>>> to REPORT the result and if you don't want to do anything = with it, >>>> thats also, IN SCOPE. >>>> >>>> Very confusing and ultimately, in my view, a SPF-KILLER. It will = lower the >>>> incentive to support SPF. It hurts SPF. I say that because we saw = it >>>> happen with DKIM when POLICY was watered down (deemed out of scope) = and >>>> removed. That is essentially what is going on here and I am very = concern >>>> about it. I can't support a BIS that marginalizes the -ALL policy = in any >>>> way, shape or form. >>>> >>>> -- >>>> HLS >>>> >>>> ----- Original Message ----- >>>> From: "Scott Kitterman" >>>> To: >>>> Sent: Tuesday, February 05, 2013 12:30 PM >>>> Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - = was >>>> Re:Fwd:New Version Notification for = draft-ietf-spfbis-4408bis-09.txt >>>> > On Tuesday, February 05, 2013 11:53:20 AM Hector Santos wrote: >>>> >> I am ok with MK's text except for the 2nd paragraph. I think a = simple >>>> >> remove is OK since I think the spec is precisely about = establishing a >>>> >> client/server protocol which inherently includes a sender and = receiver >>>> >> policy framework. >>>> > >>>> > While the second paragraph may be sufficiently obvious to members = of the >>>> > working group, I think for a naive reader of the spec, it's an = important >>>> > thing to communicate. I'd prefer to leave it. >>>> > >>>> > Scott K >>>> > _______________________________________________ >>>> > spfbis mailing list >>>> > spfbis@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/spfbis >>>> >>>> _______________________________________________ >>>> spfbis mailing list >>>> spfbis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spfbis >>> _______________________________________________ >>> spfbis mailing list >>> spfbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/spfbis >>> >> >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From spf2@kitterman.com Tue Feb 5 13:20:35 2013 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 29F7F21F86C4 for ; Tue, 5 Feb 2013 13:20:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvRZ3JbedXWz for ; Tue, 5 Feb 2013 13:20:33 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3530421F86A2 for ; Tue, 5 Feb 2013 13:20:33 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7A57F20E40D6; Tue, 5 Feb 2013 16:20:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360099231; bh=hvxgsTToMW3bKLUNRdXAwHmHwLzvwrd4clcLrfAHZA0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MFMEt7yRsq62ATiYI8/4fnFZhGI7guV8zj8UfzmdAZE6kd0C7dI13mAxQqWagnJC5 qAr/rdScDFaAdxv9p9oKpeIV/BhLG0xMr+AqOuhmDCeAUztHghMNyh+AJq8w8lRfSs fBsyyEHd7Ap0qpXkDMNlfroTv9J2+GpXsfpabipU= Received: from scott-latitude-e6320.localnet (93.sub-70-195-1.myvzw.com [70.195.1.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 457DA20E40B2; Tue, 5 Feb 2013 16:20:30 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 16:20:28 -0500 Message-ID: <6185132.ENqHzg2QWR@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <5A537618C0C343AC8BB0457FDC6A2001@addom.santronics.com> References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <5865342.GP9k02oU8y@scott-latitude-e6320> <5A537618C0C343AC8BB0457FDC6A2001@addom.santronics.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 21:20:35 -0000 OK. I think that is all covered in the current draft. Scott K On Tuesday, February 05, 2013 03:43:39 PM Hector Santos wrote: > I don't think this is the question to ask and with all due respect, an > unfair one to impose knowing there is no answer to it unless we wish to > begin discussion for the definition of GOOD vs BAD. > > This is part of the confusion of "Reputation" and "Scoring" being injected > into the protocol - the Message Evaluation Component or Agent (MEA)** as it > being considered, but we need to first change the mindset to a REPORTING > instead of rejection. > > Good or BAD are inherent terms in SPF, and specifically for -ALL, since it > declares with a high certainty who are "GOOD" or "VALID: senders as oppose > to "BAD" or "WRONG" ones. In fact, I suggest some may even extend that to > a BAD/GOOD Reputation concept, just not the one most are thinking about > using some 3rd party with a combined DKIM component. > > No, with SPF, the -ALL, and thats all I speak of, thats a deterministic > (On/Off, not Fuzzy) quality, not a heuristic, fuzzy quality althougt thats > not to say it can part of some proprietary secret formula. > > IMO, it is not out of scope for BIS to discuss -ALL REJECTION or MARKING > technical protocol ideas. Just lay it out - don't suggest it out of scope > thus it can't be discussed. People, especially "naive" ones do need > direction I would think. > > ** The MEA is implementation specific. We know that, but there is a GENERAL > guideline that SPF needs to lay out - thats part of the scope. That > includes, REJECT or MARKING and even doing nothing, but that goes for all > protocols - to do nothing. It wouldn't make sense to repeat that here > because you can cleanly lay it out as a in-scope logic: > > REJECT > MARK (REPORT) / SEPARATION > MARK (REPORT) / DO NOTHING > > Naive readers will like to know what needs to be done for supporting SPF > from an receiver standpoint and for documenting what an -ALL policy can > offer domains. > > Thanks > > ----- Original Message ----- > From: "Scott Kitterman" > To: > Sent: Tuesday, February 05, 2013 3:15 PM > Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - > wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt > > Please give me the section number of RFC 4408 where it defines how SPF > > determines good actors from bad ones? If you can find that, we might have > > something to discuss. > > > > Scott K > > > > On Tuesday, February 05, 2013 03:06:43 PM Hector Santos wrote: > >> I don't believe the 2nd paragraph is correct, technically or logically. > >> It > >> provides a falsehood about the SPF protocol, a sense of wasted purpose to > >> support or publish -ALL which is not a figment of our imaginations - its > >> in > >> > >> HIGH USE and there are two basic protocol actions: > >> REJECT > >> MARK (can be symnonous to separation) > >> > >> For many people, even the naive, that can be very clear and precise for > >> naive administrators and/or naive developers. > >> > >> What you are doing, and I am highly concern with, is the idea with the > >> "naive" market (whatever that means, different audidence of BIS readers?) > >> doesn't have to do anything in being a fully compliant SPF Receiver. > >> > >> This will water down the -ALL policy, the confidence in its usage of what > >> is expected by receivers to FILTER. > >> > >> What you (the text) is saying: > >> Forget all that, its out of scope. What is in scope is > >> to REPORT the result and if you don't want to do anything with it, > >> thats also, IN SCOPE. > >> > >> Very confusing and ultimately, in my view, a SPF-KILLER. It will lower > >> the > >> incentive to support SPF. It hurts SPF. I say that because we saw it > >> happen with DKIM when POLICY was watered down (deemed out of scope) and > >> removed. That is essentially what is going on here and I am very concern > >> about it. I can't support a BIS that marginalizes the -ALL policy in any > >> way, shape or form. > >> > >> -- > >> HLS > >> > >> ----- Original Message ----- > >> From: "Scott Kitterman" > >> To: > >> Sent: Tuesday, February 05, 2013 12:30 PM > >> Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was > >> Re:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt > >> > >> > On Tuesday, February 05, 2013 11:53:20 AM Hector Santos wrote: > >> >> I am ok with MK's text except for the 2nd paragraph. I think a simple > >> >> remove is OK since I think the spec is precisely about establishing a > >> >> client/server protocol which inherently includes a sender and receiver > >> >> policy framework. > >> > > >> > While the second paragraph may be sufficiently obvious to members of > >> > the > >> > working group, I think for a naive reader of the spec, it's an > >> > important > >> > thing to communicate. I'd prefer to leave it. > >> > > >> > Scott K From R.E.Sonneveld@sonnection.nl Tue Feb 5 13:25:45 2013 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 5DE6521F889D for ; Tue, 5 Feb 2013 13:25:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uGNwLviuR+U for ; Tue, 5 Feb 2013 13:25:44 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF8B21F873E for ; Tue, 5 Feb 2013 13:25:42 -0800 (PST) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0MHR00100NIRNV00@helium.mailtransaction.com>; Tue, 05 Feb 2013 22:25:39 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0MHR00L0JNIRMI00@helium.mailtransaction.com>; Tue, 05 Feb 2013 22:25:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id E7D1612305D; Tue, 05 Feb 2013 22:25:38 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QEg8FwqmVwwE; Tue, 05 Feb 2013 22:25:31 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 6640C123039; Tue, 05 Feb 2013 22:25:31 +0100 (CET) Message-id: <511178CB.9080906@sonnection.nl> Date: Tue, 05 Feb 2013 22:25:31 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-version: 1.0 To: Scott Kitterman References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <20130116121209.GD41685@verdi> <1439058.EEqD6QKl4d@scott-latitude-e6320> In-reply-to: <1439058.EEqD6QKl4d@scott-latitude-e6320> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1360099539; bh=pyRlJ8oekrm7L+GXtK+a0I5HiVeFFIihtpGowH5fYkQ=; h=Message-id:Date:From:Reply-to:MIME-version:To:Cc:Subject: References:In-reply-to:Content-type:Content-transfer-encoding; b=SuTTLcj8Z88aQE7KYJka3U8m1uC5WPRpxUeoewGgPcXgch+Vztvo0G7KPyhqd0Jh5 jIOdufAUvo4wTwPA746jCbtYGH99gi+vGVoosJ10o4cUrqF2y9URmw9glJZj6dPs8I UDaEIAa8maK7Oj9+n9Ws2cMr3YCCaRVaOH5gpeFM= X-DKIM: OpenDKIM Filter v2.4.3 helium.mailtransaction.com 0MHR00100NIRNV00 Cc: spfbis@ietf.org Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was Re: Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 21:25:45 -0000 On 02/05/2013 04:17 PM, Scott Kitterman wrote: > On Wednesday, January 16, 2013 03:06:05 PM Murray S. Kucherawy wrote: >> Operators are ultimately the ones that implement local policy, so I think >> it's reasonable to place the focus there. It's unlikely that end users >> will read this and/or try to understand it. That said, I don't have a >> problem with the alternative text proposed by John. >> >> I think the point in the last paragraph of the proposed 11.7 needs to >> remain, however. > I'm working through issues for the next revision and this is one of them. > > I think we should stick with Murray's originally proposed text for this new > security consideration: > >> Operators that choose to deliver mail for which SPF produces a "fail" >> result need to understand that they are admitting content that is >> explicitly not authorized by the purported sender. While there are >> known failure modes that can be considered "false negatives", the >> distincg choice to admit those messages increases end-user exposure >> to likely harm. This is especially true for domains belonging to >> known good actors that are typically well-behaved; unauthorized mail >> from those sources might well be subjected to much higher skepticism >> and content analysis. >> >> SPF does not, however, include the capacity for identifying good >> actors from bad ones, nor does it handle the concept of known actors >> versus unknown ones. Those notions are out of scope for this >> specification. +1 for this text, _including_ the 2nd paragraph. And yes, I have read all messages in this thread until 2 minutes ago. So maybe I should say: +10 for this text. /rolf From superuser@gmail.com Tue Feb 5 13:31:38 2013 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 19EA121F8881 for ; Tue, 5 Feb 2013 13:31:38 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qag19Jw4HRaE for ; Tue, 5 Feb 2013 13:31:37 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2403821F8691 for ; Tue, 5 Feb 2013 13:31:36 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so4516299wie.2 for ; Tue, 05 Feb 2013 13:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=u9Sv0ngUXHTQcr4MHuGJgJfOFnPFMNbK8BQOWQsoOtI=; b=JVlZ1QnpPPNsFqWaQYssF9jQPLxrPMmyfBjVObVtjJIi4lH30ZTvgEzaD7S6er2/Dk 5Z2Fa5ICuAStjDihe+VvcUpqCpDAvCmlJYsldg/FPZ9HQtBo2fLyCqx3jYVnMHS7TqrW J6+MTCjolcnoDM6VqB/4rtWC6QMm0uwHu+gN2Nam3j1bw5j/U0jPlqZB/qvoN+8FG9Kt 89Ad7Ne0VAYh5/d7GSBTleLGDIMT0G7PPQf3DbQIUciH5/k5E0QdzK0pLpoUBqR0Irbv lR0UpzxEYaDIFTKj9rHlcMdlKi7oTDZAOrAAo2ZqjUbi9Hy5UQp/icAlYjcey473tW3U r5vw== MIME-Version: 1.0 X-Received: by 10.180.108.3 with SMTP id hg3mr512688wib.33.1360099896317; Tue, 05 Feb 2013 13:31:36 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 13:31:36 -0800 (PST) In-Reply-To: References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <2045033.dBgdao1sTi@scott-latitude-e6320> <5865342.GP9k02oU8y@scott-latitude-e6320> <5A537618C0C343AC8BB0457FDC6A2001@addom.santronics.com> Date: Tue, 5 Feb 2013 13:31:36 -0800 Message-ID: From: "Murray S. Kucherawy" To: Dotzero Content-Type: multipart/alternative; boundary=e89a8f3ba6e32dd75604d500efc0 Cc: "spfbis@ietf.org" , Hector Santos Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 21:31:38 -0000 --e89a8f3ba6e32dd75604d500efc0 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 5, 2013 at 12:59 PM, Dotzero wrote: > On Tue, Feb 5, 2013 at 3:43 PM, Hector Santos wrote: > > I don't think this is the question to ask and with all due respect, an > unfair one to impose knowing there is no answer to it unless we wish to > begin discussion for the definition of GOOD vs BAD. > > > > GOOD and BAD are irrelevent. Either it validates or it does not. The > use of "?", "~", "-" and "+" at the end of an SPF record communicates > the strictness of the published record. It tells us about > authorization, not goodness or badness. > Right. Spammers can get an SPF "pass" easily enough, so do we simply admit everything that "pass"es? That seems awfully un-smart to me. Similarly, legit senders pass mail through forwarders, through no fault of their own. That will result in a "fail", and "-all" will cause such legit mail to be rejected. Put those together and SPF falls well short of being "deterministic". It may be good enough for some people to be used that way, but generally speaking, one can't make that claim, and a standards document certainly should not. As Dave has pointed out before, the only case where you actually know something about a message is when you get a "pass". That's the only case in which you have some generally actionable result, though it's also silly to conclude "pass" is congruent to "deliver". I think this notion that we are injecting reputation or scoring into the protocol is specious. The only thing going on here is the need to point out to operators that "pass" doesn't automatically mean "deliver", as described above. That has to be communicated; it would be irresponsible of us not to do so. What the operator does with that information is up to it. -MSK --e89a8f3ba6e32dd75604d500efc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 5, 2013 at 12:59 PM, Dotzero <dotzero@gmail.c= om> wrote:
On Tue, Feb 5, 2013 at 3:43 PM, Hector Santos <hsantos@isdg.net> wrote:
> I don't think this is the question to ask and with all due respect= , an unfair one to impose knowing there is no answer to it unless we wish t= o begin discussion for the definition of GOOD vs BAD.
>

GOOD and BAD are irrelevent. Either it validates or it does not. The<= br> use of "?", "~", "-" and "+" at the= end of an SPF record communicates
the strictness of the published record. It tells us about
authorization, not goodness or badness.

Right.=A0 Spammers can get an SPF "pass" easily= enough, so do we simply admit everything that "pass"es?=A0 That = seems awfully un-smart to me.=A0 Similarly, legit senders pass mail through= forwarders, through no fault of their own.=A0 That will result in a "= fail", and "-all" will cause such legit mail to be rejected.= =A0 Put those together and SPF falls well short of being "deterministi= c".=A0 It may be good enough for some people to be used that way, but = generally speaking, one can't make that claim, and a standards document= certainly should not.

As Dave has pointed out before, the on= ly case where you actually know something about a message is when you get a= "pass".=A0 That's the only case in which you have some gener= ally actionable result, though it's also silly to conclude "pass&q= uot; is congruent to "deliver".

I think this notion that we are inject= ing reputation or scoring into the protocol is specious.=A0 The only thing = going on here is the need to point out to operators that "pass" d= oesn't automatically mean "deliver", as described above.=A0 T= hat has to be communicated; it would be irresponsible of us not to do so.= =A0 What the operator does with that information is up to it.

-MSK

--e89a8f3ba6e32dd75604d500efc0-- From superuser@gmail.com Tue Feb 5 13:34:12 2013 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 DB4E121F88E1 for ; Tue, 5 Feb 2013 13:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t07FmmADiGKQ for ; Tue, 5 Feb 2013 13:34:12 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 88CE921F88B0 for ; Tue, 5 Feb 2013 13:34:11 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so531626wgb.33 for ; Tue, 05 Feb 2013 13:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Z3iRotJQUZe2B8mLFNClVZ5VMdW4jWM2mhPiQqAPDqU=; b=JGrzDNIawsKH8AS8Tw6tzJzEdXUA/6J3wgSVKW6y1WrWyhwv/D3HoHKyFx4gn8YV45 ZNaGxoYfp+xGTPjum8bivpQy4FhipzUdY2lB69oDNz9MZfsY/fVaHMNWWJZQbPrnwQuN k3QvQ082e3/5zFHpVbzBTmjADhQpO8cZKpa2s+FEeayMvW3Bz6nTgJn5yewbndDc1xwp d7qizk+XESmnoVUvdQvw0LePoSPXCq/E+S8O74AVab7Hf2UZVk4bgMuEY1md/a+wnVit L+0tUQF9WTUOxx/0az6QFzLQTiJrvkQeR47m6bjruD6tJotYvII3FFaiT3ucXg5bgagu RvYg== MIME-Version: 1.0 X-Received: by 10.194.59.40 with SMTP id w8mr45699245wjq.51.1360100050753; Tue, 05 Feb 2013 13:34:10 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 13:34:10 -0800 (PST) In-Reply-To: <18634195.xKHCPc4tqs@scott-latitude-e6320> References: <18634195.xKHCPc4tqs@scott-latitude-e6320> Date: Tue, 5 Feb 2013 13:34:10 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7b86d68c6256f804d500f88a Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Ticket #47 domain-spec 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, 05 Feb 2013 21:34:13 -0000 --047d7b86d68c6256f804d500f88a Content-Type: text/plain; charset=ISO-8859-1 Feel free to point me at previous discussion, but why "(even when the connection type is IPv6)"? Shouldn't a DNS error result in a "temp-fail"? -MSK On Tue, Feb 5, 2013 at 10:00 AM, Scott Kitterman wrote: > I think this needs discussion before I include one of the two proposed > solutions in a draft. > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/47 > > Suggested text: > > bis-06: > > The domain-spec is expanded as per Section 8. The resulting domain > name is > used for a DNS A RR lookup. If any A record is returned, this mechanism > matches. The lookup type is A even when the connection type is IPv6. > > new: > > The domain-spec is expanded as per Section 8. The resulting domain > name is > used for a DNS A RR lookup (even when the connection type is IPv6). If any > A > record is returned, this mechanism matches, otherwise the mechanism doesn't > match. > > or new: > > The domain-spec is expanded as per Section 8. The resulting domain > name is > used for a DNS A RR lookup (even when the connection type is IPv6). If any > A > record is returned, this mechanism matches. In all other cases (no A > records, > DNS error, etc.), the mechanism doesn't match. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > > As I read it the second alternative specifies that a DNS error is treated > as a > no match, but the first does not. I believe we want the first as we don't > want > to hide DNS failures, but I'm not sure. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --047d7b86d68c6256f804d500f88a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Feel free to point me at previous discussion, bu= t why "(even when the connection type is IPv6)"?

Sho= uldn't a DNS error result in a "temp-fail"?

-MSK=


On Tue,= Feb 5, 2013 at 10:00 AM, Scott Kitterman <spf2@kitterman.com> wrote:
I think this needs discussion before I inclu= de one of the two proposed
solutions in a draft.

http://trac.tools.ietf.org/wg/spfbis/trac/ticket/47

=A0Suggested text:

bis-06:

=A0 =A0 The domain-spec is expanded as per Section 8. The resulting domain = name is
used for a DNS A RR lookup. If any A record is returned, this mechanism
matches. The lookup type is A even when the connection type is IPv6.

new:

=A0 =A0 The domain-spec is expanded as per Section 8. The resulting domain = name is
used for a DNS A RR lookup (even when the connection type is IPv6). If any = A
record is returned, this mechanism matches, otherwise the mechanism doesn&#= 39;t
match.

or new:

=A0 =A0 The domain-spec is expanded as per Section 8. The resulting domain = name is
used for a DNS A RR lookup (even when the connection type is IPv6). If any = A
record is returned, this mechanism matches. In all other cases (no A record= s,
DNS error, etc.), the mechanism doesn't match.

http://www.ietf.org/mail-archive/web/spfbis/current/ms= g02371.html

As I read it the second alternative specifies that a DNS error is treated a= s a
no match, but the first does not. =A0I believe we want the first as we don&= #39;t want
to hide DNS failures, but I'm not sure.

Scott K
_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--047d7b86d68c6256f804d500f88a-- From superuser@gmail.com Tue Feb 5 13:35:57 2013 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 0907221F88E5 for ; Tue, 5 Feb 2013 13:35:57 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnWykOqsdhdP for ; Tue, 5 Feb 2013 13:35:56 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF9921F88B0 for ; Tue, 5 Feb 2013 13:35:55 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id 12so4479436wgh.3 for ; Tue, 05 Feb 2013 13:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DotilfTnvCeCQ/jaCMi1KcOun0WbWx83kPOZVj8CxN8=; b=u/RZP61S4bmhnMMKV7m4pbNIWdHGmxTeEiZnPqesqitYN/b05HJ3FSkct8NGETVI7C w5j8sCuqZ0bp5p6bYoh5L9y+33IwGPkpXU1wYmlZn+Ua1p5iPL1Ag4ihoHgC1DQH583m 9GE7lDbaDDSgi22iZ67sFEoHsBDIziIaOO0+VmTeCIbWRhEut/dXmL/h/IVTqY3EsZtk EbN9vOBTQXwM/he0ADKmd90ScyrhDlsi9j6EfRNuSuKXG8bXxtce2x66K2sKMAje8B0Z nb6VpWgJvqceBzFuKvItTcDgihIgBzoeNRY0oaDTwJ/P5c9+Hdyzg8+fjh3PRKayqsmW aE4Q== MIME-Version: 1.0 X-Received: by 10.180.73.80 with SMTP id j16mr1047747wiv.5.1360100155184; Tue, 05 Feb 2013 13:35:55 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 13:35:55 -0800 (PST) In-Reply-To: <18382376.hIpMDkXD4i@scott-latitude-e6320> References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> <18382376.hIpMDkXD4i@scott-latitude-e6320> Date: Tue, 5 Feb 2013 13:35:55 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043bdf389bd52304d500fe0d Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 05 Feb 2013 21:35:57 -0000 --f46d043bdf389bd52304d500fe0d Content-Type: text/plain; charset=ISO-8859-1 Doesn't the same attack exist if one lists >10 MX records? Just wondering why MX isn't getting the same treatment as PTR in the proposed new text. -MSK On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman wrote: > On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote: > > #43 New requirement for mx: or ptr records > > Issue: > > > in section 4.6.4, there is a new requirement that there must not be more > > than 10 records for mx: or ptr:. This completely wrong for ptr: because a > > spammer could choose to send spam from a host with more than 10 PTR > > records, thus forcing a domain's SPF record to return permerror, instead > of > > fail. If anything, more than 10 PTR records should cause the ptr: > mechanism > > to automatically not-match. It should also be made clear that the %{p} > > macro is valid no matter how many PTR records are returned. > > Proposed new text for 4.6.4 (in my local copy): > > > 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. If more than 10 "mx" records are returned for this > > further lookup, a permerror MUST be returned. If more than 10 "ptr" > > records are returned for this further lookup (either due to use of > > a "ptr" mechanisms, or the %{p} macro) processing MUST be terminated > > after 10 records. This limit is per mechanism or macro in the > > record and in addition to the lookup limits above. > > Comments please. If no one objects, I'll include it. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d043bdf389bd52304d500fe0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Doesn't the same attack exist if one lists &= gt;10 MX records?

Just wondering why MX isn't getting the = same treatment as PTR in the proposed new text.

-MSK


On Tue, Feb 5= , 2013 at 9:06 AM, Scott Kitterman <spf2@kitterman.com> wro= te:
On Thursday, January 31, 2= 013 06:02:53 AM S Moonesamy wrote:
> #43 New requirement for mx: or ptr records

Issue:

> in section 4.6.4, there is a new requirement that there must not be mo= re
> than 10 records for mx: or ptr:. This completely wrong for ptr: becaus= e a
> spammer could choose to send spam from a host with more than 10 PTR > records, thus forcing a domain's SPF record to return permerror, i= nstead of
> fail. If anything, more than 10 PTR records should cause the ptr: mech= anism
> to automatically not-match. It should also be made clear that the %{p}=
> macro is valid no matter how many PTR records are returned.

Proposed new text for 4.6.4 (in my local copy):

> =A0When evaluating the "mx" and "ptr" mechanisms, = or the %{p} macro,
> =A0there MUST be a limit of no more than 10 MX or PTR RRs looked up > =A0and checked. =A0If more than 10 "mx" records are returned= for this
> =A0further lookup, a permerror MUST be returned. =A0If more than 10 &q= uot;ptr"
> records are returned for this further lookup (either due to use of
> a "ptr" mechanisms, or the %{p} macro) processing MUST be te= rminated
> after 10 records. =A0This limit is per mechanism or macro in the
> record and in addition to the lookup limits above.

Comments please. =A0If no one objects, I'll include it.

Scott K
___________________________________= ____________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--f46d043bdf389bd52304d500fe0d-- From superuser@gmail.com Tue Feb 5 13:39:30 2013 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 B8F6721F892C for ; Tue, 5 Feb 2013 13:39:30 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKXlyBGHGYUB for ; Tue, 5 Feb 2013 13:39:29 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4644D21F8915 for ; Tue, 5 Feb 2013 13:39:29 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so551792wey.7 for ; Tue, 05 Feb 2013 13:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MhNM2BocCh4jvYh8Y95/uO5tnqnN7o4n4M36hB88oG8=; b=0Doddk+MwkuuuyjYv3K0ymGZEzU/da5SWn0hSu+uONW+gjiALjzq/9a9UFGrtboc0C arULySziDPWZbViwN5MYy2YGizeKt9To8qS0E10VqznVjZbc5/qBh6/+OBrtNJ9HUZRJ SQPNXJ0ASlW1y8faEHzxv/XX62vIpwoLJSwNI7Gs5YCocYWb3ESwxlshQVq+WROWSqYC UWscgQRlY/R5etJ+xlbtjqKx2Q3LGVamkEir8JzGtXd7DqVxfLKMK1nk6vfsFBApYkpT xO6cGKgeaGaxIGAOQNDmmRjby6wbjtNKjHTRuS07g9n2eUOYlwvQyVT3SMTY/DwPiLyf mMOA== MIME-Version: 1.0 X-Received: by 10.180.75.110 with SMTP id b14mr970541wiw.21.1360100368429; Tue, 05 Feb 2013 13:39:28 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 13:39:28 -0800 (PST) In-Reply-To: <6185132.ENqHzg2QWR@scott-latitude-e6320> References: <1440164.CoAgXWpN1C@scott-latitude-e6320> <5865342.GP9k02oU8y@scott-latitude-e6320> <5A537618C0C343AC8BB0457FDC6A2001@addom.santronics.com> <6185132.ENqHzg2QWR@scott-latitude-e6320> Date: Tue, 5 Feb 2013 13:39:28 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043be22851b21804d5010b9d Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 21:39:30 -0000 --f46d043be22851b21804d5010b9d Content-Type: text/plain; charset=ISO-8859-1 +1. -MSK On Tue, Feb 5, 2013 at 1:20 PM, Scott Kitterman wrote: > OK. I think that is all covered in the current draft. > > Scott K > > On Tuesday, February 05, 2013 03:43:39 PM Hector Santos wrote: > > I don't think this is the question to ask and with all due respect, an > > unfair one to impose knowing there is no answer to it unless we wish to > > begin discussion for the definition of GOOD vs BAD. > > > > This is part of the confusion of "Reputation" and "Scoring" being > injected > > into the protocol - the Message Evaluation Component or Agent (MEA)** as > it > > being considered, but we need to first change the mindset to a REPORTING > > instead of rejection. > > > > Good or BAD are inherent terms in SPF, and specifically for -ALL, since > it > > declares with a high certainty who are "GOOD" or "VALID: senders as > oppose > > to "BAD" or "WRONG" ones. In fact, I suggest some may even extend that > to > > a BAD/GOOD Reputation concept, just not the one most are thinking about > > using some 3rd party with a combined DKIM component. > > > > No, with SPF, the -ALL, and thats all I speak of, thats a deterministic > > (On/Off, not Fuzzy) quality, not a heuristic, fuzzy quality althougt > thats > > not to say it can part of some proprietary secret formula. > > > > IMO, it is not out of scope for BIS to discuss -ALL REJECTION or MARKING > > technical protocol ideas. Just lay it out - don't suggest it out of > scope > > thus it can't be discussed. People, especially "naive" ones do need > > direction I would think. > > > > ** The MEA is implementation specific. We know that, but there is a > GENERAL > > guideline that SPF needs to lay out - thats part of the scope. That > > includes, REJECT or MARKING and even doing nothing, but that goes for all > > protocols - to do nothing. It wouldn't make sense to repeat that here > > because you can cleanly lay it out as a in-scope logic: > > > > REJECT > > MARK (REPORT) / SEPARATION > > MARK (REPORT) / DO NOTHING > > > > Naive readers will like to know what needs to be done for supporting SPF > > from an receiver standpoint and for documenting what an -ALL policy can > > offer domains. > > > > Thanks > > > > ----- Original Message ----- > > From: "Scott Kitterman" > > To: > > Sent: Tuesday, February 05, 2013 3:15 PM > > Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - > > wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt > > > Please give me the section number of RFC 4408 where it defines how SPF > > > determines good actors from bad ones? If you can find that, we might > have > > > something to discuss. > > > > > > Scott K > > > > > > On Tuesday, February 05, 2013 03:06:43 PM Hector Santos wrote: > > >> I don't believe the 2nd paragraph is correct, technically or > logically. > > >> It > > >> provides a falsehood about the SPF protocol, a sense of wasted > purpose to > > >> support or publish -ALL which is not a figment of our imaginations - > its > > >> in > > >> > > >> HIGH USE and there are two basic protocol actions: > > >> REJECT > > >> MARK (can be symnonous to separation) > > >> > > >> For many people, even the naive, that can be very clear and precise > for > > >> naive administrators and/or naive developers. > > >> > > >> What you are doing, and I am highly concern with, is the idea with the > > >> "naive" market (whatever that means, different audidence of BIS > readers?) > > >> doesn't have to do anything in being a fully compliant SPF Receiver. > > >> > > >> This will water down the -ALL policy, the confidence in its usage of > what > > >> is expected by receivers to FILTER. > > >> > > >> What you (the text) is saying: > > >> Forget all that, its out of scope. What is in scope is > > >> to REPORT the result and if you don't want to do anything with > it, > > >> thats also, IN SCOPE. > > >> > > >> Very confusing and ultimately, in my view, a SPF-KILLER. It will lower > > >> the > > >> incentive to support SPF. It hurts SPF. I say that because we saw it > > >> happen with DKIM when POLICY was watered down (deemed out of scope) > and > > >> removed. That is essentially what is going on here and I am very > concern > > >> about it. I can't support a BIS that marginalizes the -ALL policy in > any > > >> way, shape or form. > > >> > > >> -- > > >> HLS > > >> > > >> ----- Original Message ----- > > >> From: "Scott Kitterman" > > >> To: > > >> Sent: Tuesday, February 05, 2013 12:30 PM > > >> Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was > > >> Re:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt > > >> > > >> > On Tuesday, February 05, 2013 11:53:20 AM Hector Santos wrote: > > >> >> I am ok with MK's text except for the 2nd paragraph. I think a > simple > > >> >> remove is OK since I think the spec is precisely about > establishing a > > >> >> client/server protocol which inherently includes a sender and > receiver > > >> >> policy framework. > > >> > > > >> > While the second paragraph may be sufficiently obvious to members of > > >> > the > > >> > working group, I think for a naive reader of the spec, it's an > > >> > important > > >> > thing to communicate. I'd prefer to leave it. > > >> > > > >> > Scott K > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d043be22851b21804d5010b9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1.

-MSK


On Tue, Feb 5, 2013 at 1:20 PM, Sco= tt Kitterman <spf2@kitterman.com> wrote:
OK. =A0I think that is all covered in the cu= rrent draft.

Scott K

On Tuesday, February 05, 2013 03:43:39 PM Hector Santos wrote:
> I don't think this is the question to ask and with all due respect= , an
> unfair one to impose knowing there is no answer to it unless we wish t= o
> begin discussion for the definition of GOOD vs BAD.
>
> This is part of the confusion of "Reputation" and "Scor= ing" being injected
> into the protocol - the Message Evaluation Component or Agent (MEA)** = as it
> being considered, but we need to first change the mindset to a REPORTI= NG
> instead of rejection.
>
> Good or BAD are inherent terms in SPF, and specifically for -ALL, sinc= e it
> declares with a high certainty who are "GOOD" or "VALID= : senders as oppose
> to "BAD" or "WRONG" ones. =A0In fact, I suggest so= me may even extend that to
> a BAD/GOOD Reputation concept, just not the one most are thinking abou= t
> using some 3rd party with a combined DKIM component.
>
> No, with SPF, the -ALL, and thats all I speak of, thats a deterministi= c
> (On/Off, not Fuzzy) quality, not a heuristic, fuzzy quality althougt t= hats
> not to say it can part of some proprietary secret formula.
>
> IMO, it is not out of scope for BIS to discuss -ALL REJECTION or MARKI= NG
> technical protocol ideas. =A0Just lay it out - don't suggest it ou= t of scope
> thus it can't be discussed. People, especially "naive" o= nes do need
> direction I would think.
>
> ** The MEA is implementation specific. We know that, but there is a GE= NERAL
> guideline that SPF needs to lay out - thats part of the scope. That > includes, REJECT or MARKING and even doing nothing, but that goes for = all
> protocols - to do nothing. It wouldn't make sense to repeat that h= ere
> because you can cleanly lay it out as a in-scope logic:
>
> =A0 REJECT
> =A0 MARK (REPORT) / SEPARATION
> =A0 MARK (REPORT) / DO NOTHING
>
> Naive readers will like to know what needs to be done for supporting S= PF
> from an receiver standpoint and for documenting what an -ALL policy ca= n
> offer domains.
>
> Thanks
>
> ----- Original Message -----
> From: "Scott Kitterman" <spf2@kitterman.com>
> To: <spfbis@ietf.org>
> Sent: Tuesday, February 05, 2013 3:15 PM
> Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Resul= t -
> wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.tx= t
> > Please give me the section number of RFC 4408 where it defines ho= w SPF
> > determines good actors from bad ones? =A0If you can find that, we= might have
> > something to discuss.
> >
> > Scott K
> >
> > On Tuesday, February 05, 2013 03:06:43 PM Hector Santos wrote: > >> I don't believe the 2nd paragraph is correct, technically= or logically.
> >> It
> >> provides a falsehood about the SPF protocol, a sense of waste= d purpose to
> >> support or publish -ALL which is not a figment of our imagina= tions - its
> >> in
> >>
> >> HIGH USE and there are two basic protocol actions:
> >> =A0 =A0 =A0REJECT
> >> =A0 =A0 =A0MARK (can be symnonous to separation)
> >>
> >> For many people, even the naive, that can be very clear and p= recise for
> >> naive administrators and/or naive developers.
> >>
> >> What you are doing, and I am highly concern with, is the idea= with the
> >> "naive" market (whatever that means, different audi= dence of BIS readers?)
> >> doesn't have to do anything in being a fully compliant SP= F Receiver.
> >>
> >> This will water down the -ALL policy, the confidence in its u= sage of what
> >> is expected by receivers to FILTER.
> >>
> >> What you (the text) is saying:
> >> =A0 =A0 =A0 Forget all that, its out of scope. What is in sco= pe is
> >> =A0 =A0 =A0 to REPORT the result and if you don't want to= do anything with it,
> >> =A0 =A0 =A0 thats also, IN SCOPE.
> >>
> >> Very confusing and ultimately, in my view, a SPF-KILLER. It w= ill lower
> >> the
> >> incentive to support SPF. =A0It hurts SPF. =A0I say that beca= use we saw it
> >> happen with DKIM when POLICY was watered down (deemed out of = scope) and
> >> removed. =A0That is essentially what is going on here and I a= m very concern
> >> about it. I can't support a BIS that marginalizes the -AL= L policy in any
> >> way, shape or form.
> >>
> >> --
> >> HLS
> >>
> >> ----- Original Message -----
> >> From: "Scott Kitterman" <spf2@kitterman.com>
> >> To: <spfbis@ietf.org>
> >> Sent: Tuesday, February 05, 2013 12:30 PM
> >> Subject: Re: [spfbis] Delivering Mail Producing a 'Fail&#= 39; Result - was
> >> Re:Fwd:New Version Notification for draft-ietf-spfbis-4408bis= -09.txt
> >>
> >> > On Tuesday, February 05, 2013 11:53:20 AM Hector Santos = wrote:
> >> >> I am ok with MK's text except for the 2nd paragr= aph. =A0I think a simple
> >> >> remove is OK since I think the spec is precisely abo= ut establishing a
> >> >> client/server protocol which inherently includes a s= ender and receiver
> >> >> policy framework.
> >> >
> >> > While the second paragraph may be sufficiently obvious t= o members of
> >> > the
> >> > working group, I think for a naive reader of the spec, i= t's an
> >> > important
> >> > thing to communicate. =A0I'd prefer to leave it.
> >> >
> >> > Scott K

_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--f46d043be22851b21804d5010b9d-- From tim@eudaemon.net Tue Feb 5 13:41:58 2013 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 8926F21F8933 for ; Tue, 5 Feb 2013 13:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx9kQddCPRjz for ; Tue, 5 Feb 2013 13:41:58 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id CE78921F892E for ; Tue, 5 Feb 2013 13:41:57 -0800 (PST) Received: from [10.162.171.21] (4.sub-70-193-6.myvzw.com [70.193.6.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 3EE65CB46; Tue, 5 Feb 2013 16:42:31 -0500 (EST) References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> <18382376.hIpMDkXD4i@scott-latitude-e6320> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-3BD13659-814C-4B22-80E6-0149B44414B0 Content-Transfer-Encoding: 7bit Message-Id: <48F9E629-7707-461A-93B6-CC3885EABCD0@eudaemon.net> X-Mailer: iPhone Mail (10B143) From: Tim Draegen Date: Tue, 5 Feb 2013 16:41:53 -0500 To: "Murray S. Kucherawy" Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 05 Feb 2013 21:41:58 -0000 --Apple-Mail-3BD13659-814C-4B22-80E6-0149B44414B0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'm reading that it does get the same treatment.. =3D- Tim On Feb 5, 2013, at 4:35 PM, "Murray S. Kucherawy" wrot= e: > Doesn't the same attack exist if one lists >10 MX records? >=20 > Just wondering why MX isn't getting the same treatment as PTR in the propo= sed new text. >=20 > -MSK >=20 >=20 > On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman wrote= : >> On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote: >> > #43 New requirement for mx: or ptr records >>=20 >> Issue: >>=20 >> > in section 4.6.4, there is a new requirement that there must not be mor= e >> > than 10 records for mx: or ptr:. This completely wrong for ptr: because= a >> > spammer could choose to send spam from a host with more than 10 PTR >> > records, thus forcing a domain's SPF record to return permerror, instea= d of >> > fail. If anything, more than 10 PTR records should cause the ptr: mecha= nism >> > to automatically not-match. It should also be made clear that the %{p} >> > macro is valid no matter how many PTR records are returned. >>=20 >> Proposed new text for 4.6.4 (in my local copy): >>=20 >> > 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. If more than 10 "mx" records are returned for this >> > further lookup, a permerror MUST be returned. If more than 10 "ptr" >> > records are returned for this further lookup (either due to use of >> > a "ptr" mechanisms, or the %{p} macro) processing MUST be terminated >> > after 10 records. This limit is per mechanism or macro in the >> > record and in addition to the lookup limits above. >>=20 >> Comments please. If no one objects, I'll include it. >>=20 >> Scott K >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >=20 > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis --Apple-Mail-3BD13659-814C-4B22-80E6-0149B44414B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I'm reading that it does get the same treatment..

=- Tim


On Feb 5, 2013, at 4:35 PM, "Murray S. Kucherawy" <superuser@gmail.com> wrote:

Doesn't the same attack exist if one lists >10 MX records?

Just wondering why MX isn't getting the same treatment as PTR in the proposed new text.

-MSK


On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman <spf2@kitterman.com> wrote:
On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote:
> #43 New requirement for mx: or ptr records

Issue:

> in section 4.6.4, there is a new requirement that there must not be more
> than 10 records for mx: or ptr:. This completely wrong for ptr: because a
> spammer could choose to send spam from a host with more than 10 PTR
> records, thus forcing a domain's SPF record to return permerror, instead of
> fail. If anything, more than 10 PTR records should cause the ptr: mechanism
> to automatically not-match. It should also be made clear that the %{p}
> macro is valid no matter how many PTR records are returned.

Proposed new text for 4.6.4 (in my local copy):

>  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.  If more than 10 "mx" records are returned for this
>  further lookup, a permerror MUST be returned.  If more than 10 "ptr"
> records are returned for this further lookup (either due to use of
> a "ptr" mechanisms, or the %{p} macro) processing MUST be terminated
> after 10 records.  This limit is per mechanism or macro in the
> record and in addition to the lookup limits above.

Comments please.  If no one objects, I'll include it.

Scott K
_______________________________________________
spfbis mailing list
spfbis@ietf.org
https://www.ietf.org/mailman/listinfo/spfbis

_______________________________________________
spfbis mailing list
spfbis@ietf.org
https://www.ietf.org/mailman/listinfo/spfbis
--Apple-Mail-3BD13659-814C-4B22-80E6-0149B44414B0-- From hsantos@isdg.net Tue Feb 5 13:54:12 2013 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 5E91D21F8536 for ; Tue, 5 Feb 2013 13:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.529 X-Spam-Level: X-Spam-Status: No, score=-101.529 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_46=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5mNmj+zjR0K for ; Tue, 5 Feb 2013 13:54:09 -0800 (PST) Received: from mail.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CE9D721F857D for ; Tue, 5 Feb 2013 13:54:08 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3032; t=1360101241; h=Received:Received: Message-ID:From:To:Subject:Date:Organization:List-ID; bh=51USnJK gSeXXs/IY1TOzy9rVdyA=; b=jGHCXjiJE3Buey0/qqQXCgG91/keZ+5LVu0Xwe/ T7QRe1mQrts4lnsN5n5MHSSNQBWEydV+/H4lwmLmGaGU4VgXBUiRuTQ5/MeomaYd m3jqzL/GzExGK99ac7fsSmghope9StNcFatahB1DrSLuo9DE72I3uCud+kkhaF8w 010I= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 05 Feb 2013 16:54:01 -0500 Received: from main2 ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3237972974.24643.3780; Tue, 05 Feb 2013 16:54:00 -0500 Message-ID: From: "Hector Santos" To: "Murray S. Kucherawy" , "Dotzero" References: <1440164.CoAgXWpN1C@scott-latitude-e6320><2045033.dBgdao1sTi@scott-latitude-e6320><5865342.GP9k02oU8y@scott-latitude-e6320><5A537618C0C343AC8BB0457FDC6A2001@addom.santronics.com> Date: Tue, 5 Feb 2013 16:52:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Cc: spfbis@ietf.org Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 21:54:12 -0000 None of which has to do what DESIGN OPTIONS are available for the SPF = protocol. Its not a vague concept. Reciever gets an -ALL failure, it can REJECT or MARK the message. isn't that what RFC 4408 2.5.4 basically stated? All you are basically saying now (reminding the naive), it can DO = NOTHING. Fine, then say it, but lay it out: REJECT (already has RFC 2119 semantics) MARK (Define it) =20 DO NOTHING (Warning against it) OTHER (Advise of DOMAIN PUBLISHER expectations) Ultimately, alternatives MUST|SHOULD match the Functional behavior of a = REJECT, otherwisethere are security repercussions with the MARK and = worst with DO NOTHING and possible OTHER. We are not starting new here.=20 Thanks ----- Original Message -----=20 From: "Murray S. Kucherawy" To: "Dotzero" Cc: "Hector Santos" ; Sent: Tuesday, February 05, 2013 4:31 PM Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - = wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.txt > On Tue, Feb 5, 2013 at 12:59 PM, Dotzero wrote: >=20 >> On Tue, Feb 5, 2013 at 3:43 PM, Hector Santos = wrote: >> > I don't think this is the question to ask and with all due respect, = an >> unfair one to impose knowing there is no answer to it unless we wish = to >> begin discussion for the definition of GOOD vs BAD. >> > >> >> GOOD and BAD are irrelevent. Either it validates or it does not. The >> use of "?", "~", "-" and "+" at the end of an SPF record communicates >> the strictness of the published record. It tells us about >> authorization, not goodness or badness. >> >=20 > Right. Spammers can get an SPF "pass" easily enough, so do we simply = admit > everything that "pass"es? That seems awfully un-smart to me. = Similarly, > legit senders pass mail through forwarders, through no fault of their = own. > That will result in a "fail", and "-all" will cause such legit mail to = be > rejected. Put those together and SPF falls well short of being > "deterministic". It may be good enough for some people to be used = that > way, but generally speaking, one can't make that claim, and a = standards > document certainly should not. >=20 > As Dave has pointed out before, the only case where you actually know > something about a message is when you get a "pass". That's the only = case > in which you have some generally actionable result, though it's also = silly > to conclude "pass" is congruent to "deliver". >=20 > I think this notion that we are injecting reputation or scoring into = the > protocol is specious. The only thing going on here is the need to = point > out to operators that "pass" doesn't automatically mean "deliver", as > described above. That has to be communicated; it would be = irresponsible of > us not to do so. What the operator does with that information is up = to it. >=20 > -MSK > From johnl@iecc.com Tue Feb 5 14:18:28 2013 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 8E09421F8484 for ; Tue, 5 Feb 2013 14:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.958 X-Spam-Level: X-Spam-Status: No, score=-110.958 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOr6eiDPlmTL for ; Tue, 5 Feb 2013 14:18:28 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BF7E621F847B for ; Tue, 5 Feb 2013 14:18:27 -0800 (PST) Received: (qmail 92913 invoked from network); 5 Feb 2013 22:18:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Feb 2013 22:18:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51118532.xn--9vv.k1302; i=johnl@user.iecc.com; bh=R939c4e818dVQtdrRSUHOnwq03PRsRgYKnKPeipbMBU=; b=ioyJ/1BIJexx2L3pkvd2+XHXEgEIbr6EvmNE6LfpdIaDsojkC1apO57XSoiL2YBVbXSKxS7T8DBB9OFhOY78BmwW3RB7yhkMqlKAynC0EmFZ/LfkxWfjKECIWdjDPAKCEkmGSzfcs+kj5mlHGH9Hf43K46eBSZjT07MpY4aX7pw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=51118532.xn--9vv.k1302; olt=johnl@user.iecc.com; bh=R939c4e818dVQtdrRSUHOnwq03PRsRgYKnKPeipbMBU=; b=h4QnDsj3U9SG+QqIxFGblYfQgiwE6UDlTvLIs5DbjE0p3lMzF0q8aQwGpCbXvR4Fu0v7zasXiUQI22nChfE1W0NjvAsBLfrRZEOUMZ2cBDot7Zp9Cc8yWOcZgqDcwGqschlIssJmhfVpkOfxpQs97DDpEVCjlbPBpnkLADj/Ngw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 5 Feb 2013 22:18:04 -0000 Message-ID: <20130205221804.70945.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20130205192833.GA11629@verdi> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: john@jlc.net Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was Re: Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 22:18:28 -0000 > I think it important to say that SPF _cannot_ promise non-delivery >of email that receives an SPF "fail"; and it is not helpful to "blame" >service providers who do so. Agreed. It really is not our job to tell receivers what some of us think that receivers should do with the SPF results. R's, John From spf2@kitterman.com Tue Feb 5 14:50:09 2013 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 29E4321F8880 for ; Tue, 5 Feb 2013 14:50:09 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsS8h8TwUNpF for ; Tue, 5 Feb 2013 14:50:08 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 12E9F21F887F for ; Tue, 5 Feb 2013 14:50:07 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 62F3820E40D6; Tue, 5 Feb 2013 17:50:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360104607; bh=PdMif6h1HRW9H5g1eZ9Ik3qu6WsziSH6Y6E9WF0GdEo=; h=From:To:Subject:Date:From; b=Zr/nMFt+84HkTdgrhmEqCwIJM82cuHSMkm8EhgRTvNMkNJ8Q9EKSkhx1OcpeV9gTY khWgcUnB5y0/LHi0CCxoa0jsACEJhqOMbnCp1EATbsrgKtnLck2AgVzFM6M1wKhIBI JKAa+YqOhX1HWBh0nxPbOHFSCZFdgJgxlNbC3TME= Received: from scott-latitude-e6320.localnet (93.sub-70-195-1.myvzw.com [70.195.1.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 34F9220E40B2; Tue, 5 Feb 2013 17:50:06 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 17:50:04 -0500 Message-ID: <1878869.epuRBHeDfC@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 05 Feb 2013 22:50:09 -0000 Need some help with this one: http://trac.tools.ietf.org/wg/spfbis/trac/ticket/53 Message posted by Barry Leiba on 4 Sept 2012: that was intended to support unknown mechanisms. So, if you had an = SPF record from draft-mengwong-spf-00: v=3Dspf1 a mx ptr domainkeys:_dk.%{d} -all The Received-SPF header would look like: Received-SPF: unknown domainkeys=3D_dk.example.com If that's the case, the text needs work to make it clear, because it's=20= decidedly not. The text below the grammar lists key names and the meani= ngs of=20 the values. "mechanism" is listed as a key name in that text. So there'= s a=20 problem somewhere that needs to be cleared up. =E2=80=8Bhttp://www.ietf.org/mail-archive/web/spfbis/current/msg02608.h= tml Downthread from the referenced message, there's a proposed simplificati= on from=20 Arthur Thisell, but I think it's based on the (I believe incorrect) ass= umption=20 that mechanism isn't used. Suggestions please. Scott K From john@jlc.net Tue Feb 5 14:52:14 2013 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 1DBC221F8900 for ; Tue, 5 Feb 2013 14:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.928 X-Spam-Level: X-Spam-Status: No, score=-105.928 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2pXfQYvQHfG for ; Tue, 5 Feb 2013 14:52:08 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 5D54B21F8880 for ; Tue, 5 Feb 2013 14:51:56 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 693CB33C73; Tue, 5 Feb 2013 17:51:56 -0500 (EST) Date: Tue, 5 Feb 2013 17:51:56 -0500 From: John Leslie To: spfbis@ietf.org Message-ID: <20130205225156.GA15797@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 22:52:14 -0000 Hector Santos wrote: > > None of which has to do what DESIGN OPTIONS are available for the SPF > protocol. Its not a vague concept. > > Reciever gets an -ALL failure, it can REJECT or MARK the message. > > isn't that what RFC 4408 2.5.4 basically stated? Yes: ] ] 2.5.4. Fail ] ] A "Fail" result is an explicit statement that the client is not ] authorized to use the domain in the given identity. The checking ] software can choose to mark the mail based on this or to reject the ] mail outright. In the draft, this has become: ] ] 2.6.4. Fail ] ] A "fail" result is an explicit statement that the client is not ] authorized to use the domain in the given identity. In Section 8, we see: ] ] 8.4. Fail ] ] A "fail" result is an explicit statement that the client is not ] authorized to use the domain in the given identity. Disposition of ] SPF fail messages is a matter of local policy. ]... ] If the checking software chooses not to reject the mail during the ] SMTP transaction, then it SHOULD add a Received-SPF or ] Authentication-Results header field (see Section 9) to communicate ] this result to downstream message processors. While this is true for ] all SPF results, it is of particular importance for "fail" results ] since the message is explicitly not authorized by the domain owner. It seems to me that this is where Hector's problem lies: "SHOULD" add one of these two headers is less than he read into 4408. > All you are basically saying now (reminding the naive), it can DO NOTHING. > > Fine, then say it, but lay it out: > > REJECT (already has RFC 2119 semantics) > MARK (Define it) > DO NOTHING (Warning against it) > OTHER (Advise of DOMAIN PUBLISHER expectations) The Security Considerations text in question lumps together the second, third, and fourth of these. I think it reasonable to say somewhere (not necessarily in Security Considerations, that the "SHOULD" in Section 8.4 may not be strong enough -- that for an SPF "fail" adding one of those headers is a MUST. (OTOH, a "SHOULD" is actually a lot stronger than Hector may think: "SHOULD" is less strong than "MUST" only if the implementor can find an actual reason that "MUST" is inappropriate. While I can't think of such a reason, perhaps someone else can...) The intent of my proposed text was that a service provider (that implements SPF at all) might have a business reason to add one of those headers showing the SPF "fail" and pass the email to the mail-delivery process. I certainly did not intend that the service provider might deliver the email without adding such a header. I would tend to humor Hector to the extent of mentioning in Security Considerations that a service provider that marks with one of the headers mentioned is in accordance with the spec, even though this exposes a receiver that fails to check those headers to potential harm. OTOH, I'd be happy with such text in Section 8.4 instead... -- John Leslie From hsantos@isdg.net Tue Feb 5 14:52:27 2013 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 D24A221F86D8 for ; Tue, 5 Feb 2013 14:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.764 X-Spam-Level: X-Spam-Status: No, score=-101.764 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52IV6cmnTsak for ; Tue, 5 Feb 2013 14:52:25 -0800 (PST) Received: from mail.catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 38B0621F8596 for ; Tue, 5 Feb 2013 14:52:24 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1721; t=1360104735; h=Received:Received: Message-ID:From:To:Subject:Date:Organization:List-ID; bh=iKS8DLU hdCiaztxjYDOQYJJ1u/I=; b=Vv7ZX7ltItASV7pqFYhSNa2FWg0kQK2ZrRgZK75 q1/daqq+Y0s7yCi66HCuub1/HzcKcb5hL819lIX6M+szxgQP1KtHMAq3MMgQkwU3 vsHNv1h9B7ajEhNOqgHC8ZNV1CHdvZYJ4dgAwkgqZOn50C3esz3c37AuTozqHztM wY+w= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 05 Feb 2013 17:52:15 -0500 Received: from main2 ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3241467241.24643.5308; Tue, 05 Feb 2013 17:52:15 -0500 Message-ID: From: "Hector Santos" To: References: <20130205221804.70945.qmail@joyce.lan> Date: Tue, 5 Feb 2013 17:50:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Cc: john@jlc.net Subject: [spfbis] Hard Fail is not Soft Fail. 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, 05 Feb 2013 22:52:27 -0000 It is our job in providing the learned SPF technical engineering = options, epecially in a BIS I hope will gain from the 9+ years of = deployed engineering insights and not start fresh with a new and = alternative viewpoints on how SPF receivers should now behave post-BIS. Ultimately, -ALL requires supportives receivers to: reject or mark, per RFC 4408=20 =20 What I see being advocated is: =20 REPORT and do nothing (or we won't tell you want to do). It is prudent that we write down what are the engineering and security = issues with either one. If domains (Post BIS era) come to learn that -ALL has no weight with = receivers then we have failed the SPF protcol as it was done with DKIM = when we did the same by watering down DKIM policies. We are signing = mail for no purpose any more. No one is doing handling as far as I know. = Lets not create the same problem for SPF -ALL policies. Thank you. ----- Original Message -----=20 From: "John Levine" To: Cc: Sent: Tuesday, February 05, 2013 5:18 PM Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - was = Re:Fwd: New Version Notification for draft-ietf-spfbis-4408bis-09.txt >> I think it important to say that SPF _cannot_ promise non-delivery >>of email that receives an SPF "fail"; and it is not helpful to "blame" >>service providers who do so. >=20 > Agreed. It really is not our job to tell receivers what some of us > think that receivers should do with the SPF results. >=20 > R's, > John > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From spf2@kitterman.com Tue Feb 5 15:00:56 2013 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 812BF21F85E2 for ; Tue, 5 Feb 2013 15:00:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nky2ZWQ7pgFk for ; Tue, 5 Feb 2013 15:00:55 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B671021F8936 for ; Tue, 5 Feb 2013 15:00:55 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 023BE20E40D6; Tue, 5 Feb 2013 18:00:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360105255; bh=BzBvre+HtS2+nTh2nWHYFg4fh8FZuuWGpZ1aGGs0Hrw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C6HzW5fvfumeSTjsbn0gkIij3v4dStydIrPgBuoknoWbefDyZQ1G4mIUnLSKKT+V2 4G4y8vRBuaAd1QLAmKh9qzwAmdnRdUqTnxijYNmc5d0fywOzbfbQfO4MYm53SEYihz d4cKGRwO836O665+hTfwV0xiIFhhAs2gDz29d3kw= Received: from scott-latitude-e6320.localnet (93.sub-70-195-1.myvzw.com [70.195.1.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A7B4D20E40B2; Tue, 5 Feb 2013 18:00:54 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 18:00:52 -0500 Message-ID: <1410839.1pcvUEaBed@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <18634195.xKHCPc4tqs@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] Ticket #47 domain-spec 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, 05 Feb 2013 23:00:56 -0000 As far as I know, there's been no discussion on the topic, just an initial proposal for resolving an ambiguity in the spec. It's A lookup even when the connection type is IPv6 because DNSxBLs return an A record format. Looking at the two options, I think the rationale (to be clear, I am guessing): 1. A DNS lookup failure here will generally only turn a pass into a temperror, so hiding the error doesn't allow a path to upgrade a result. If a message would otherwise be accepted, it's not worth sending them a 450 just for this. 2. Hiding errors is bad. Scott K On Tuesday, February 05, 2013 01:34:10 PM Murray S. Kucherawy wrote: > Feel free to point me at previous discussion, but why "(even when the > connection type is IPv6)"? > > Shouldn't a DNS error result in a "temp-fail"? > > -MSK > > On Tue, Feb 5, 2013 at 10:00 AM, Scott Kitterman wrote: > > I think this needs discussion before I include one of the two proposed > > solutions in a draft. > > > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/47 > > > > Suggested text: > > bis-06: > > The domain-spec is expanded as per Section 8. The resulting domain > > > > name is > > used for a DNS A RR lookup. If any A record is returned, this mechanism > > matches. The lookup type is A even when the connection type is IPv6. > > > > new: > > The domain-spec is expanded as per Section 8. The resulting domain > > > > name is > > used for a DNS A RR lookup (even when the connection type is IPv6). If any > > A > > record is returned, this mechanism matches, otherwise the mechanism > > doesn't > > match. > > > > or new: > > The domain-spec is expanded as per Section 8. The resulting domain > > > > name is > > used for a DNS A RR lookup (even when the connection type is IPv6). If any > > A > > record is returned, this mechanism matches. In all other cases (no A > > records, > > DNS error, etc.), the mechanism doesn't match. > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > > > > As I read it the second alternative specifies that a DNS error is treated > > as a > > no match, but the first does not. I believe we want the first as we don't > > want > > to hide DNS failures, but I'm not sure. > > > > Scott K > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Tue Feb 5 15:03:02 2013 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 2925221F8605 for ; Tue, 5 Feb 2013 15:03:02 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYrsoDcEQHCy for ; Tue, 5 Feb 2013 15:03:01 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6706221F85FD for ; Tue, 5 Feb 2013 15:03:01 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E4D1F20E40D6; Tue, 5 Feb 2013 18:03:00 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360105380; bh=DM5fdUhoLWxzH2CCg3yVyUqQP71z4aB3GfedZ3yCCS4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IA1Io1ok3X+9mY+rqAJ+3MElCMnMJtXVrgeIuk77UKT+ZJw5eGNSXJpOoRFWx+xpg LUsgyIko8gAvTmLksEv5XdUI39V1wTwhAuTV5ObflkjcXOEWLnJKtac+MW6i6P5tL9 i53kComKoGgGfkPqzbD+Z2oKsJS5AYzV01XIkp1E= Received: from scott-latitude-e6320.localnet (93.sub-70-195-1.myvzw.com [70.195.1.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id AF27520E40B2; Tue, 5 Feb 2013 18:03:00 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 18:02:58 -0500 Message-ID: <2909071.tcQAMypl50@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> <18382376.hIpMDkXD4i@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] Summary of issues for draft-ietf-spfbis-4408bis 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, 05 Feb 2013 23:03:02 -0000 The difference is that the contents of the MX record are under control of the domain owner. The number of PTR records are under control of the owner of the IP address actually making the connection. If we allow for permerror on too many PTR, then that gives someone trying to avoid SPF fail an easy way to turn a fail into a permerror. A similar risk does not exist with MX. Scott K On Tuesday, February 05, 2013 01:35:55 PM Murray S. Kucherawy wrote: > Doesn't the same attack exist if one lists >10 MX records? > > Just wondering why MX isn't getting the same treatment as PTR in the > proposed new text. > > -MSK > > On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman wrote: > > On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote: > > > #43 New requirement for mx: or ptr records > > > > Issue: > > > in section 4.6.4, there is a new requirement that there must not be more > > > than 10 records for mx: or ptr:. This completely wrong for ptr: because > > > a > > > spammer could choose to send spam from a host with more than 10 PTR > > > records, thus forcing a domain's SPF record to return permerror, instead > > > > of > > > > > fail. If anything, more than 10 PTR records should cause the ptr: > > mechanism > > > > > to automatically not-match. It should also be made clear that the %{p} > > > macro is valid no matter how many PTR records are returned. > > > > Proposed new text for 4.6.4 (in my local copy): > > > 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. If more than 10 "mx" records are returned for this > > > further lookup, a permerror MUST be returned. If more than 10 "ptr" > > > > > > records are returned for this further lookup (either due to use of > > > a "ptr" mechanisms, or the %{p} macro) processing MUST be terminated > > > after 10 records. This limit is per mechanism or macro in the > > > record and in addition to the lookup limits above. > > > > Comments please. If no one objects, I'll include it. > > > > Scott K > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From superuser@gmail.com Tue Feb 5 15:50:20 2013 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 DCE8621F88FC for ; Tue, 5 Feb 2013 15:50:19 -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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q47ZsQpopmI1 for ; Tue, 5 Feb 2013 15:50:18 -0800 (PST) Received: from mail-we0-x234.google.com (we-in-x0234.1e100.net [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C9B6D21F8633 for ; Tue, 5 Feb 2013 15:50:16 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id k14so652470wer.11 for ; Tue, 05 Feb 2013 15:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SNW1seXa8t5qO3XY80b9umhPHUQd3x4N6oJhsy4REHc=; b=b/t+2mc64hvpmrapsvUS1Fkj7pAdYES2ITzaXeodw5RRdJ12OHTet3qz93WEMLE+mA bBF3Cq0l/ncWSXNrFK3wZO9v61s08pxqhLlyFJE3GFZUPgJPhBzAIISIZ1O5I2vBFqw9 zSvY9EjUhDiitxh+3i2uMansh7a1G0Sh3TvLki1/aAXUSRMup3r8y5Ikl4CbESCIzw95 mVzmeRJ99oeF5DzvzRA0xw3HcI263Aj4SWk6PEkGNSrjhB6dt9G8sz7LY/HBTWMyiXKa R2c81pDDVPgBqGpbdJbtCLeed5XykB/6b9OUij0mUxz5Rx/RGTX/h2XHAWY8A/0j/Z5X Pk4w== MIME-Version: 1.0 X-Received: by 10.180.73.80 with SMTP id j16mr1509177wiv.5.1360108215559; Tue, 05 Feb 2013 15:50:15 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 15:50:15 -0800 (PST) In-Reply-To: <20130205225156.GA15797@verdi> References: <20130205225156.GA15797@verdi> Date: Tue, 5 Feb 2013 15:50:15 -0800 Message-ID: From: "Murray S. Kucherawy" To: John Leslie Content-Type: multipart/alternative; boundary=f46d043bdf380b67c004d502df0f Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 05 Feb 2013 23:50:20 -0000 --f46d043bdf380b67c004d502df0f Content-Type: text/plain; charset=ISO-8859-1 I think we're straying across the line of local policy again. To my mind, the only justification for a MUST or SHOULD here would be a valid claim that the protocol has failed to operate correctly if you don't reject or mark the message. But that's not true; SPF itself terminates when the "fail" is delivered to whatever asked the question in the first place, and not when some handling action has been selected locally. Saying SHOULD or even MUST add a result header field of some kind if not rejecting is ideal operational advice, but I don't agree that it's part of the protocol proper. -MSK On Tue, Feb 5, 2013 at 2:51 PM, John Leslie wrote: > Hector Santos wrote: > > > > None of which has to do what DESIGN OPTIONS are available for the SPF > > protocol. Its not a vague concept. > > > > Reciever gets an -ALL failure, it can REJECT or MARK the message. > > > > isn't that what RFC 4408 2.5.4 basically stated? > > Yes: > ] > ] 2.5.4. Fail > ] > ] A "Fail" result is an explicit statement that the client is not > ] authorized to use the domain in the given identity. The checking > ] software can choose to mark the mail based on this or to reject the > ] mail outright. > > In the draft, this has become: > ] > ] 2.6.4. Fail > ] > ] A "fail" result is an explicit statement that the client is not > ] authorized to use the domain in the given identity. > > In Section 8, we see: > ] > ] 8.4. Fail > ] > ] A "fail" result is an explicit statement that the client is not > ] authorized to use the domain in the given identity. Disposition of > ] SPF fail messages is a matter of local policy. > ]... > ] If the checking software chooses not to reject the mail during the > ] SMTP transaction, then it SHOULD add a Received-SPF or > ] Authentication-Results header field (see Section 9) to communicate > ] this result to downstream message processors. While this is true for > ] all SPF results, it is of particular importance for "fail" results > ] since the message is explicitly not authorized by the domain owner. > > It seems to me that this is where Hector's problem lies: "SHOULD" > add one of these two headers is less than he read into 4408. > > > All you are basically saying now (reminding the naive), it can DO > NOTHING. > > > > Fine, then say it, but lay it out: > > > > REJECT (already has RFC 2119 semantics) > > MARK (Define it) > > DO NOTHING (Warning against it) > > OTHER (Advise of DOMAIN PUBLISHER expectations) > > The Security Considerations text in question lumps together the > second, third, and fourth of these. > > I think it reasonable to say somewhere (not necessarily in Security > Considerations, that the "SHOULD" in Section 8.4 may not be strong > enough -- that for an SPF "fail" adding one of those headers is a MUST. > > (OTOH, a "SHOULD" is actually a lot stronger than Hector may think: > "SHOULD" is less strong than "MUST" only if the implementor can find > an actual reason that "MUST" is inappropriate. While I can't think of > such a reason, perhaps someone else can...) > > The intent of my proposed text was that a service provider (that > implements SPF at all) might have a business reason to add one of > those headers showing the SPF "fail" and pass the email to the > mail-delivery process. I certainly did not intend that the service > provider might deliver the email without adding such a header. > > I would tend to humor Hector to the extent of mentioning in > Security Considerations that a service provider that marks with > one of the headers mentioned is in accordance with the spec, even > though this exposes a receiver that fails to check those headers > to potential harm. OTOH, I'd be happy with such text in Section 8.4 > instead... > > -- > John Leslie > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d043bdf380b67c004d502df0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think we're straying across the line of local p= olicy again.=A0 To my mind, the only justification for a MUST or SHOULD her= e would be a valid claim that the protocol has failed to operate correctly = if you don't reject or mark the message.=A0 But that's not true; SP= F itself terminates when the "fail" is delivered to whatever aske= d the question in the first place, and not when some handling action has be= en selected locally.

Saying SHOULD or even MUST add a result header field of some kind if no= t rejecting is ideal operational advice, but I don't agree that it'= s part of the protocol proper.
-MSK
<= br>
On Tue, Feb 5, 2013 at 2:51 PM, John Leslie <= span dir=3D"ltr"><john= @jlc.net> wrote:
Hector Santos <hsantos@isdg.net> wrote:
>
> None of which has to do what DESIGN OPTIONS are available for the SPF<= br> > protocol. =A0Its not a vague concept.
>
> =A0Reciever gets an -ALL failure, it can REJECT or MARK the message. >
> isn't that what RFC 4408 2.5.4 basically stated?

=A0 =A0Yes:
]
] 2.5.4. =A0Fail
]
] A "Fail" result is an explicit statement that the client is not=
] authorized to use the domain in the given identity. =A0The checking
] software can choose to mark the mail based on this or to reject the
] mail outright.

=A0 =A0In the draft, this has become:
]
] 2.6.4. =A0Fail
]
] A "fail" result is an explicit statement that the client is not=
] authorized to use the domain in the given identity.

=A0 =A0In Section 8, we see:
]
] 8.4. =A0Fail
]
] A "fail" result is an explicit statement that the client is not=
] authorized to use the domain in the given identity. =A0Disposition of
] =A0SPF fail messages is a matter of local policy.
]...
] If the checking software chooses not to reject the mail during the
] SMTP transaction, then it SHOULD add a Received-SPF or
] Authentication-Results header field (see Section 9) to communicate
] this result to downstream message processors. =A0While this is true for ] all SPF results, it is of particular importance for "fail" resu= lts
] since the message is explicitly not authorized by the domain owner.

=A0 =A0It seems to me that this is where Hector's problem lies: "S= HOULD"
add one of these two headers is less than he read into 4408.

> All you are basically saying now (reminding the naive), it can DO NOTH= ING.
>
> Fine, then say it, but lay it out:
>
> =A0 =A0REJECT =A0 =A0 =A0 =A0(already has RFC 2119 semantics)
> =A0 =A0MARK =A0 =A0 =A0 =A0 =A0(Define it)
> =A0 =A0DO NOTHING =A0 =A0(Warning against it)
> =A0 =A0OTHER =A0 =A0 =A0 =A0 (Advise of DOMAIN PUBLISHER expectations)=

=A0 =A0The Security Considerations text in question lumps together th= e
second, third, and fourth of these.

=A0 =A0I think it reasonable to say somewhere (not necessarily in Security<= br> Considerations, that the "SHOULD" in Section 8.4 may not be stron= g
enough -- that for an SPF "fail" adding one of those headers is a= MUST.

=A0 =A0(OTOH, a "SHOULD" is actually a lot stronger than Hector m= ay think:
"SHOULD" is less strong than "MUST" only if the impleme= ntor can find
an actual reason that "MUST" is inappropriate. While I can't = think of
such a reason, perhaps someone else can...)

=A0 =A0The intent of my proposed text was that a service provider (that
implements SPF at all) might have a business reason to add one of
those headers showing the SPF "fail" and pass the email to the mail-delivery process. I certainly did not intend that the service
provider might deliver the email without adding such a header.

=A0 =A0I would tend to humor Hector to the extent of mentioning in
Security Considerations that a service provider that marks with
one of the headers mentioned is in accordance with the spec, even
though this exposes a receiver that fails to check those headers
to potential harm. OTOH, I'd be happy with such text in Section 8.4
instead...

--
John Leslie <john@jlc.net>
___________________________________= ____________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--f46d043bdf380b67c004d502df0f-- From sm@elandsys.com Tue Feb 5 16:25:40 2013 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 AEB5A21F8691 for ; Tue, 5 Feb 2013 16:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6HeigXnL09W for ; Tue, 5 Feb 2013 16:25:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 427EF21F8625 for ; Tue, 5 Feb 2013 16:25:38 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.138.233]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r160PNia005925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Feb 2013 16:25:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360110335; bh=oaBK/YeZHPhxmpXn6q9aRPaXXn9RqEOF+sM3zMKb19w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TxuFX8bKTP1dcilgY2+u0dbWpt9FCE2UGglxbXFTdPq1fzw5dsDP5KZUHbijvWLVh AdPTPYwellnwi8YFb7xGWoX2K4T5SzohwHK3+z4+mXs2p8DUk2FcGsPw3+dSDafIyI VykcU7r8wHinTxEezWlPTmTr7a6fx2VhgtxxJYfo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1360110335; i=@elandsys.com; bh=oaBK/YeZHPhxmpXn6q9aRPaXXn9RqEOF+sM3zMKb19w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oiSmNpbsSu942NzrZb+7O9Un4TT32bZOAswCGSulK7PzyjbbhMHY+r5ASWeOViON3 RLkzmifYvb1yrpakDhaV90h5OA/p4iDEYvSbjI6jblH/J4E8j01nrG/DSTQ4JhFHVW Q/fmFyMjqWpbNGikQvYsJP3pIYzeTWPMcmh1faAk= Message-Id: <6.2.5.6.2.20130205154310.0a0db178@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Feb 2013 16:24:21 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20130205225156.GA15797@verdi> References: <20130205225156.GA15797@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: John Leslie Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 06 Feb 2013 00:25:40 -0000 At 14:51 05-02-2013, John Leslie wrote: >Hector Santos wrote: > > > > None of which has to do what DESIGN OPTIONS are available for the SPF > > protocol. Its not a vague concept. > > > > Reciever gets an -ALL failure, it can REJECT or MARK the message. > > > > isn't that what RFC 4408 2.5.4 basically stated? > > Yes: >] >] 2.5.4. Fail >] >] A "Fail" result is an explicit statement that the client is not >] authorized to use the domain in the given identity. The checking >] software can choose to mark the mail based on this or to reject the >] mail outright. > > In the draft, this has become: >] >] 2.6.4. Fail >] >] A "fail" result is an explicit statement that the client is not >] authorized to use the domain in the given identity. Thanks to John Leslie for the above. I have been reading the messages on this thread to understand the comments. I read the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg03070.html which is the diff mentioned at http://www.ietf.org/mail-archive/web/spfbis/current/msg03060.html The diff shows the following for Section 2.5.4: "2.5.4. Fail A "fail" result is an explicit statement that the client is not authorized to use the domain in the given identity." There was issue #29 about Section 2.5.4 (see http://www.ietf.org/mail-archive/web/spfbis/current/msg01314.html ). The definition of one of the possible outputs ("fail") has been in the draft for a while. > In Section 8, we see: >] >] 8.4. Fail >] >] A "fail" result is an explicit statement that the client is not >] authorized to use the domain in the given identity. Disposition of >] SPF fail messages is a matter of local policy. >]... >] If the checking software chooses not to reject the mail during the >] SMTP transaction, then it SHOULD add a Received-SPF or >] Authentication-Results header field (see Section 9) to communicate >] this result to downstream message processors. While this is true for >] all SPF results, it is of particular importance for "fail" results >] since the message is explicitly not authorized by the domain owner. > > It seems to me that this is where Hector's problem lies: "SHOULD" >add one of these two headers is less than he read into 4408. I do not see any "SHOULD" for "mark" in Section 2.5.4 of RFC 4408. As a quick reaction, the "SHOULD" seems to have been added to clarify the "mark". I have not tracked the history of this change yet. Is the problem that the reorganization changed the substance of -08 (see http://www.ietf.org/mail-archive/web/spfbis/current/msg03053.html )? Regards, S. Moonesamy SPFBIS WG co-chair From superuser@gmail.com Tue Feb 5 18:41:32 2013 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 CB58421F894D for ; Tue, 5 Feb 2013 18:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOe4cg5+Zqkc for ; Tue, 5 Feb 2013 18:41:32 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F55921F8566 for ; Tue, 5 Feb 2013 18:41:31 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr12so703817wgb.11 for ; Tue, 05 Feb 2013 18:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KxF/25elJbSfmVDTCWRZqjKwUWg39XK5pFPDPzw45l0=; b=Z3FTwOJ8NtcTpQzDz4EzadRlDtZMRygeS627U2rCzYei5gwpYoSFekW6BYVU5aqhg+ DlH6fsqKWgB2jIBEko3dKOicP32fLuOq+QuZRbrnCYzCMyGemFBWxYpgbZgpcTlhDBr4 u3HZdt4gXJIxjrfMGD9o/bMpPMDnitC3VybNvEzeM0g4Y4faxdm3XkTUJcGthArwXHF5 0EZA8Hs4/uV7kIj03YFKmJtsMeQUB2cjCDZvqoR795R0Kuv7zt/ko+0k0KHrnlPBw5VG SFYX6qgYXymcQzcO36IKtiMq70HcZUeS8GMVODUqlFhNfFSGkKjjH2a7LGn7aLCoFcRF ljhw== MIME-Version: 1.0 X-Received: by 10.180.73.80 with SMTP id j16mr2088372wiv.5.1360118490736; Tue, 05 Feb 2013 18:41:30 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 18:41:30 -0800 (PST) In-Reply-To: <6.2.5.6.2.20130205154310.0a0db178@resistor.net> References: <20130205225156.GA15797@verdi> <6.2.5.6.2.20130205154310.0a0db178@resistor.net> Date: Tue, 5 Feb 2013 18:41:30 -0800 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d043bdf387e26ff04d505434c Cc: "spfbis@ietf.org" , John Leslie Subject: Re: [spfbis] Delivering Mail Producing a 'Fail' Result - wasRe:Fwd:New Version Notification for draft-ietf-spfbis-4408bis-09.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, 06 Feb 2013 02:41:32 -0000 --f46d043bdf387e26ff04d505434c Content-Type: text/plain; charset=ISO-8859-1 I think the SHOULD included in the new Section 8.4 is there mainly to advise that the two proposed "marking" methods are the de facto standard ways to accomplish the relaying of results to downstream components, rather than suggesting that SPF interoperability is jeopardized if one doesn't do so without a very good reason. Put another way: "If you're not going to reject, then you need to use Received-SPF or Authentication-Results, unless you have a very good reason not to", but not "SPF is broken if you don't do this." Otherwise, the SHOULD for "mark" (which is really "add a header field") is certainly good general operational advice, but not part of the actual protocol, and as such, we might be challenged about including it in the -bis draft, because it doesn't affect the interoperability of SPF as a protocol between a domain owner and the receiving MTA. There are, however, operational environments where doing "none of the above" makes sense; neither "marking" in the ways described in the -bis draft nor rejection makes sense there, yet the SPF result is still used as input to the final handling decision via some out-of-band transmission of the result to the decision component. We might consider replacing the SHOULD with a note that "marking" is best accomplished by adding a header field designed for that purpose, as described in Section 9. -MSK On Tue, Feb 5, 2013 at 4:24 PM, S Moonesamy wrote: > At 14:51 05-02-2013, John Leslie wrote: > >> Hector Santos wrote: >> > >> > None of which has to do what DESIGN OPTIONS are available for the SPF >> > protocol. Its not a vague concept. >> > >> > Reciever gets an -ALL failure, it can REJECT or MARK the message. >> > >> > isn't that what RFC 4408 2.5.4 basically stated? >> >> Yes: >> ] >> ] 2.5.4. Fail >> ] >> ] A "Fail" result is an explicit statement that the client is not >> ] authorized to use the domain in the given identity. The checking >> ] software can choose to mark the mail based on this or to reject the >> ] mail outright. >> >> In the draft, this has become: >> ] >> ] 2.6.4. Fail >> ] >> ] A "fail" result is an explicit statement that the client is not >> ] authorized to use the domain in the given identity. >> > > Thanks to John Leslie for the above. I have been reading the messages on > this thread to understand the comments. > > I read the message at http://www.ietf.org/mail-** > archive/web/spfbis/current/**msg03070.htmlwhich is the diff mentioned at > http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03060.html > > The diff shows the following for Section 2.5.4: > > "2.5.4. Fail > > A "fail" result is an explicit statement that the client is not > authorized to use the domain in the given identity." > > There was issue #29 about Section 2.5.4 (see http://www.ietf.org/mail-** > archive/web/spfbis/current/**msg01314.html). > > The definition of one of the possible outputs ("fail") has been in the > draft for a while. > > > In Section 8, we see: >> ] >> ] 8.4. Fail >> ] >> ] A "fail" result is an explicit statement that the client is not >> ] authorized to use the domain in the given identity. Disposition of >> ] SPF fail messages is a matter of local policy. >> ]... >> ] If the checking software chooses not to reject the mail during the >> ] SMTP transaction, then it SHOULD add a Received-SPF or >> ] Authentication-Results header field (see Section 9) to communicate >> ] this result to downstream message processors. While this is true for >> ] all SPF results, it is of particular importance for "fail" results >> ] since the message is explicitly not authorized by the domain owner. >> >> It seems to me that this is where Hector's problem lies: "SHOULD" >> add one of these two headers is less than he read into 4408. >> > > I do not see any "SHOULD" for "mark" in Section 2.5.4 of RFC 4408. As a > quick reaction, the "SHOULD" seems to have been added to clarify the > "mark". I have not tracked the history of this change yet. > > Is the problem that the reorganization changed the substance of -08 (see > http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03053.html)? > > Regards, > S. Moonesamy > SPFBIS WG co-chair > > ______________________________**_________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/**listinfo/spfbis > --f46d043bdf387e26ff04d505434c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think the SHOULD included in the new Section 8.4 is= there mainly to advise that the two proposed "marking" methods a= re the de facto standard ways to accomplish the relaying of results to down= stream components, rather than suggesting that SPF interoperability is jeop= ardized if one doesn't do so without a very good reason.=A0 Put another= way: "If you're not going to reject, then you need to use Receive= d-SPF or Authentication-Results, unless you have a very good reason not to&= quot;, but not "SPF is broken if you don't do this."=A0 Other= wise, the SHOULD for "mark" (which is really "add a header f= ield") is certainly good general operational advice, but not part of t= he actual protocol, and as such, we might be challenged about including it = in the -bis draft, because it doesn't affect the interoperability of SP= F as a protocol between a domain owner and the receiving MTA.

There are, however, operational environments where doing &qu= ot;none of the above" makes sense; neither "marking" in the = ways described in the -bis draft nor rejection makes sense there, yet the S= PF result is still used as input to the final handling decision via some ou= t-of-band transmission of the result to the decision component.

We might consider replacing the SHOULD with a note that &quo= t;marking" is best accomplished by adding a header field designed for = that purpose, as described in Section 9.

-MSK



On Tue, Feb 5, 2013 at 4:24 PM, S Moonesamy <<= a href=3D"mailto:sm+ietf@elandsys.com" target=3D"_blank">sm+ietf@elandsys.c= om> wrote:
At 14:51 05-02-2013, Joh= n Leslie wrote:
Hector Santos <hsa= ntos@isdg.net> wrote:
>
> None of which has to do what DESIGN OPTIONS are available for the SPF<= br> > protocol. =A0Its not a vague concept.
>
> =A0Reciever gets an -ALL failure, it can REJECT or MARK the message. >
> isn't that what RFC 4408 2.5.4 basically stated?

=A0 =A0Yes:
]
] 2.5.4. =A0Fail
]
] A "Fail" result is an explicit statement that the client is not=
] authorized to use the domain in the given identity. =A0The checking
] software can choose to mark the mail based on this or to reject the
] mail outright.

=A0 =A0In the draft, this has become:
]
] 2.6.4. =A0Fail
]
] A "fail" result is an explicit statement that the client is not=
] authorized to use the domain in the given identity.

Thanks to John Leslie for the above. =A0I have been reading the messages on= this thread to understand the comments.

I read the message at http://www.ietf.org/mail-= archive/web/spfbis/current/msg03070.html which is the diff menti= oned at http://www.ietf.org/mail-archive/web/sp= fbis/current/msg03060.html

The diff shows the following for Section 2.5.4:

=A0 "2.5.4. Fail

=A0 =A0A "fail" result is an explicit statement that the client i= s not
=A0 =A0authorized to use the domain in the given identity."

There was issue #29 about Section 2.5.4 (see http://ww= w.ietf.org/mail-archive/web/spfbis/current/msg01314.html = ).

The definition of one of the possible outputs ("fail") has been i= n the draft for a while.


=A0 =A0In Section 8, we see:
]
] 8.4. =A0Fail
]
] A "fail" result is an explicit statement that the client is not=
] authorized to use the domain in the given identity. =A0Disposition of
] =A0SPF fail messages is a matter of local policy.
]...
] If the checking software chooses not to reject the mail during the
] SMTP transaction, then it SHOULD add a Received-SPF or
] Authentication-Results header field (see Section 9) to communicate
] this result to downstream message processors. =A0While this is true for ] all SPF results, it is of particular importance for "fail" resu= lts
] since the message is explicitly not authorized by the domain owner.

=A0 =A0It seems to me that this is where Hector's problem lies: "S= HOULD"
add one of these two headers is less than he read into 4408.

I do not see any "SHOULD" for "mark" in Section 2.5.4 o= f RFC 4408. =A0As a quick reaction, the "SHOULD" seems to have be= en added to clarify the "mark". =A0I have not tracked the history= of this change yet.

Is the problem that the reorganization changed the substance of -08 (see http://www.ietf.org/mail-archive/web/spfbis/curre= nt/msg03053.html )?

Regards,
S. Moonesamy
SPFBIS WG co-chair =A0

_______________________________________________
spfbis mailing list
spfbis@ietf.org = https://www.ietf.org/mailman/listinfo/spfbis

--f46d043bdf387e26ff04d505434c-- From superuser@gmail.com Tue Feb 5 19:08:38 2013 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 73F0D21F89D5 for ; Tue, 5 Feb 2013 19:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2P879B5KOms for ; Tue, 5 Feb 2013 19:08:36 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD5121F8984 for ; Tue, 5 Feb 2013 19:08:36 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hm6so1077025wib.8 for ; Tue, 05 Feb 2013 19:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7bb5uM0bDh2A51Yn05FAeXvmQTqKihZVcID2ri0B210=; b=iRoNHB/lAVpfXPMgTMyJf2boKbU6zw9BXH9Z8NAdbUQslatp03JUwLzv5b0/joxaSv vd9yyyPKyP+9yhdV5VfyeufioRBY4heOmwBlkM8snMHJAgcECu1OpV0cGjS+A0jXuNKD HYVSaHmF8Nsb34xijwwqOXBb+GxyvpA0rG8KzM+Azs2Wwc/+0Rp80gZAFTGKSqFcafFO 3XQeXH+684HdYmUtATWBD7JuV8badi523uMs15Da6XPAGUb2K6f1Tx90axcXjjMcE74p pOmbFmu3Q6sWjoo09dSMh7p2dV4PDexeY4pqP1M1AowRq0maPxYve2ML4k+dvj6cEK3v Zn/g== MIME-Version: 1.0 X-Received: by 10.194.59.40 with SMTP id w8mr46885662wjq.51.1360120115578; Tue, 05 Feb 2013 19:08:35 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 19:08:35 -0800 (PST) In-Reply-To: <2909071.tcQAMypl50@scott-latitude-e6320> References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> <18382376.hIpMDkXD4i@scott-latitude-e6320> <2909071.tcQAMypl50@scott-latitude-e6320> Date: Tue, 5 Feb 2013 19:08:35 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7b86d68c5746eb04d505a40b Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 06 Feb 2013 03:08:38 -0000 --047d7b86d68c5746eb04d505a40b Content-Type: text/plain; charset=ISO-8859-1 Got it. Could we massage that paragraph in to explain the context of the rule being imposed? -MSK On Tue, Feb 5, 2013 at 3:02 PM, Scott Kitterman wrote: > The difference is that the contents of the MX record are under control of > the > domain owner. The number of PTR records are under control of the owner of > the > IP address actually making the connection. If we allow for permerror on > too > many PTR, then that gives someone trying to avoid SPF fail an easy way to > turn > a fail into a permerror. A similar risk does not exist with MX. > > Scott K > > On Tuesday, February 05, 2013 01:35:55 PM Murray S. Kucherawy wrote: > > Doesn't the same attack exist if one lists >10 MX records? > > > > Just wondering why MX isn't getting the same treatment as PTR in the > > proposed new text. > > > > -MSK > > > > On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman > wrote: > > > On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote: > > > > #43 New requirement for mx: or ptr records > > > > > > Issue: > > > > in section 4.6.4, there is a new requirement that there must not be > more > > > > than 10 records for mx: or ptr:. This completely wrong for ptr: > because > > > > a > > > > spammer could choose to send spam from a host with more than 10 PTR > > > > records, thus forcing a domain's SPF record to return permerror, > instead > > > > > > of > > > > > > > fail. If anything, more than 10 PTR records should cause the ptr: > > > mechanism > > > > > > > to automatically not-match. It should also be made clear that the > %{p} > > > > macro is valid no matter how many PTR records are returned. > > > > > > Proposed new text for 4.6.4 (in my local copy): > > > > 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. If more than 10 "mx" records are returned for this > > > > further lookup, a permerror MUST be returned. If more than 10 "ptr" > > > > > > > > records are returned for this further lookup (either due to use of > > > > a "ptr" mechanisms, or the %{p} macro) processing MUST be terminated > > > > after 10 records. This limit is per mechanism or macro in the > > > > record and in addition to the lookup limits above. > > > > > > Comments please. If no one objects, I'll include it. > > > > > > Scott K > > > _______________________________________________ > > > spfbis mailing list > > > spfbis@ietf.org > > > https://www.ietf.org/mailman/listinfo/spfbis > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --047d7b86d68c5746eb04d505a40b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Got it.=A0 Could we massage that paragraph in to explain t= he context of the rule being imposed?

-MS= K

On Tue= , Feb 5, 2013 at 3:02 PM, Scott Kitterman <spf2@kitterman.com> wrote:
The difference is that the contents of the M= X record are under control of the
domain owner. =A0The number of PTR records are under control of the owner o= f the
IP address actually making the connection. =A0If we allow for permerror on = too
many PTR, then that gives someone trying to avoid SPF fail an easy way to t= urn
a fail into a permerror. =A0A similar risk does not exist with MX.

Scott K

On Tuesday, February 05, 2013 01:35:55 PM Murray S. Kucherawy wrote:
> Doesn't the same attack exist if one lists >10 MX records?
>
> Just wondering why MX isn't getting the same treatment as PTR in t= he
> proposed new text.
>
> -MSK
>
> On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman <spf2@kitterman.com> wrote:
> > On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote:
> > > #43 New requirement for mx: or ptr records
> >
> > Issue:
> > > in section 4.6.4, there is a new requirement that there must= not be more
> > > than 10 records for mx: or ptr:. This completely wrong for p= tr: because
> > > a
> > > spammer could choose to send spam from a host with more than= 10 PTR
> > > records, thus forcing a domain's SPF record to return pe= rmerror, instead
> >
> > of
> >
> > > fail. If anything, more than 10 PTR records should cause the= ptr:
> > mechanism
> >
> > > to automatically not-match. It should also be made clear tha= t the %{p}
> > > macro is valid no matter how many PTR records are returned.<= br> > >
> > Proposed new text for 4.6.4 (in my local copy):
> > > =A0When evaluating the "mx" and "ptr" me= chanisms, or the %{p} macro,
> > > =A0there MUST be a limit of no more than 10 MX or PTR RRs lo= oked up
> > > =A0and checked. =A0If more than 10 "mx" records ar= e returned for this
> > > =A0further lookup, a permerror MUST be returned. =A0If more = than 10 "ptr"
> > >
> > > records are returned for this further lookup (either due to = use of
> > > a "ptr" mechanisms, or the %{p} macro) processing = MUST be terminated
> > > after 10 records. =A0This limit is per mechanism or macro in= the
> > > record and in addition to the lookup limits above.
> >
> > Comments please. =A0If no one objects, I'll include it.
> >
> > Scott K
> > _______________________________________________
> > spfbis mailing list
> > spfbis@ietf.org
> > https://www.ietf.org/mailman/listinfo/spfbis
_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--047d7b86d68c5746eb04d505a40b-- From spf2@kitterman.com Tue Feb 5 19:13:36 2013 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 C1C1721F8A1C for ; Tue, 5 Feb 2013 19:13:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6AYJf1Wl-5C for ; Tue, 5 Feb 2013 19:13:35 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BE79321F8881 for ; Tue, 5 Feb 2013 19:13:35 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0042C20E410F; Tue, 5 Feb 2013 22:13:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360120415; bh=6HUNPfnluiW/oM2fAmg61ZjF4KTqO8sq4Hcyv4wFeqA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GM+2BV8wZSsXqsOFX0BRhiDXbm+6e95Rw2KuzaWA/1xmAI/2H/1fJ6o58ujfw2BtV sf7CRfqGr6DXiz2NRoJeUeHQPgIk3c7QLB7GIJtQyZR4+m3sTvnkmSHzHNX2cl6fXW MrpFIEBmfDOYyz3T+yFrqd+k5rJH7wwjrhnq/Qo0= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A970020E40B2; Tue, 5 Feb 2013 22:13:34 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 05 Feb 2013 22:13:32 -0500 Message-ID: <2168659.7lAyFt0zqY@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> <2909071.tcQAMypl50@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] Summary of issues for draft-ietf-spfbis-4408bis 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, 06 Feb 2013 03:13:36 -0000 Sure. Do you have a suggestion? Scott K On Tuesday, February 05, 2013 07:08:35 PM Murray S. Kucherawy wrote: > Got it. Could we massage that paragraph in to explain the context of the > rule being imposed? > > -MSK > > On Tue, Feb 5, 2013 at 3:02 PM, Scott Kitterman wrote: > > The difference is that the contents of the MX record are under control of > > the > > domain owner. The number of PTR records are under control of the owner of > > the > > IP address actually making the connection. If we allow for permerror on > > too > > many PTR, then that gives someone trying to avoid SPF fail an easy way to > > turn > > a fail into a permerror. A similar risk does not exist with MX. > > > > Scott K > > > > On Tuesday, February 05, 2013 01:35:55 PM Murray S. Kucherawy wrote: > > > Doesn't the same attack exist if one lists >10 MX records? > > > > > > Just wondering why MX isn't getting the same treatment as PTR in the > > > proposed new text. > > > > > > -MSK > > > > > > On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman > > > > wrote: > > > > On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote: > > > > > #43 New requirement for mx: or ptr records > > > > > > > > Issue: > > > > > in section 4.6.4, there is a new requirement that there must not be > > > > more > > > > > > > than 10 records for mx: or ptr:. This completely wrong for ptr: > > because > > > > > > > a > > > > > spammer could choose to send spam from a host with more than 10 PTR > > > > > records, thus forcing a domain's SPF record to return permerror, > > > > instead > > > > > > of > > > > > > > > > fail. If anything, more than 10 PTR records should cause the ptr: > > > > mechanism > > > > > > > > > to automatically not-match. It should also be made clear that the > > > > %{p} > > > > > > > macro is valid no matter how many PTR records are returned. > > > > > > > > Proposed new text for 4.6.4 (in my local copy): > > > > > 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. If more than 10 "mx" records are returned for this > > > > > further lookup, a permerror MUST be returned. If more than 10 > > > > > "ptr" > > > > > > > > > > records are returned for this further lookup (either due to use of > > > > > a "ptr" mechanisms, or the %{p} macro) processing MUST be terminated > > > > > after 10 records. This limit is per mechanism or macro in the > > > > > record and in addition to the lookup limits above. > > > > > > > > Comments please. If no one objects, I'll include it. > > > > > > > > Scott K > > > > _______________________________________________ > > > > spfbis mailing list > > > > spfbis@ietf.org > > > > https://www.ietf.org/mailman/listinfo/spfbis > > > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From superuser@gmail.com Tue Feb 5 20:14:20 2013 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 BAC3521F8A00 for ; Tue, 5 Feb 2013 20:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HIps+2N4wqA for ; Tue, 5 Feb 2013 20:14:19 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 492CF21F89FD for ; Tue, 5 Feb 2013 20:14:19 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ez12so1108173wid.12 for ; Tue, 05 Feb 2013 20:14:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wmWaNZDWRnDOR2NkUs6BdWX77xrRHecV2MO6TMDOwNE=; b=XIkQYZMHdbpBMQqt12iR3WCiTKRx2Y4C8UQmzj4amk8ZDvJMAcgxnEJSnXmgdZpH4o hwM+HXna/VOytyVB3Xf72dI8TKmWRgOUzL7q/tfxT0sLJAdiNZpQ6cnoYAwjW7gPO/Ar 8xt0/e0yEnzTRxjywd60z2W0+f2xUd2LNJgCIZNEFVqcxwn2wQHXUhLVbTs/6ztRiqHJ AwICvxckm4MhSvpCnn3pr7vdOWyElu2+28BQfUnXpOU/dG2Fd3DM2QRINSykfXXg4/gg E7ye5Okxk7GQvprOgbM4KBFKVCc9Reoa0W1kjQGJLAG8Yu1WeQaxjpyeGbzMTgB5d3fb vDkg== MIME-Version: 1.0 X-Received: by 10.195.13.11 with SMTP id eu11mr47084763wjd.39.1360124054185; Tue, 05 Feb 2013 20:14:14 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 20:14:13 -0800 (PST) In-Reply-To: <2168659.7lAyFt0zqY@scott-latitude-e6320> References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> <2909071.tcQAMypl50@scott-latitude-e6320> <2168659.7lAyFt0zqY@scott-latitude-e6320> Date: Tue, 5 Feb 2013 20:14:13 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bd91a8419a6bd04d5068f15 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 06 Feb 2013 04:14:20 -0000 --047d7bd91a8419a6bd04d5068f15 Content-Type: text/plain; charset=ISO-8859-1 How about: When evaluating the "mx" mechanism, the number of MX resource records queried MUST NOT exceed 10. If the evaluation of an "mx" mechanism results in more than 10 resource records being , the "mx" mechanism MUST produce a "permerror" result (see Section xxx). When evaluating the "ptr" mechanism, the number of PTR resource records queried MUST NOT exceed 10. If the evaluation of a "ptr" mechanism results in more than 10 resource records being returned, all records other than the first 10 MUST be ignored. The reason for the disparity is that the set of and contents of the MX record are under control of the domain owner, while the set of and contents of PTR records are under control of the owner of the IP address actually making the connection. These limits are per mechanism or macro in the record, and are in addition to the lookup limits specified above. Could we change "10" to "a fixed but possibly configurable limit", and indicate that most implementations use 10 as that limit? 10 is effectively arbitrary, unless studies have shown that it's the best answer. Also, the ignoring of PTR replies beyond the first 10 renders the protocol non-deterministic given that replies come back in a random order. Are we okay with that? -MSK On Tue, Feb 5, 2013 at 7:13 PM, Scott Kitterman wrote: > Sure. Do you have a suggestion? > > Scott K > > On Tuesday, February 05, 2013 07:08:35 PM Murray S. Kucherawy wrote: > > Got it. Could we massage that paragraph in to explain the context of the > > rule being imposed? > > > > -MSK > > > > On Tue, Feb 5, 2013 at 3:02 PM, Scott Kitterman > wrote: > > > The difference is that the contents of the MX record are under control > of > > > the > > > domain owner. The number of PTR records are under control of the > owner of > > > the > > > IP address actually making the connection. If we allow for permerror > on > > > too > > > many PTR, then that gives someone trying to avoid SPF fail an easy way > to > > > turn > > > a fail into a permerror. A similar risk does not exist with MX. > > > > > > Scott K > > > > > > On Tuesday, February 05, 2013 01:35:55 PM Murray S. Kucherawy wrote: > > > > Doesn't the same attack exist if one lists >10 MX records? > > > > > > > > Just wondering why MX isn't getting the same treatment as PTR in the > > > > proposed new text. > > > > > > > > -MSK > > > > > > > > On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman > > > > > > wrote: > > > > > On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote: > > > > > > #43 New requirement for mx: or ptr records > > > > > > > > > > Issue: > > > > > > in section 4.6.4, there is a new requirement that there must not > be > > > > > > more > > > > > > > > > than 10 records for mx: or ptr:. This completely wrong for ptr: > > > because > > > > > > > > > a > > > > > > spammer could choose to send spam from a host with more than 10 > PTR > > > > > > records, thus forcing a domain's SPF record to return permerror, > > > > > > instead > > > > > > > > of > > > > > > > > > > > fail. If anything, more than 10 PTR records should cause the ptr: > > > > > mechanism > > > > > > > > > > > to automatically not-match. It should also be made clear that the > > > > > > %{p} > > > > > > > > > macro is valid no matter how many PTR records are returned. > > > > > > > > > > Proposed new text for 4.6.4 (in my local copy): > > > > > > 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. If more than 10 "mx" records are returned for this > > > > > > further lookup, a permerror MUST be returned. If more than 10 > > > > > > "ptr" > > > > > > > > > > > > records are returned for this further lookup (either due to use > of > > > > > > a "ptr" mechanisms, or the %{p} macro) processing MUST be > terminated > > > > > > after 10 records. This limit is per mechanism or macro in the > > > > > > record and in addition to the lookup limits above. > > > > > > > > > > Comments please. If no one objects, I'll include it. > > > > > > > > > > Scott K > > > > > _______________________________________________ > > > > > spfbis mailing list > > > > > spfbis@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/spfbis > > > > > > _______________________________________________ > > > spfbis mailing list > > > spfbis@ietf.org > > > https://www.ietf.org/mailman/listinfo/spfbis > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --047d7bd91a8419a6bd04d5068f15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
How about:

When evaluating the "mx" = mechanism, the number of MX resource records queried MUST NOT exceed 10.=A0= If the evaluation of an "mx" mechanism results in more than 10 r= esource records being <returned? queried?>, the "mx" mechan= ism MUST produce a "permerror" result (see Section xxx).

When evaluating the "ptr" mechanism, the number of PTR = resource records queried MUST NOT exceed 10.=A0 If the evaluation of a &quo= t;ptr" mechanism results in more than 10 resource records being return= ed, all records other than the first 10 MUST be ignored.

The reason for the disparity is that the set of and contents of the MX = record are under control of the domain owner, while the set of and contents= of PTR records are under control of the owner of the IP address actually m= aking the connection.

These limits are per mechanism or macro in the record, and ar= e in addition to the lookup limits specified above.

<s= nip>

Could we change "10" to "a fixed b= ut possibly configurable limit", and indicate that most implementation= s use 10 as that limit?=A0 10 is effectively arbitrary, unless studies have= shown that it's the best answer.

Also, the ignoring of PTR replies beyond the first 10 render= s the protocol non-deterministic given that replies come back in a random o= rder.=A0 Are we okay with that?

-MSK


O= n Tue, Feb 5, 2013 at 7:13 PM, Scott Kitterman <spf2@kitterman.com>= ; wrote:
Sure. =A0Do you have a suggestion?

Scott K

On Tuesday, February 05, 2013 07:08:35 PM Murray S. Kucherawy wrote:
> Got it. =A0Could we massage that paragraph in to explain the context o= f the
> rule being imposed?
>
> -MSK
>
> On Tue, Feb 5, 2013 at 3:02 PM, Scott Kitterman <spf2@kitterman.com> wrote:
> > The difference is that the contents of the MX record are under co= ntrol of
> > the
> > domain owner. =A0The number of PTR records are under control of t= he owner of
> > the
> > IP address actually making the connection. =A0If we allow for per= merror on
> > too
> > many PTR, then that gives someone trying to avoid SPF fail an eas= y way to
> > turn
> > a fail into a permerror. =A0A similar risk does not exist with MX= .
> >
> > Scott K
> >
> > On Tuesday, February 05, 2013 01:35:55 PM Murray S. Kucherawy wro= te:
> > > Doesn't the same attack exist if one lists >10 MX rec= ords?
> > >
> > > Just wondering why MX isn't getting the same treatment a= s PTR in the
> > > proposed new text.
> > >
> > > -MSK
> > >
> > > On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman <spf2@kitterman.com>
> >
> > wrote:
> > > > On Thursday, January 31, 2013 06:02:53 AM S Moonesamy w= rote:
> > > > > #43 New requirement for mx: or ptr records
> > > >
> > > > Issue:
> > > > > in section 4.6.4, there is a new requirement that = there must not be
> >
> > more
> >
> > > > > than 10 records for mx: or ptr:. This completely w= rong for ptr:
> > because
> >
> > > > > a
> > > > > spammer could choose to send spam from a host with= more than 10 PTR
> > > > > records, thus forcing a domain's SPF record to= return permerror,
> >
> > instead
> >
> > > > of
> > > >
> > > > > fail. If anything, more than 10 PTR records should= cause the ptr:
> > > > mechanism
> > > >
> > > > > to automatically not-match. It should also be made= clear that the
> >
> > %{p}
> >
> > > > > macro is valid no matter how many PTR records are = returned.
> > > >
> > > > Proposed new text for 4.6.4 (in my local copy):
> > > > > =A0When evaluating the "mx" and "pt= r" mechanisms, or the %{p} macro,
> > > > > =A0there MUST be a limit of no more than 10 MX or = PTR RRs looked up
> > > > > =A0and checked. =A0If more than 10 "mx" = records are returned for this
> > > > > =A0further lookup, a permerror MUST be returned. = =A0If more than 10
> > > > > =A0"ptr"
> > > > >
> > > > > records are returned for this further lookup (eith= er due to use of
> > > > > a "ptr" mechanisms, or the %{p} macro) p= rocessing MUST be terminated
> > > > > after 10 records. =A0This limit is per mechanism o= r macro in the
> > > > > record and in addition to the lookup limits above.=
> > > >
> > > > Comments please. =A0If no one objects, I'll include= it.
> > > >
> > > > Scott K
> > > > _______________________________________________
> > > > spfbis mailing list
> > > > spfbis@ietf.org<= br> > > > > https://www.ietf.org/mailman/listinfo/spfbis
> >
> > _______________________________________________
> > spfbis mailing list
> > spfbis@ietf.org
> > https://www.ietf.org/mailman/listinfo/spfbis
_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--047d7bd91a8419a6bd04d5068f15-- From superuser@gmail.com Tue Feb 5 20:17:14 2013 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 31CF121F8519 for ; Tue, 5 Feb 2013 20:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4e3dkzFNgbwI for ; Tue, 5 Feb 2013 20:17:13 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D128021F84B2 for ; Tue, 5 Feb 2013 20:17:12 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr12so742832wgb.11 for ; Tue, 05 Feb 2013 20:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GpgvJojErJt8GvAk0CciVBfNXrACVpHH2/iMzo+Rdyw=; b=HCsiNKJdTheqYSWfKOPsE2/XCBoIOzVBcmYLGBEnORJrGoomsmYHMcOLpDqSMixpew OWhq+jud/ZgNTri7UtEvGCDEKQt7NBJzWoDPAsoxo8Qyrpl5WSFuf5BWNGCz4isnYOtN 8HnWuJoFM+qkKx4nG/0elkUqoPjpw+ZrdqmQDSDsrUNVKhzUe8cPiuUu1GGGHdCSDz/+ gge6slbGEbrPQRUV+IGSmLlZzFAO1Qyoh0tDrUYjeIJ26MjrVhBvacrnxmNu4jX8x60y FB0sPOf2y0qptdwvniuOrMZvM1cGBn2zmKsCe2XWjSfIn9uZSLTU/sV994q02Bs9S0W7 8f7g== MIME-Version: 1.0 X-Received: by 10.180.108.3 with SMTP id hg3mr1817745wib.33.1360124232023; Tue, 05 Feb 2013 20:17:12 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 20:17:11 -0800 (PST) In-Reply-To: References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> <2909071.tcQAMypl50@scott-latitude-e6320> <2168659.7lAyFt0zqY@scott-latitude-e6320> Date: Tue, 5 Feb 2013 20:17:11 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=e89a8f3ba6e3b33d3204d5069914 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 06 Feb 2013 04:17:14 -0000 --e89a8f3ba6e3b33d3204d5069914 Content-Type: text/plain; charset=ISO-8859-1 ...except with the %{p} stuff folded in, sorry about that. On Tue, Feb 5, 2013 at 8:14 PM, Murray S. Kucherawy wrote: > How about: > > When evaluating the "mx" mechanism, the number of MX resource records > queried MUST NOT exceed 10. If the evaluation of an "mx" mechanism results > in more than 10 resource records being , the "mx" > mechanism MUST produce a "permerror" result (see Section xxx). > > When evaluating the "ptr" mechanism, the number of PTR resource records > queried MUST NOT exceed 10. If the evaluation of a "ptr" mechanism results > in more than 10 resource records being returned, all records other than the > first 10 MUST be ignored. > > The reason for the disparity is that the set of and contents of the MX > record are under control of the domain owner, while the set of and contents > of PTR records are under control of the owner of the IP address actually > making the connection. > > These limits are per mechanism or macro in the record, and are in addition > to the lookup limits specified above. > > > > Could we change "10" to "a fixed but possibly configurable limit", and > indicate that most implementations use 10 as that limit? 10 is effectively > arbitrary, unless studies have shown that it's the best answer. > > Also, the ignoring of PTR replies beyond the first 10 renders the protocol > non-deterministic given that replies come back in a random order. Are we > okay with that? > > -MSK > > > On Tue, Feb 5, 2013 at 7:13 PM, Scott Kitterman wrote: > >> Sure. Do you have a suggestion? >> >> Scott K >> >> On Tuesday, February 05, 2013 07:08:35 PM Murray S. Kucherawy wrote: >> > Got it. Could we massage that paragraph in to explain the context of >> the >> > rule being imposed? >> > >> > -MSK >> > >> > On Tue, Feb 5, 2013 at 3:02 PM, Scott Kitterman >> wrote: >> > > The difference is that the contents of the MX record are under >> control of >> > > the >> > > domain owner. The number of PTR records are under control of the >> owner of >> > > the >> > > IP address actually making the connection. If we allow for permerror >> on >> > > too >> > > many PTR, then that gives someone trying to avoid SPF fail an easy >> way to >> > > turn >> > > a fail into a permerror. A similar risk does not exist with MX. >> > > >> > > Scott K >> > > >> > > On Tuesday, February 05, 2013 01:35:55 PM Murray S. Kucherawy wrote: >> > > > Doesn't the same attack exist if one lists >10 MX records? >> > > > >> > > > Just wondering why MX isn't getting the same treatment as PTR in the >> > > > proposed new text. >> > > > >> > > > -MSK >> > > > >> > > > On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman > > >> > > >> > > wrote: >> > > > > On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote: >> > > > > > #43 New requirement for mx: or ptr records >> > > > > >> > > > > Issue: >> > > > > > in section 4.6.4, there is a new requirement that there must >> not be >> > > >> > > more >> > > >> > > > > > than 10 records for mx: or ptr:. This completely wrong for ptr: >> > > because >> > > >> > > > > > a >> > > > > > spammer could choose to send spam from a host with more than 10 >> PTR >> > > > > > records, thus forcing a domain's SPF record to return permerror, >> > > >> > > instead >> > > >> > > > > of >> > > > > >> > > > > > fail. If anything, more than 10 PTR records should cause the >> ptr: >> > > > > mechanism >> > > > > >> > > > > > to automatically not-match. It should also be made clear that >> the >> > > >> > > %{p} >> > > >> > > > > > macro is valid no matter how many PTR records are returned. >> > > > > >> > > > > Proposed new text for 4.6.4 (in my local copy): >> > > > > > 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. If more than 10 "mx" records are returned for >> this >> > > > > > further lookup, a permerror MUST be returned. If more than 10 >> > > > > > "ptr" >> > > > > > >> > > > > > records are returned for this further lookup (either due to use >> of >> > > > > > a "ptr" mechanisms, or the %{p} macro) processing MUST be >> terminated >> > > > > > after 10 records. This limit is per mechanism or macro in the >> > > > > > record and in addition to the lookup limits above. >> > > > > >> > > > > Comments please. If no one objects, I'll include it. >> > > > > >> > > > > Scott K >> > > > > _______________________________________________ >> > > > > spfbis mailing list >> > > > > spfbis@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/spfbis >> > > >> > > _______________________________________________ >> > > spfbis mailing list >> > > spfbis@ietf.org >> > > https://www.ietf.org/mailman/listinfo/spfbis >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> > > --e89a8f3ba6e3b33d3204d5069914 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
...except with the %{p} stuff folded in, sorry about that.=


On = Tue, Feb 5, 2013 at 8:14 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
How about:

When= evaluating the "mx" mechanism, the number of MX resource records= queried MUST NOT exceed 10.=A0 If the evaluation of an "mx" mech= anism results in more than 10 resource records being <returned? queried?= >, the "mx" mechanism MUST produce a "permerror" res= ult (see Section xxx).

When evaluating the "ptr" mechanism, the number of PTR = resource records queried MUST NOT exceed 10.=A0 If the evaluation of a &quo= t;ptr" mechanism results in more than 10 resource records being return= ed, all records other than the first 10 MUST be ignored.

The reason for the disparity is that the set of and contents of the MX = record are under control of the domain owner, while the set of and contents= of PTR records are under control of the owner of the IP address actually m= aking the connection.

These limits are per mechanism or macro in the record, and ar= e in addition to the lookup limits specified above.

<s= nip>

Could we change "10" to "a fixed b= ut possibly configurable limit", and indicate that most implementation= s use 10 as that limit?=A0 10 is effectively arbitrary, unless studies have= shown that it's the best answer.

Also, the ignoring of PTR replies beyond the first 10 render= s the protocol non-deterministic given that replies come back in a random o= rder.=A0 Are we okay with that?
-MSK


On Tue, Feb 5, 2013 at= 7:13 PM, Scott Kitterman <spf2@kitterman.com> wrote:
Sure. =A0Do you have a suggestion?

Scott K

On Tuesday, February 05, 2013 07:08:35 PM Murray S. Kucherawy wrote:
> Got it. =A0Could we massage that paragraph in to explain the context o= f the
> rule being imposed?
>
> -MSK
>
> On Tue, Feb 5, 2013 at 3:02 PM, Scott Kitterman <spf2@kitterman.com> wrote:
> > The difference is that the contents of the MX record are under co= ntrol of
> > the
> > domain owner. =A0The number of PTR records are under control of t= he owner of
> > the
> > IP address actually making the connection. =A0If we allow for per= merror on
> > too
> > many PTR, then that gives someone trying to avoid SPF fail an eas= y way to
> > turn
> > a fail into a permerror. =A0A similar risk does not exist with MX= .
> >
> > Scott K
> >
> > On Tuesday, February 05, 2013 01:35:55 PM Murray S. Kucherawy wro= te:
> > > Doesn't the same attack exist if one lists >10 MX rec= ords?
> > >
> > > Just wondering why MX isn't getting the same treatment a= s PTR in the
> > > proposed new text.
> > >
> > > -MSK
> > >
> > > On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman <spf2@kitterman.com>=
> >
> > wrote:
> > > > On Thursday, January 31, 2013 06:02:53 AM S Moonesamy w= rote:
> > > > > #43 New requirement for mx: or ptr records
> > > >
> > > > Issue:
> > > > > in section 4.6.4, there is a new requirement that = there must not be
> >
> > more
> >
> > > > > than 10 records for mx: or ptr:. This completely w= rong for ptr:
> > because
> >
> > > > > a
> > > > > spammer could choose to send spam from a host with= more than 10 PTR
> > > > > records, thus forcing a domain's SPF record to= return permerror,
> >
> > instead
> >
> > > > of
> > > >
> > > > > fail. If anything, more than 10 PTR records should= cause the ptr:
> > > > mechanism
> > > >
> > > > > to automatically not-match. It should also be made= clear that the
> >
> > %{p}
> >
> > > > > macro is valid no matter how many PTR records are = returned.
> > > >
> > > > Proposed new text for 4.6.4 (in my local copy):
> > > > > =A0When evaluating the "mx" and "pt= r" mechanisms, or the %{p} macro,
> > > > > =A0there MUST be a limit of no more than 10 MX or = PTR RRs looked up
> > > > > =A0and checked. =A0If more than 10 "mx" = records are returned for this
> > > > > =A0further lookup, a permerror MUST be returned. = =A0If more than 10
> > > > > =A0"ptr"
> > > > >
> > > > > records are returned for this further lookup (eith= er due to use of
> > > > > a "ptr" mechanisms, or the %{p} macro) p= rocessing MUST be terminated
> > > > > after 10 records. =A0This limit is per mechanism o= r macro in the
> > > > > record and in addition to the lookup limits above.=
> > > >
> > > > Comments please. =A0If no one objects, I'll include= it.
> > > >
> > > > Scott K
> > > > _______________________________________________
> > > > spfbis mailing list
> > > > sp= fbis@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/spfbis
> >
> > _______________________________________________
> > spfbis mailing list
> > spfbis@ietf.= org
> > https://www.ietf.org/mailman/listinfo/spfbis
_______________________________________________
spfbis mailing list
spfbis@ietf.org = https://www.ietf.org/mailman/listinfo/spfbis


--e89a8f3ba6e3b33d3204d5069914-- From superuser@gmail.com Tue Feb 5 20:20:17 2013 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 7237621F8A0C for ; Tue, 5 Feb 2013 20:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miZflaWh1GHT for ; Tue, 5 Feb 2013 20:20:16 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8F121F8519 for ; Tue, 5 Feb 2013 20:20:09 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ez12so1113476wid.6 for ; Tue, 05 Feb 2013 20:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PUKTDIlqWBvJ1tp61+hTQ1UzfXqjI7Bk3UhliF3xrhQ=; b=AVOpZT6+ezE8YXUqCqAlZRrqLTTElSP53gQJBCdFmE5ZPC3y8wDnASsK3g+dvYw0WZ 1tixur/AYxWU3VUOT1MbloKpL/L5rmkwa9cKRUjgtmlq2Gft7zpAj+rh4wF2zlv6dCcH V3gJk065MUsMm1kM4/GjQdqhTkik06kPgCPZVkBPZDqKhx1+FixxDyID5NSgionDpYpd e1l1kKdzHC2Yf727s+ygcBO0rV3jPuFP9Uf9WSZr3C3zilt2bsqfALlyfHQh34aj+rIp KB5S8U2lkaDJbm7Od5KVstvVnRQSJTRCpuPHGPeW4N02h7th17igP6rQ0y5y+lQ8uSGt ITeg== MIME-Version: 1.0 X-Received: by 10.195.13.11 with SMTP id eu11mr47104715wjd.39.1360124408836; Tue, 05 Feb 2013 20:20:08 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 20:20:08 -0800 (PST) In-Reply-To: <1410839.1pcvUEaBed@scott-latitude-e6320> References: <18634195.xKHCPc4tqs@scott-latitude-e6320> <1410839.1pcvUEaBed@scott-latitude-e6320> Date: Tue, 5 Feb 2013 20:20:08 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bd91a843d338904d506a4b1 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Ticket #47 domain-spec 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, 06 Feb 2013 04:20:17 -0000 --047d7bd91a843d338904d506a4b1 Content-Type: text/plain; charset=ISO-8859-1 I'm unclear on how DNSxLs come into this. Is that through the macro reverse IP lookup trick? Something else? More generally, I agree that DNS errors should not be hidden. -MSK On Tue, Feb 5, 2013 at 3:00 PM, Scott Kitterman wrote: > As far as I know, there's been no discussion on the topic, just an initial > proposal for resolving an ambiguity in the spec. > > It's A lookup even when the connection type is IPv6 because DNSxBLs return > an > A record format. > > Looking at the two options, I think the rationale (to be clear, I am > guessing): > > 1. A DNS lookup failure here will generally only turn a pass into a > temperror, so hiding the error doesn't allow a path to upgrade a result. > If a > message would otherwise be accepted, it's not worth sending them a 450 just > for this. > > 2. Hiding errors is bad. > > Scott K > > On Tuesday, February 05, 2013 01:34:10 PM Murray S. Kucherawy wrote: > > Feel free to point me at previous discussion, but why "(even when the > > connection type is IPv6)"? > > > > Shouldn't a DNS error result in a "temp-fail"? > > > > -MSK > > > > On Tue, Feb 5, 2013 at 10:00 AM, Scott Kitterman > wrote: > > > I think this needs discussion before I include one of the two proposed > > > solutions in a draft. > > > > > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/47 > > > > > > Suggested text: > > > bis-06: > > > The domain-spec is expanded as per Section 8. The resulting domain > > > > > > name is > > > used for a DNS A RR lookup. If any A record is returned, this mechanism > > > matches. The lookup type is A even when the connection type is IPv6. > > > > > > new: > > > The domain-spec is expanded as per Section 8. The resulting domain > > > > > > name is > > > used for a DNS A RR lookup (even when the connection type is IPv6). If > any > > > A > > > record is returned, this mechanism matches, otherwise the mechanism > > > doesn't > > > match. > > > > > > or new: > > > The domain-spec is expanded as per Section 8. The resulting domain > > > > > > name is > > > used for a DNS A RR lookup (even when the connection type is IPv6). If > any > > > A > > > record is returned, this mechanism matches. In all other cases (no A > > > records, > > > DNS error, etc.), the mechanism doesn't match. > > > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > > > > > > As I read it the second alternative specifies that a DNS error is > treated > > > as a > > > no match, but the first does not. I believe we want the first as we > don't > > > want > > > to hide DNS failures, but I'm not sure. > > > > > > Scott K > > > _______________________________________________ > > > spfbis mailing list > > > spfbis@ietf.org > > > https://www.ietf.org/mailman/listinfo/spfbis > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --047d7bd91a843d338904d506a4b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm unclear on how DNSxLs come into this.=A0 Is t= hat through the macro reverse IP lookup trick?=A0 Something else?

More generally, I agree that DNS errors should not be hidden.
<= br>
-MSK


On Tue, Feb 5, 2013 at 3:00 PM, Scott Kitterman &l= t;spf2@kitterman.co= m> wrote:
As far as I know, there's been no discus= sion on the topic, just an initial
proposal for resolving an ambiguity in the spec.

It's A lookup even when the connection type is IPv6 because DNSxBLs ret= urn an
A record format.

Looking at the two options, I think the rationale (to be clear, I am
guessing):

1. =A0A DNS lookup failure here will generally only turn a pass into a
temperror, so hiding the error doesn't allow a path to upgrade a result= . =A0If a
message would otherwise be accepted, it's not worth sending them a 450 = just
for this.

2. =A0Hiding errors is bad.

Scott K

On Tuesday, February 05, 2013 01:34:10 PM Murray S. Kucherawy wrote:
> Feel free to point me at previous discussion, but why "(even when= the
> connection type is IPv6)"?
>
> Shouldn't a DNS error result in a "temp-fail"?
>
> -MSK
>
> On Tue, Feb 5, 2013 at 10:00 AM, Scott Kitterman <spf2@kitterman.com> wrote:
> > I think this needs discussion before I include one of the two pro= posed
> > solutions in a draft.
> >
> > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/47 > >
> > =A0Suggested text:
> > bis-06:
> > =A0 =A0 The domain-spec is expanded as per Section 8. The resulti= ng domain
> >
> > name is
> > used for a DNS A RR lookup. If any A record is returned, this mec= hanism
> > matches. The lookup type is A even when the connection type is IP= v6.
> >
> > new:
> > =A0 =A0 The domain-spec is expanded as per Section 8. The resulti= ng domain
> >
> > name is
> > used for a DNS A RR lookup (even when the connection type is IPv6= ). If any
> > A
> > record is returned, this mechanism matches, otherwise the mechani= sm
> > doesn't
> > match.
> >
> > or new:
> > =A0 =A0 The domain-spec is expanded as per Section 8. The resulti= ng domain
> >
> > name is
> > used for a DNS A RR lookup (even when the connection type is IPv6= ). If any
> > A
> > record is returned, this mechanism matches. In all other cases (n= o A
> > records,
> > DNS error, etc.), the mechanism doesn't match.
> >
> > http://www.ietf.org/mail-archive/web/spfbis/= current/msg02371.html
> >
> > As I read it the second alternative specifies that a DNS error is= treated
> > as a
> > no match, but the first does not. =A0I believe we want the first = as we don't
> > want
> > to hide DNS failures, but I'm not sure.
> >
> > Scott K
> > _______________________________________________
> > spfbis mailing list
> > spfbis@ietf.org
> > https://www.ietf.org/mailman/listinfo/spfbis
_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--047d7bd91a843d338904d506a4b1-- From johnl@iecc.com Tue Feb 5 20:29:58 2013 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 85FB921F8A0C for ; Tue, 5 Feb 2013 20:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.998 X-Spam-Level: X-Spam-Status: No, score=-110.998 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTwzpK+hvwi6 for ; Tue, 5 Feb 2013 20:29:58 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B89B921F899E for ; Tue, 5 Feb 2013 20:29:56 -0800 (PST) Received: (qmail 61933 invoked from network); 6 Feb 2013 04:29:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Feb 2013 04:29:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5111dc44.xn--i8sz2z.k1302; i=johnl@user.iecc.com; bh=DPVB0Gx4TWnNvV1VSgKXw89kkbqYLkT+HvhSVz35oMk=; b=eXKRz10GSWtlZ/tc62kmQYuGemyQsOs90KF83hfPul3TD5kE3sKlpJjNbkkEc7gsoSC/wBvM4VOfOWdvuw04avDQK932AlOM6OxEtcezDgRCVoo/PKiO+vQL1ZgFWlxLQDl7IVdUTsxL4u5mOSbL8MFoPFpCZEXtr4fSY9526C8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5111dc44.xn--i8sz2z.k1302; olt=johnl@user.iecc.com; bh=DPVB0Gx4TWnNvV1VSgKXw89kkbqYLkT+HvhSVz35oMk=; b=iCQ3s0+JEXPNLdThV5c+Uppqa5T27DZLmX6+QSkCWhK9eBFAqay/i5W3VpcWJDeeGRIVbQ8BX5yM4N0cZNNqqf0bRsyqpRQtZ3nXX49ufJ74NFHz+3rfAFFA1syykk3bOqHOXzaNL0kt0SLqwqVjdyv5wN7kf9ZQMQa4g3UrB/8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 6 Feb 2013 04:29:34 -0000 Message-ID: <20130206042934.97742.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: superuser@gmail.com Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 06 Feb 2013 04:29:58 -0000 >Could we change "10" to "a fixed but possibly configurable limit", and >indicate that most implementations use 10 as that limit? 10 is effectively >arbitrary, unless studies have shown that it's the best answer. It's an interop issue. If your limit is 10 and my limit is 15, there's going to be mail where you'll get a permerror and I'll get a pass or fail. It's been 10 since forever, and it hasn't been a problem in practice. From superuser@gmail.com Tue Feb 5 21:09:41 2013 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 6074B21F899F for ; Tue, 5 Feb 2013 21:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5ufZMQe54jn for ; Tue, 5 Feb 2013 21:09:40 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 619AC21F89AA for ; Tue, 5 Feb 2013 21:09:40 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr12so762839wgb.23 for ; Tue, 05 Feb 2013 21:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y8yKeaOqm3XYa92NCOfCSQZNaf/YGyS4urTAQS8azv0=; b=FoOT5LciuWv9cxvp79F4MRQMOZu4Q0KJjlE98EfY8SJyVB+zwlh3Aex+kc1cP0z4wj 2GbYdzuX+Noueu51IC+hbwOLHjseEvpY9PMMg/X0nsesJO3ITAsb1biNouumoxil4s7W xOE8yubL4PcKdodkLJh7NzfhQ8AzNzsCxQgcgZoSNRYumRA0dwDKa3R+EIIVLQjfv6/z xoqVveSrl4vLWOCuqeWJEc+OP29lO6yaaHdUO+W2eAJb6K0hoemmrrl4Wp0xL8MmReAN 8ALDbpNx6FBgQZTUGMmYPImWQfcoZH6lCXDLAYmQIHJ/xviPlsPl1rKMsY+rfjXrZKGs jPRQ== MIME-Version: 1.0 X-Received: by 10.194.59.40 with SMTP id w8mr47245940wjq.51.1360127377212; Tue, 05 Feb 2013 21:09:37 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 21:09:37 -0800 (PST) In-Reply-To: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> Date: Tue, 5 Feb 2013 21:09:37 -0800 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7b86d68c2b040d04d5075559 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 06 Feb 2013 05:09:41 -0000 --047d7b86d68c2b040d04d5075559 Content-Type: text/plain; charset=ISO-8859-1 Since the list of open issues has been seriously trimmed by someone since SM posted this (only 16 left), I'll open a thread for each of the open ones now with a comment on each based on the current draft version (-09). -MSK On Thu, Jan 31, 2013 at 6:02 AM, S Moonesamy wrote: > Hello, > > According to the SPFBIS WG Charter the working group was scheduled to > submit draft-ietf-spfbis-4408bis for publication in December 2012. Here is > the list of open issues [1]: > > #22 RFC 4408: Section 2.5.7 PermError on invalid domains after macro > expansion > > #24 RFC 4408: Reasonable DNS error limits > > #29 RFC 4408: Section 2.5.4 - mark on fail > > #34 Throw a temperror - Section 5.2 > > #35 authorized_spf domain name - Section 9.1.1 > > #36 RFC 2119 key words > > #37 spf classic > > #38 Deprecated > > #39 Temporary errors implied as only caused by DNS errors > > #40 Wildcard records > > #41 Multiple DNS errors > > #42 Record Evaluation > > #43 New requirement for mx: or ptr records > > #44 Section 5.4 does not mention requirement in section 4.6.4 > > #45 Section 5.5 steps > > #46 DNS reply in Section 5.7 > > #47 domain-spec > > #48 Section 8.1 - macro defs > > #49 IANA registry for SPF modifiers > > #50 Terminology > > #51 Remove A-R from 4408bis > > #52 Section 8.1 *Macro Definitions > > #53 Possible ABNF nit with Received-SPF > > #54 Section 9.2.1 of 4408bis > > #55 Section 9.2.2 Forwarding Services and Aliases > > #56 Section 9.2.2 Forwarding Services and Aliases > > #57 x-* fields in 4408bis > > #58 Local policy in 4408bis > > #59 Remove section 9.1.1 DNS Resource Considerations > > #6 RFC 4408 Section 10.1 - Processing limits needs clarification and > reorganization > > #33 Marked Failed Mail Exposure > > Regards, > S. Moonesamy > > 1. http://trac.tools.ietf.org/wg/**spfbis/trac/report/1 > > ______________________________**_________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/**listinfo/spfbis > --047d7b86d68c2b040d04d5075559 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Since the list of open issues has been seriously trim= med by someone since SM posted this (only 16 left), I'll open a thread = for each of the open ones now with a comment on each based on the current d= raft version (-09).

-MSK


On Thu, Jan 31, 2013 at 6:02 AM, S Moonesamy <sm+ietf@elandsys.com= > wrote:
Hello,

According to the SPFBIS WG Charter the working group was scheduled to submi= t draft-ietf-spfbis-4408bis for publication in December 2012. =A0Here is th= e list of open issues [1]:

#22 RFC 4408: Section 2.5.7 PermError on invalid domains after macro expans= ion

#24 RFC 4408: Reasonable DNS error limits

#29 RFC 4408: Section 2.5.4 - mark on fail

#34 Throw a temperror - Section 5.2

#35 authorized_spf domain name - Section 9.1.1

#36 RFC 2119 key words

#37 spf classic

#38 Deprecated

#39 Temporary errors implied as only caused by DNS errors

#40 Wildcard records

#41 Multiple DNS errors

#42 Record Evaluation

#43 New requirement for mx: or ptr records

#44 Section 5.4 does not mention requirement in section 4.6.4

#45 Section 5.5 steps

#46 DNS reply in Section 5.7

#47 domain-spec

#48 Section 8.1 - macro defs

#49 IANA registry for SPF modifiers

#50 Terminology

#51 Remove A-R from 4408bis

#52 Section 8.1 *Macro Definitions

#53 Possible ABNF nit with Received-SPF

#54 Section 9.2.1 of 4408bis

#55 Section 9.2.2 Forwarding Services and Aliases

#56 Section 9.2.2 Forwarding Services and Aliases

#57 x-* fields in 4408bis

#58 Local policy in 4408bis

#59 Remove section 9.1.1 DNS Resource Considerations

#6 RFC 4408 Section 10.1 - Processing limits needs clarification and reorga= nization

#33 Marked Failed Mail Exposure

Regards,
S. Moonesamy

1. http://trac.tools.ietf.org/wg/spfbis/trac/report/1

_______________________________________________
spfbis mailing list
spfbis@ietf.org = https://www.ietf.org/mailman/listinfo/spfbis

--047d7b86d68c2b040d04d5075559-- From superuser@gmail.com Tue Feb 5 21:18:06 2013 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 6A5B121F8936 for ; Tue, 5 Feb 2013 21:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.313 X-Spam-Level: X-Spam-Status: No, score=-3.313 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x68kned79KjS for ; Tue, 5 Feb 2013 21:18:05 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 97A4821F8934 for ; Tue, 5 Feb 2013 21:18:04 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hm6so1144837wib.8 for ; Tue, 05 Feb 2013 21:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=/GyTlgjvNpIY6UFeGdijvNuSVHDHhXiwYgfwS0qu024=; b=Ezk6wRGt575hvXVe26c7NKf+EE+9l7lBdc/vodlLmIHSgICL+82Ub/VXt0KnxkubIy iL8qji/dhUBKYDIbUWcdAFpyZrL57OJ2ZzB0LYDMry92pxCzJi8xZQYaBck5CJavbsDK ictFn+Na+X01afkCpG1eS7MLFU/zBlzH7xuLOFEkDEmFrqZSA5eclHMOWPvAelcq29f0 wTYD9337F0o4FAOzBEBpcxLj997/xXApbT/u9emZtpg8x3hzpt4S79d4Y4iN9jvWvTMl NmMbWfsyvoSEvm6weaQ17OBRuxa7eLgIdL/g3cdcvUIpuyt4qE3fczL+wbTS4UqVL4XB d2aQ== MIME-Version: 1.0 X-Received: by 10.180.101.99 with SMTP id ff3mr2313707wib.21.1360127883541; Tue, 05 Feb 2013 21:18:03 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 21:18:03 -0800 (PST) Date: Tue, 5 Feb 2013 21:18:03 -0800 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=f46d044280e858fcf404d50773a1 Subject: [spfbis] Revisit: Issue #24: RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization 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, 06 Feb 2013 05:18:06 -0000 --f46d044280e858fcf404d50773a1 Content-Type: text/plain; charset=ISO-8859-1 This has gotten no attention since SM's first summary, nor can I find any text in -09 that addresses it. I'm happy to be corrected. I remember a conversation with Scott that gave me clarity on what a "null lookup" is, but I don't see that a resolution made it into -09. Could someone more familiar with the issue propose some text to resolve it? -MSK --f46d044280e858fcf404d50773a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This has gotten no attention since SM's first sum= mary, nor can I find any text in -09 that addresses it.=A0 I'm happy to= be corrected.=A0 I remember a conversation with Scott that gave me clarity= on what a "null lookup" is, but I don't see that a resolutio= n made it into -09.

Could someone more familiar with the issue propos= e some text to resolve it?

-MSK
--f46d044280e858fcf404d50773a1-- From superuser@gmail.com Tue Feb 5 21:22:40 2013 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 8655521F84D3 for ; Tue, 5 Feb 2013 21:22:40 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ma2OOX3o9+HY for ; Tue, 5 Feb 2013 21:22:39 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEEA21F8200 for ; Tue, 5 Feb 2013 21:22:39 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so795916wey.31 for ; Tue, 05 Feb 2013 21:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=F6VJ4e1+qFJ6vZF2EFmcT1RtZHDtpWqJVGIkDWPtjlA=; b=XcnXIrb8CweU0RLXAxXZwJO8BZqFSqNNUTzB3xwMeb/VQcMXKlKRDzLaGYriGR37i8 rp17zqKUf2qre4CL+mE2a+pExJZT805e8j5joKegKksiufU5Ow2OMabGNcPKSbRraJR6 uIjtYSdgzYlEjNGg2uaUOfPXrt6cudbEnIWOJB+i/B7JH/3ZhULQp9xGUjvuIYnEdAVD OQEn1vuZxnAvCq5OEQJVmfF7UrKr3cmo0STOC0IIUaU7PDVkKtQaN5CXAhZ2rYe57vQ0 0cxUiSa2voCC65OdMxVFTLZHM0tnAGmJMYmNcDs2uVKKHLwNVh57R9oL8OqOILso55S6 8sAw== MIME-Version: 1.0 X-Received: by 10.195.13.11 with SMTP id eu11mr47301889wjd.39.1360128158633; Tue, 05 Feb 2013 21:22:38 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 21:22:38 -0800 (PST) Date: Tue, 5 Feb 2013 21:22:38 -0800 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd91a84be8ec704d5078376 Subject: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 06 Feb 2013 05:22:40 -0000 --047d7bd91a84be8ec704d5078376 Content-Type: text/plain; charset=ISO-8859-1 "Overall, when RFC 4408 was drafted, care was taken to capitalize RFC 2119 keywords, and use the lower case words as regular English meaning. While most of the lower case words have been changed to synonyms, a few have been changed into RFC 2119 keywords. I think most (but sadly, not all) of these capitalizations are wrong." Could this be made more specific? Which ones are wrong? -MSK --047d7bd91a84be8ec704d5078376 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
"Overall, when RFC 4408 was drafted, care was taken to c= apitalize RFC 211= 9 keywords, and use the lower case words as regular English meaning. =20 While most of the lower case words have been changed to synonyms, a few=20 have been changed into RFC 2119 keywords. I think most (but sadly, not all) of these ca= pitalizations are wrong."

Could this be made more specifi= c?=A0 Which ones are wrong?

-MSK
--047d7bd91a84be8ec704d5078376-- From superuser@gmail.com Tue Feb 5 21:27:17 2013 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 21E1D21F8625 for ; Tue, 5 Feb 2013 21:27:17 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk1WPPcmql2P for ; Tue, 5 Feb 2013 21:27:16 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 72D8C21F84CA for ; Tue, 5 Feb 2013 21:27:16 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so4830767wie.2 for ; Tue, 05 Feb 2013 21:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=8Msi/OYpLkfZpefzbiO7mvxegOfnE/KyHVaYMTvvXXk=; b=MUbwvKQWF3wRsCF8yw6pUvztGXu8zH/8uICkkH478u3FEZ8D2LkkqDPx2HiuUR7Rfn 86htE/bFFsvhLMuaJrTD2OiZYoOVZzNzTnYZpZmi0CtOhHR34bovwNzzBzlTco/WinZg CE0tbMvEtKgk2kuYTtfiCI1oDLEwg+BlDaE1NBA3b8TcKWIHVzIjtV8yT+oZzYr2D0kE siQbxtBgNL4F0K/d1XJbl1g0DOlQJH+omgs3fxngeiEUqzNEBpRb7Ecnc8DjiyzpC08H TR6XjqU74TLCwgZUccS/YhwdnHqqvC4ajCYLn1kPyiLmxGlPr//Z9Qxha9ANv5vJFz8j cSxA== MIME-Version: 1.0 X-Received: by 10.180.105.232 with SMTP id gp8mr2372621wib.33.1360128435653; Tue, 05 Feb 2013 21:27:15 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 21:27:15 -0800 (PST) Date: Tue, 5 Feb 2013 21:27:15 -0800 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=f46d044402d0418c6904d5079419 Subject: [spfbis] Revisit: Issue #38: Deprecated 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, 06 Feb 2013 05:27:17 -0000 --f46d044402d0418c6904d5079419 Content-Type: text/plain; charset=ISO-8859-1 I think we could stand to get rid of the definition we have for "Deprecated" in Section 1, but still leave the notations elsewhere in the document. Operationally, we have to continue to support ptr and %p because people are using them. That means compliant implementations still implement them. We're basically stuck with it. The right thing to do is what's done in the "ptr" description that explains why we don't like it anymore. -MSK --f46d044402d0418c6904d5079419 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think we could stand to get rid of the definition w= e have for "Deprecated" in Section 1, but still leave the notatio= ns elsewhere in the document.

Operationally, we have to continue to = support ptr and %p because people are using them.=A0 That means compliant i= mplementations still implement them.=A0 We're basically stuck with it.= =A0 The right thing to do is what's done in the "ptr" descrip= tion that explains why we don't like it anymore.

-MSK
--f46d044402d0418c6904d5079419-- From spf2@kitterman.com Tue Feb 5 21:49:57 2013 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 4CDB921F8A1D for ; Tue, 5 Feb 2013 21:49:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gZhequtXCYC for ; Tue, 5 Feb 2013 21:49:56 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2BB21F8A0D for ; Tue, 5 Feb 2013 21:49:56 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D244F20E410F; Wed, 6 Feb 2013 00:49:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360129795; bh=1BtV1jFmy+1N67k+lRzUpuD4F4qpX+RPQp+NfN9YKok=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PDmn0blkvdACbQ2QqAgFWCrOUsuzMKZIPLNiUSsysH44i2T+BStTDtwPCVePZcUw+ gKwa3CmFLbBw5xbrsChBnTn1eRUQY9eIiZJhcEeWh8NTNOASl7DYwCNSaiJAlb0IDu jPu2U03Kfq53zaKGfBjh+H9niNNKpYgJJbix1KkM= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A2E1120E40B2; Wed, 6 Feb 2013 00:49:54 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 06 Feb 2013 00:49:49 -0500 Message-ID: <1442153.EBqHnkr4cX@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; 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] Revisit: Issue #24: RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization 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, 06 Feb 2013 05:49:57 -0000 On Tuesday, February 05, 2013 09:18:03 PM Murray S. Kucherawy wrote: > This has gotten no attention since SM's first summary, nor can I find any > text in -09 that addresses it. I'm happy to be corrected. I remember a > conversation with Scott that gave me clarity on what a "null lookup" is, > but I don't see that a resolution made it into -09. > > Could someone more familiar with the issue propose some text to resolve it? I want to hold this issue open. We've reorganized and clarified relative to 4408, but the "null lookup" question is still open and I can't resolve it without some data mining I haven't had time to do. I was discussing this with someone today (who I won't name since they haven't actually volunteered yet) who may be able to do it soon. Scott K From superuser@gmail.com Tue Feb 5 21:57:16 2013 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 542A921F842C for ; Tue, 5 Feb 2013 21:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOBbomTXlhLW for ; Tue, 5 Feb 2013 21:57:15 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id D123921F85FC for ; Tue, 5 Feb 2013 21:57:10 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id 16so787082wgi.27 for ; Tue, 05 Feb 2013 21:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MCiilaPXvXye6zc0u9lNUgzCTzyTgitUV5q0bwf2YFI=; b=NSQI8ipxcc/yJxfCvsN1tzauhqbWWXWSMe5xMyfqriz80GM5meB5KChJhZBsj1blwm kNisIM5mrTYRV1k+WYCYrbAAWi9FSNVNH1L85c96Dyz+WXa0Vl6si/wSXvdgn/eHhy5n XzWypGlWNn4PSW/TLZIxaRcLZrh8dCFEHimDuH2s68I/QcAaoM2zvKUtAy9Kz+wn15JQ vQK7lJfxeqpKLyLTcLq9ycNTgf6oxdaZtkxYy6G12GsT2tviJ9xo3/pZnMHI2iYgc8Ep nm3NVbQNt8mZByC7JoQeAd4EcmsNfyuSZNl/nT4o09CDB7Mbw5tFuU7OZ5dTdbVNZnch dCXg== MIME-Version: 1.0 X-Received: by 10.180.105.232 with SMTP id gp8mr2457613wib.33.1360130229825; Tue, 05 Feb 2013 21:57:09 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 21:57:09 -0800 (PST) In-Reply-To: <1878869.epuRBHeDfC@scott-latitude-e6320> References: <1878869.epuRBHeDfC@scott-latitude-e6320> Date: Tue, 5 Feb 2013 21:57:09 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d044402d0326fa804d507ffdf Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 06 Feb 2013 05:57:16 -0000 --f46d044402d0326fa804d507ffdf Content-Type: text/plain; charset=ISO-8859-1 I think the ABNF is correct as-is, but there is no example that illustrates the use of mechanisms within a Received-SPF, which would clear up the confusion. The current ABNF is mean to enable things like: Received-SPF: pass mx=something; a=something; ... So "mechanism" doesn't need to be quoted, because it expands into all of the available mechanism names. What Barry was doing is assuming one wants to produce: Received-SPF: pass mechanism=mx; ... ...which was not the intention. Does that sound right, Barry? Scott? There is an error in the example upthread though, because it's impossible to generate "Received-SPF: unknown ..." as "unknown" isn't a valid result string. -MSK On Tue, Feb 5, 2013 at 2:50 PM, Scott Kitterman wrote: > Need some help with this one: > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/53 > > Message posted by Barry Leiba on 4 Sept 2012: > > that was intended to support unknown mechanisms. So, if you had an SPF > record from draft-mengwong-spf-00: > > v=spf1 a mx ptr domainkeys:_dk.%{d} -all > > The Received-SPF header would look like: > > Received-SPF: unknown domainkeys=_dk.example.com > > If that's the case, the text needs work to make it clear, because it's > decidedly not. The text below the grammar lists key names and the meanings > of > the values. "mechanism" is listed as a key name in that text. So there's a > problem somewhere that needs to be cleared up. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02608.html > > Downthread from the referenced message, there's a proposed simplification > from > Arthur Thisell, but I think it's based on the (I believe incorrect) > assumption > that mechanism isn't used. > > Suggestions please. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d044402d0326fa804d507ffdf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think the ABNF is correct as-is, but ther= e is no example that illustrates the use of mechanisms within a Received-SP= F, which would clear up the confusion.

The current ABNF is mea= n to enable things like:

Received-SPF: pass mx=3Dsomething; a=3Dsomething; ...

So &= quot;mechanism" doesn't need to be quoted, because it expands into= all of the available mechanism names.=A0 What Barry was doing is assuming = one wants to produce:

Received-SPF: pass mechanism=3Dmx; ...

...which was n= ot the intention.

Does that sound right, Barry?=A0 Scott?=

There is an error in the example upthread though, becaus= e it's impossible to generate "Received-SPF: unknown ..." as = "unknown" isn't a valid result string.

-MSK


On Tue, Feb 5, 2013 at 2:50 PM, Scott Kitterman <spf2@kitterma= n.com> wrote:
Need some help with this one:

http://trac.tools.ietf.org/wg/spfbis/trac/ticket/53

=A0Message posted by Barry Leiba on 4 Sept 2012:

=A0 =A0 that was intended to support unknown mechanisms. So, if you had an = SPF
=A0 =A0 record from draft-mengwong-spf-00:

=A0 =A0 =A0 =A0 v=3Dspf1 a mx ptr domainkeys:_dk.%{d} -all

=A0 =A0 The Received-SPF header would look like:

=A0 =A0 =A0 =A0 Received-SPF: unknown domainkeys=3D_dk.example.com

If that's the case, the text needs work to make it clear, because it= 9;s
decidedly not. The text below the grammar lists key names and the meanings = of
the values. "mechanism" is listed as a key name in that text. So = there's a
problem somewhere that needs to be cleared up.

http://www.ietf.org/mail-archive/web/spfbis/current/ms= g02608.html

Downthread from the referenced message, there's a proposed simplificati= on from
Arthur Thisell, but I think it's based on the (I believe incorrect) ass= umption
that mechanism isn't used.

Suggestions please.

Scott K
_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--f46d044402d0326fa804d507ffdf-- From superuser@gmail.com Tue Feb 5 22:25:03 2013 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 60BC221F84CE for ; Tue, 5 Feb 2013 22:25:03 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2NwtctvAEPe for ; Tue, 5 Feb 2013 22:25:03 -0800 (PST) Received: from mail-we0-x233.google.com (we-in-x0233.1e100.net [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B952C21F84CA for ; Tue, 5 Feb 2013 22:25:02 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id x43so830870wey.24 for ; Tue, 05 Feb 2013 22:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Op5dIugGLvPcPcVhWyGMUnF0mK9amQpie3jXC2pc2lA=; b=c2db8hVfv1+UMfNJzuDaJ4PjZjWwZ8lBJeo3Ay7iAF7Nr/AVmEP/DVsskP3lVw4Af0 qQLLUuD1ENUX0RA0tDQbltzyKV18gfK1/ppc7Abf3trBakW+EKiEitJzKjJrWjqIPQdM tE81M/jlgL7kcnsccUF30/cmpHGOZCERPZCClZcsX9vox9Q/0aXzge6VTAy3OdSR9L6Q zPJpjyEx7KGhwN8PDIFd6DsuaB/byLZbnCwvfJk4i51/wqB86pdOxhtXaKog0nnZ0TZb YFdNFkh/B/lYAD5dcQsiHB2FJH97178gahRRQXjDU1DxDBA1oo16Ke6tBQ/gNtnX+hFg 5Uag== MIME-Version: 1.0 X-Received: by 10.180.101.99 with SMTP id ff3mr2534517wib.21.1360131901687; Tue, 05 Feb 2013 22:25:01 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 22:25:01 -0800 (PST) Date: Tue, 5 Feb 2013 22:25:01 -0800 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=f46d044280e8d9068d04d508629d Subject: [spfbis] Revisit: Issue #55: Section 9.2.2 Forwarding Services and Aliases 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, 06 Feb 2013 06:25:03 -0000 --f46d044280e8d9068d04d508629d Content-Type: text/plain; charset=ISO-8859-1 Dave, Would changing "Forwarding service" to "Mediators" throughout this section suffice? -MSK --f46d044280e8d9068d04d508629d Content-Type: text/html; charset=ISO-8859-1
Dave,

Would changing "Forwarding service" to "Mediators" throughout this section suffice?

-MSK
--f46d044280e8d9068d04d508629d-- From spf2@kitterman.com Tue Feb 5 22:26:40 2013 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 7C9DA21F8964 for ; Tue, 5 Feb 2013 22:26:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D6Lrn-u8wJM for ; Tue, 5 Feb 2013 22:26:39 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B343921F84CA for ; Tue, 5 Feb 2013 22:26:39 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D14BA20E410F; Wed, 6 Feb 2013 01:26:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360131998; bh=bqJub7bTK1HNeeu6R+g1nYQDQfD1hxduugjQ20Oigs4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lA0mW3vS9/tHpPD8byoyFmFbCsVy+Er+07vtzVedPPjnAaIGGhmWHHcy4aOfXLpx5 CdDPnCddWgN7cgZqURIbSxgv/q/HRQcCJkZjSCdanptJnU//AC3d20/7JZj0JR0HNt PILVvRnbJC4AlmSW4R7zxthaJ6qAwgXBrp7lH9Uo= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9E43120E40B2; Wed, 6 Feb 2013 01:26:38 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 06 Feb 2013 01:26:36 -0500 Message-ID: <1560860.2sJEDpXUvL@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <1878869.epuRBHeDfC@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] Possible ABNF nit with Received-SPF - #53 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, 06 Feb 2013 06:26:40 -0000 I fear not. I looked in the internal pyspf tests and it has things like mechanism=mx/24, so at best it's not clear. Mail::SPF seems to only put the mechanisms in comments and not use this bit of the ABNF. Unknown is the old name for temperror, so it used to be a valid result. Perhaps a copy/paste from an old example. Scott K On Tuesday, February 05, 2013 09:57:09 PM Murray S. Kucherawy wrote: > I think the ABNF is correct as-is, but there is no example that illustrates > the use of mechanisms within a Received-SPF, which would clear up the > confusion. > > The current ABNF is mean to enable things like: > > Received-SPF: pass mx=something; a=something; ... > > So "mechanism" doesn't need to be quoted, because it expands into all of > the available mechanism names. What Barry was doing is assuming one wants > to produce: > > Received-SPF: pass mechanism=mx; ... > > ...which was not the intention. > > Does that sound right, Barry? Scott? > > There is an error in the example upthread though, because it's impossible > to generate "Received-SPF: unknown ..." as "unknown" isn't a valid result > string. > > -MSK > > On Tue, Feb 5, 2013 at 2:50 PM, Scott Kitterman wrote: > > Need some help with this one: > > > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/53 > > > > Message posted by Barry Leiba on 4 Sept 2012: > > that was intended to support unknown mechanisms. So, if you had an SPF > > > > record from draft-mengwong-spf-00: > > v=spf1 a mx ptr domainkeys:_dk.%{d} -all > > > > The Received-SPF header would look like: > > Received-SPF: unknown domainkeys=_dk.example.com > > > > If that's the case, the text needs work to make it clear, because it's > > decidedly not. The text below the grammar lists key names and the meanings > > of > > the values. "mechanism" is listed as a key name in that text. So there's a > > problem somewhere that needs to be cleared up. > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02608.html > > > > Downthread from the referenced message, there's a proposed simplification > > from > > Arthur Thisell, but I think it's based on the (I believe incorrect) > > assumption > > that mechanism isn't used. > > > > Suggestions please. > > > > Scott K > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Tue Feb 5 22:31:40 2013 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 E14A621F8514 for ; Tue, 5 Feb 2013 22:31:40 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUYPp0DP4R5e for ; Tue, 5 Feb 2013 22:31:40 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD6621F86C4 for ; Tue, 5 Feb 2013 22:31:40 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B209720E410F; Wed, 6 Feb 2013 01:31:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360132299; bh=0f8errGpbwAxWhS0ZouO311qiHndMCi/iPAshFH72OY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=X/fEUb54PJgkYss/NR44bgnlMlLx73tnER8qGZkzFLPSCE0Wu2D9zK2xZtCrub04A Eyy2PxjoaWjubsvEnYF8OqGUaPhNdsLBlkM2FK9CcRtuvKuZm9ifdjwt2Tw2hKDNjj RBBLIT0ruDIK789nJFqZY6cXUmUtmV/y1w/wzGzk= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 843D720E40B2; Wed, 6 Feb 2013 01:31:39 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 06 Feb 2013 01:31:37 -0500 Message-ID: <75565768.jNv0X0XkDG@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> <2168659.7lAyFt0zqY@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] Summary of issues for draft-ietf-spfbis-4408bis 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, 06 Feb 2013 06:31:41 -0000 On Tuesday, February 05, 2013 08:14:13 PM Murray S. Kucherawy wrote: > How about: > > When evaluating the "mx" mechanism, the number of MX resource records > queried MUST NOT exceed 10. If the evaluation of an "mx" mechanism results > in more than 10 resource records being , the "mx" > mechanism MUST produce a "permerror" result (see Section xxx). > > When evaluating the "ptr" mechanism, the number of PTR resource records > queried MUST NOT exceed 10. If the evaluation of a "ptr" mechanism results > in more than 10 resource records being returned, all records other than the > first 10 MUST be ignored. > > The reason for the disparity is that the set of and contents of the MX > record are under control of the domain owner, while the set of and contents > of PTR records are under control of the owner of the IP address actually > making the connection. > > These limits are per mechanism or macro in the record, and are in addition > to the lookup limits specified above. > > > > Could we change "10" to "a fixed but possibly configurable limit", and > indicate that most implementations use 10 as that limit? 10 is effectively > arbitrary, unless studies have shown that it's the best answer. > > Also, the ignoring of PTR replies beyond the first 10 renders the protocol > non-deterministic given that replies come back in a random order. Are we > okay with that? > > -MSK I see John Levine already answered the why 10 pat of the question. Ignoring replies over 10 is the 4408 behavior, so we're making it deterministic for MX, because we can and leaving PTR as is because there's no better option available. I'm not particularly OK with non-determinism for PTR, but I don't have a better idea. I think your proposed text is good. Scott K From spf2@kitterman.com Tue Feb 5 22:33:27 2013 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 B5F9721F8920 for ; Tue, 5 Feb 2013 22:33:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ypxn3iEXvQO for ; Tue, 5 Feb 2013 22:33:27 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0783821F8918 for ; Tue, 5 Feb 2013 22:33:27 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8619A20E410F; Wed, 6 Feb 2013 01:33:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360132406; bh=BSUxha+VBbNTTFnzAHcWaMNBP4fgiLoK2JihkylMgHE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kKPYqzutZ2BGOGRu4U1v19JOXqpwGMI04q3JnFHMWQpBdh7P4N7RPpw0bN+ZeMzyk dqU9iEf0cgU40BJGnHQMHNmwOUZMJJZim3schkxJ+7A2lYK1in8mpGV3ic8brQqVjs WdEW1Ie84WFMwSjGScnC8emosAhC3Ue2vhybPu1c= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5411520E40B2; Wed, 6 Feb 2013 01:33:25 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 06 Feb 2013 01:33:24 -0500 Message-ID: <1489346.VMoCzk18lI@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <18634195.xKHCPc4tqs@scott-latitude-e6320> <1410839.1pcvUEaBed@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] Ticket #47 domain-spec 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, 06 Feb 2013 06:33:27 -0000 They actually don't. I think given the improvements we've made in the previous text, the DNSxL reference is just confusing now. I've removed it from my local copy. Scott K On Tuesday, February 05, 2013 08:20:08 PM Murray S. Kucherawy wrote: > I'm unclear on how DNSxLs come into this. Is that through the macro > reverse IP lookup trick? Something else? > > More generally, I agree that DNS errors should not be hidden. > > -MSK > > On Tue, Feb 5, 2013 at 3:00 PM, Scott Kitterman wrote: > > As far as I know, there's been no discussion on the topic, just an initial > > proposal for resolving an ambiguity in the spec. > > > > It's A lookup even when the connection type is IPv6 because DNSxBLs return > > an > > A record format. > > > > Looking at the two options, I think the rationale (to be clear, I am > > guessing): > > > > 1. A DNS lookup failure here will generally only turn a pass into a > > temperror, so hiding the error doesn't allow a path to upgrade a result. > > > > If a > > > > message would otherwise be accepted, it's not worth sending them a 450 > > just > > for this. > > > > 2. Hiding errors is bad. > > > > Scott K > > > > On Tuesday, February 05, 2013 01:34:10 PM Murray S. Kucherawy wrote: > > > Feel free to point me at previous discussion, but why "(even when the > > > connection type is IPv6)"? > > > > > > Shouldn't a DNS error result in a "temp-fail"? > > > > > > -MSK > > > > > > On Tue, Feb 5, 2013 at 10:00 AM, Scott Kitterman > > > > wrote: > > > > I think this needs discussion before I include one of the two proposed > > > > solutions in a draft. > > > > > > > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/47 > > > > > > > > Suggested text: > > > > bis-06: > > > > The domain-spec is expanded as per Section 8. The resulting domain > > > > > > > > name is > > > > used for a DNS A RR lookup. If any A record is returned, this > > > > mechanism > > > > matches. The lookup type is A even when the connection type is IPv6. > > > > > > > > new: > > > > The domain-spec is expanded as per Section 8. The resulting domain > > > > > > > > name is > > > > used for a DNS A RR lookup (even when the connection type is IPv6). If > > > > any > > > > > > A > > > > record is returned, this mechanism matches, otherwise the mechanism > > > > doesn't > > > > match. > > > > > > > > or new: > > > > The domain-spec is expanded as per Section 8. The resulting domain > > > > > > > > name is > > > > used for a DNS A RR lookup (even when the connection type is IPv6). If > > > > any > > > > > > A > > > > record is returned, this mechanism matches. In all other cases (no A > > > > records, > > > > DNS error, etc.), the mechanism doesn't match. > > > > > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > > > > > > > > As I read it the second alternative specifies that a DNS error is > > > > treated > > > > > > as a > > > > no match, but the first does not. I believe we want the first as we > > > > don't > > > > > > want > > > > to hide DNS failures, but I'm not sure. > > > > > > > > Scott K > > > > _______________________________________________ > > > > spfbis mailing list > > > > spfbis@ietf.org > > > > https://www.ietf.org/mailman/listinfo/spfbis > > > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From superuser@gmail.com Tue Feb 5 22:35:05 2013 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 4D66021F8918 for ; Tue, 5 Feb 2013 22:35:05 -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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxiLZ1ZXX4DX for ; Tue, 5 Feb 2013 22:35:04 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3711021F8920 for ; Tue, 5 Feb 2013 22:35:04 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hm11so6580988wib.3 for ; Tue, 05 Feb 2013 22:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=d2e0mweG6mxGkqo/sUsaSxUzFbvZ22C0OOgyXnyRFh4=; b=Qbxl2/Of6sQzlU4k1yV8Mi2OuBueHfiDv7NeJYu/OrB3gjipJ3gNb9BF7JLpl5zTZo 2mQutebsoaFwm7IkMFfz7NTu/kGCatpGt63fQNgetNDUXs2vHPGaO1mqz9ac5lyBDyUH YsR6muU28dfjqv0XZxQr+R0flP6Mm3Ac0rcij5gIHMQwgL9QEjYyqIYYEbZ/hmH/mSBM s0d+QPclZprzRjmQGHIpd1e1v6XxzcVBzTnlfGj3TH9bz2midh0/W1qXXxwjEMnTjoEp GSe+IIy40R5P/nSi4Kmc+/bausNz+zPGr9vJgrakW5kD+/fdR9y8i/Pxe/HN72VfczBY dX6Q== MIME-Version: 1.0 X-Received: by 10.180.75.110 with SMTP id b14mr2708888wiw.21.1360132503364; Tue, 05 Feb 2013 22:35:03 -0800 (PST) Received: by 10.180.164.43 with HTTP; Tue, 5 Feb 2013 22:35:03 -0800 (PST) In-Reply-To: <1560860.2sJEDpXUvL@scott-latitude-e6320> References: <1878869.epuRBHeDfC@scott-latitude-e6320> <1560860.2sJEDpXUvL@scott-latitude-e6320> Date: Tue, 5 Feb 2013 22:35:03 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043be228b5e37b04d5088656 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 06 Feb 2013 06:35:05 -0000 --f46d043be228b5e37b04d5088656 Content-Type: text/plain; charset=ISO-8859-1 That makes it an open topic. Ugly. Do we have any indication of a consensus of what various implementations do? Do we need to undertake such a survey? -MSK On Tue, Feb 5, 2013 at 10:26 PM, Scott Kitterman wrote: > I fear not. I looked in the internal pyspf tests and it has things like > mechanism=mx/24, so at best it's not clear. Mail::SPF seems to only put > the > mechanisms in comments and not use this bit of the ABNF. > > Unknown is the old name for temperror, so it used to be a valid result. > Perhaps a copy/paste from an old example. > > Scott K > > On Tuesday, February 05, 2013 09:57:09 PM Murray S. Kucherawy wrote: > > I think the ABNF is correct as-is, but there is no example that > illustrates > > the use of mechanisms within a Received-SPF, which would clear up the > > confusion. > > > > The current ABNF is mean to enable things like: > > > > Received-SPF: pass mx=something; a=something; ... > > > > So "mechanism" doesn't need to be quoted, because it expands into all of > > the available mechanism names. What Barry was doing is assuming one > wants > > to produce: > > > > Received-SPF: pass mechanism=mx; ... > > > > ...which was not the intention. > > > > Does that sound right, Barry? Scott? > > > > There is an error in the example upthread though, because it's impossible > > to generate "Received-SPF: unknown ..." as "unknown" isn't a valid result > > string. > > > > -MSK > > > > On Tue, Feb 5, 2013 at 2:50 PM, Scott Kitterman > wrote: > > > Need some help with this one: > > > > > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/53 > > > > > > Message posted by Barry Leiba on 4 Sept 2012: > > > that was intended to support unknown mechanisms. So, if you had an > SPF > > > > > > record from draft-mengwong-spf-00: > > > v=spf1 a mx ptr domainkeys:_dk.%{d} -all > > > > > > The Received-SPF header would look like: > > > Received-SPF: unknown domainkeys=_dk.example.com > > > > > > If that's the case, the text needs work to make it clear, because it's > > > decidedly not. The text below the grammar lists key names and the > meanings > > > of > > > the values. "mechanism" is listed as a key name in that text. So > there's a > > > problem somewhere that needs to be cleared up. > > > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02608.html > > > > > > Downthread from the referenced message, there's a proposed > simplification > > > from > > > Arthur Thisell, but I think it's based on the (I believe incorrect) > > > assumption > > > that mechanism isn't used. > > > > > > Suggestions please. > > > > > > Scott K > > > _______________________________________________ > > > spfbis mailing list > > > spfbis@ietf.org > > > https://www.ietf.org/mailman/listinfo/spfbis > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d043be228b5e37b04d5088656 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That makes it an open topic.=A0 Ugly.

Do we have any indication of a consensus of what various implementations= do?=A0 Do we need to undertake such a survey?

-MSK
<= div class=3D"gmail_extra">

On Tue, Feb 5, 2013 at 10:26 PM, Scott K= itterman <spf2@kitterman.com> wrote:
I fear not. =A0I looked in the internal pyspf tests and it has things like<= br> mechanism=3Dmx/24, so at best it's not clear. =A0Mail::SPF seems to onl= y put the
mechanisms in comments and not use this bit of the ABNF.

Unknown is the old name for temperror, so it used to be a valid result.
Perhaps a copy/paste from an old example.

Scott K

On Tuesday, February 05, 2013 09:57:09 PM Murray S. Kucherawy wrote:
> I think the ABNF is correct as-is, but there is no example that illust= rates
> the use of mechanisms within a Received-SPF, which would clear up the<= br> > confusion.
>
> The current ABNF is mean to enable things like:
>
> Received-SPF: pass mx=3Dsomething; a=3Dsomething; ...
>
> So "mechanism" doesn't need to be quoted, because it exp= ands into all of
> the available mechanism names. =A0What Barry was doing is assuming one= wants
> to produce:
>
> Received-SPF: pass mechanism=3Dmx; ...
>
> ...which was not the intention.
>
> Does that sound right, Barry? =A0Scott?
>
> There is an error in the example upthread though, because it's imp= ossible
> to generate "Received-SPF: unknown ..." as "unknown&quo= t; isn't a valid result
> string.
>
> -MSK
>
> On Tue, Feb 5, 2013 at 2:50 PM, Scott Kitterman <spf2@kitterman.com> wrote:
> > Need some help with this one:
> >
> > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/53 > >
> > =A0Message posted by Barry Leiba on 4 Sept 2012:
> > =A0 =A0 that was intended to support unknown mechanisms. So, if y= ou had an SPF
> >
> > =A0 =A0 record from draft-mengwong-spf-00:
> > =A0 =A0 =A0 =A0 v=3Dspf1 a mx ptr domainkeys:_dk.%{d} -all
> >
> > =A0 =A0 The Received-SPF header would look like:
> > =A0 =A0 =A0 =A0 Received-SPF: unknown domainkeys=3D_dk.example.com
> >
> > If that's the case, the text needs work to make it clear, bec= ause it's
> > decidedly not. The text below the grammar lists key names and the= meanings
> > of
> > the values. "mechanism" is listed as a key name in that= text. So there's a
> > problem somewhere that needs to be cleared up.
> >
> > http://www.ietf.org/mail-archive/web/spfbis/= current/msg02608.html
> >
> > Downthread from the referenced message, there's a proposed si= mplification
> > from
> > Arthur Thisell, but I think it's based on the (I believe inco= rrect)
> > assumption
> > that mechanism isn't used.
> >
> > Suggestions please.
> >
> > Scott K
> > _______________________________________________
> > spfbis mailing list
> > spfbis@ietf.org
> > https://www.ietf.org/mailman/listinfo/spfbis
_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--f46d043be228b5e37b04d5088656-- From spf2@kitterman.com Tue Feb 5 22:35:17 2013 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 A5C6F21F8999 for ; Tue, 5 Feb 2013 22:35:17 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dD8Hf4h8UHDs for ; Tue, 5 Feb 2013 22:35:17 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E766A21F897A for ; Tue, 5 Feb 2013 22:35:16 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 67EEC20E410F; Wed, 6 Feb 2013 01:35:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360132516; bh=tboZv4c4foCM7sxvPXu2DpGqGeWS/NH887qVrqTFvl4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ff2VaybEQ5sHkenoiPRNYlS0CgVX4tworU4BeAiUxqSnJnHVAw9kWyUvHhl8TCAzP e2YHnqLkTu9uTDJWsCQB9wz8754AK+Xwgr22ycP8/DDLi/A6zR72ZQ5xfgcf7+A6W8 tlocizOUCvgOPpMxfnxNJx8R5tyXDOuyIJ6zWpEI= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2661320E40B2; Wed, 6 Feb 2013 01:35:15 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 06 Feb 2013 01:35:14 -0500 Message-ID: <1582575.VsSs9YShWJ@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; 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] Revisit: Issue #36: RFC 2119 key words 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, 06 Feb 2013 06:35:17 -0000 On Tuesday, February 05, 2013 09:22:38 PM Murray S. Kucherawy wrote: > "Overall, when RFC 4408 was drafted, > care was taken to capitalize RFC 2119 > keywords, and use the lower case > words as regular English meaning. While > most of the lower case words have been changed to synonyms, a few have been > changed into RFC 2119 keywords. I > think most (but sadly, not all) of these capitalizations are wrong." > > Could this be made more specific? Which ones are wrong? Unfortunately Arthur hasn't been very active lately, so I was hoping someone experienced with RFC lawyering could have a look and see if there were any they felt were wrong. I've already gone back and fixed several that I concluded in retrospect were wrong. Scott K From spf2@kitterman.com Tue Feb 5 22:37:36 2013 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 AE0C321F84CE for ; Tue, 5 Feb 2013 22:37:36 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUCxMDHsTVB5 for ; Tue, 5 Feb 2013 22:37:36 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5BA21F8414 for ; Tue, 5 Feb 2013 22:37:36 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AA3B820E410F; Wed, 6 Feb 2013 01:37:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360132655; bh=FXwZqEydbG1PBWMc2E3HEpV4NbGy7XflMCxrrCaIXWI=; h=From:To:Subject:Date:From; b=LJMHMAv6UOuVuQh7Q2Tb3DzH99b7K7VcucatUrk12c4T2sKmi1rnUjrBnBQHlNrZ1 ThDiVOFkXC5S0q7gZ/phc/GzozzWWsHqt27+9ba02+UQR4e6iQAzBmHJGfI2sfmN/+ khsVU+ZDanO0pEoyGSMtFovXJvmeA6drlix64Ni8= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 766AF20E40B2; Wed, 6 Feb 2013 01:37:35 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 06 Feb 2013 01:37:33 -0500 Message-ID: <2200169.zLyB0fbaOB@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Fwd: Re: Ticket #47 domain-spec 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, 06 Feb 2013 06:37:36 -0000 Resending to the list as it doesn't look like the list copy ever arrived. Scott K ---------- Forwarded Message ---------- Subject: Re: [spfbis] Ticket #47 domain-spec Date: Wednesday, February 06, 2013, 12:56:03 AM From: Stuart Gathman To: spfbis@ietf.org CC: spf2@kitterman.com Resent because ietf.org is ignoring my emails for some reason (no confirmation requests sent). On 02/05/2013 11:16 PM, Stuart Gathman wrote: > On 02/05/2013 04:34 PM, Murray S. Kucherawy wrote: >> Feel free to point me at previous discussion, but why "(even when the >> connection type is IPv6)"? > Because that is what rfc4408 says. The A and MX mechanisms look for > A or AAAA RRs depending on the > connection type. EXISTS, on the other hand, always looks only for A > records. That was perfectly clear. > > The ambiguity is what to do when there is a DNS error. For other > mechanisms, a temperror would result, and > lacking any further specification, you could assume the same for > exists. However EXISTS is special, and given its intended usage, > a temperror is not as helpful (and maybe you could argue that if the > DNS service is unavailable, the RR doesn't "exist" - or maybe that the > record is in a superposition of "exists" and "not exists" until it is > able to be observed). > I added a test to the test suite that allows either interpretation for now. After mulling it over, I am on the side of sticking with temperror. But I won't be alarmed if spfbis decides to go with nomatch. That would just nudge applications away from advanced filtering (which typically involve localpart which is problematic in itself), and more toward logging. ----------------------------------------- From spf2@kitterman.com Tue Feb 5 22:40:49 2013 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 83A9621F84CE for ; Tue, 5 Feb 2013 22: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_92=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEcHiGTYedrp for ; Tue, 5 Feb 2013 22:40:48 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AAD1121F8414 for ; Tue, 5 Feb 2013 22:40:48 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 35FFD20E410F; Wed, 6 Feb 2013 01:40:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360132848; bh=UABL5x/sBCmFHwBv7XEHREOyyGhMgrCQ9QxB98FmTXI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SjkdcJt7kYbEeqxKs/VYqLuWZw/e8Ho5MhXTDHat6V7baf0VFpfsCCZUSbOX66ChJ M6BDvDWhgKugPja+tOgKddxneeAdrk+NLhSCDbl69zSZFS1p7ztJrMN9fQ/Z3JQTW4 G2XLOP+vxtqLYCjt7sOkOEuiU2yjARln9AFFRF78= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 063D920E40B2; Wed, 6 Feb 2013 01:40:47 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 06 Feb 2013 01:40:46 -0500 Message-ID: <1937618.TQ5hFNaY6t@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <1878869.epuRBHeDfC@scott-latitude-e6320> <1560860.2sJEDpXUvL@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] Possible ABNF nit with Received-SPF - #53 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, 06 Feb 2013 06:40:49 -0000 I think we can pick what we want. Mechanism is there for forensics, not for filtering, so changing it won't affect interoperability. Personally, I think mx=example.com is a lot more useful than mechanism=mx since there may be more than one of a mechanism type in a record, but I'm open to either approach. I do think we should make it clear and then give an example. Scott K On Tuesday, February 05, 2013 10:35:03 PM Murray S. Kucherawy wrote: > That makes it an open topic. Ugly. > > Do we have any indication of a consensus of what various implementations > do? Do we need to undertake such a survey? > > -MSK > > On Tue, Feb 5, 2013 at 10:26 PM, Scott Kitterman wrote: > > I fear not. I looked in the internal pyspf tests and it has things like > > mechanism=mx/24, so at best it's not clear. Mail::SPF seems to only put > > the > > mechanisms in comments and not use this bit of the ABNF. > > > > Unknown is the old name for temperror, so it used to be a valid result. > > Perhaps a copy/paste from an old example. > > > > Scott K > > > > On Tuesday, February 05, 2013 09:57:09 PM Murray S. Kucherawy wrote: > > > I think the ABNF is correct as-is, but there is no example that > > > > illustrates > > > > > the use of mechanisms within a Received-SPF, which would clear up the > > > confusion. > > > > > > The current ABNF is mean to enable things like: > > > > > > Received-SPF: pass mx=something; a=something; ... > > > > > > So "mechanism" doesn't need to be quoted, because it expands into all of > > > the available mechanism names. What Barry was doing is assuming one > > > > wants > > > > > to produce: > > > > > > Received-SPF: pass mechanism=mx; ... > > > > > > ...which was not the intention. > > > > > > Does that sound right, Barry? Scott? > > > > > > There is an error in the example upthread though, because it's > > > impossible > > > to generate "Received-SPF: unknown ..." as "unknown" isn't a valid > > > result > > > string. > > > > > > -MSK > > > > > > On Tue, Feb 5, 2013 at 2:50 PM, Scott Kitterman > > > > wrote: > > > > Need some help with this one: > > > > > > > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/53 > > > > > > > > Message posted by Barry Leiba on 4 Sept 2012: > > > > that was intended to support unknown mechanisms. So, if you had an > > > > SPF > > > > > > record from draft-mengwong-spf-00: > > > > v=spf1 a mx ptr domainkeys:_dk.%{d} -all > > > > > > > > The Received-SPF header would look like: > > > > Received-SPF: unknown domainkeys=_dk.example.com > > > > > > > > If that's the case, the text needs work to make it clear, because it's > > > > decidedly not. The text below the grammar lists key names and the > > > > meanings > > > > > > of > > > > the values. "mechanism" is listed as a key name in that text. So > > > > there's a > > > > > > problem somewhere that needs to be cleared up. > > > > > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02608.html > > > > > > > > Downthread from the referenced message, there's a proposed > > > > simplification > > > > > > from > > > > Arthur Thisell, but I think it's based on the (I believe incorrect) > > > > assumption > > > > that mechanism isn't used. > > > > > > > > Suggestions please. > > > > > > > > Scott K > > > > _______________________________________________ > > > > spfbis mailing list > > > > spfbis@ietf.org > > > > https://www.ietf.org/mailman/listinfo/spfbis > > > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Tue Feb 5 23:01:33 2013 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 AE58A21F85BC for ; Tue, 5 Feb 2013 23:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYyoaCt7l62l for ; Tue, 5 Feb 2013 23:01:32 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CF10821F85AC for ; Tue, 5 Feb 2013 23:01:32 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5A23220E410F; Wed, 6 Feb 2013 02:01:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360134092; bh=SB7PdB8mzDhIN5hPeSKeCpcZEWb5hT+CV7XDjWl8Oa8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LVjxDkCU1ofKk2zTeBr4jmFhAnidU01Hy+azFiJHkwDFZiEayxW/6Cnn79noaKjV/ 9HX2/qjfCAnS1M6LyPmZBniN319ASt2Wf88aGQR6RV34YvEoD47XMwo49W8a4ArWGI 4S1I4qDYlPTvlbKv2uXMvP6um5CO/zc/71S1oRDA= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2F36920E40B2; Wed, 6 Feb 2013 02:01:31 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 06 Feb 2013 02:01:30 -0500 Message-ID: <2436018.g36R4X2mnu@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> <2168659.7lAyFt0zqY@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] Summary of issues for draft-ietf-spfbis-4408bis 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, 06 Feb 2013 07:01:33 -0000 On Tuesday, February 05, 2013 08:14:13 PM Murray S. Kucherawy wrote: ... > When evaluating the "mx" mechanism, the number of MX resource records > queried MUST NOT exceed 10. If the evaluation of an "mx" mechanism results > in more than 10 resource records being , the "mx" > mechanism MUST produce a "permerror" result (see Section xxx). ... What section is xxx meant to be? Scott K From spf2@kitterman.com Tue Feb 5 23:08:17 2013 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 6DA4921F84F2 for ; Tue, 5 Feb 2013 23:08:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBTR91RSMngM for ; Tue, 5 Feb 2013 23:08:16 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 66D6621F88ED for ; Tue, 5 Feb 2013 23:08:16 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E5CAB20E410F; Wed, 6 Feb 2013 02:08:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360134495; bh=XvgPlSvqdAFtmEeEQ8wZaT6yKfhxONUH7VeJGB1lMTg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=U3HZ+nv1j3KfOfTGU2hX7DmjtFzCId5Vsdyq/z1DrNY1YR/0nsL/d35qW4r474JuH bQIDjxkNyGrptY6uc6PJZcorDwr45VeBFqtV9AWoTXe0i4g0V7X2ywRS6iHHZ6pel8 A9NpmuVcib4IxtIoDGStCOQX+Qf0cr18eLChcJLo= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id AC38A20E40B2; Wed, 6 Feb 2013 02:08:15 -0500 (EST) From: Scott Kitterman To: "spfbis@ietf.org" Date: Wed, 06 Feb 2013 02:08:14 -0500 Message-ID: <1757875.UdYfy5sZbb@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> <2168659.7lAyFt0zqY@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] Summary of issues for draft-ietf-spfbis-4408bis 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, 06 Feb 2013 07:08:17 -0000 I adjusted a bit. Here's what I have locally now: > When evaluating the "mx" mechanism, the number of MX resource records > queried MUST NOT exceed 10. If the evaluation of an "mx" mechanism > results in more than 10 A resource records to be queried, the "mx" > mechanism MUST produce a "permerror" result. > > When evaluating the "ptr" mechanism or the %{p} macro, the number of > PTR resource records queried MUST NOT exceed 10. If the evaluation > of a "ptr" mechanism results in more than 10 hostnames returned to > be queried, all records other than the first 10 MUST be ignored. > > The reason for the disparity is that the set of and contents of the > MX record are under control of the domain owner, while the set of > and contents of PTR records are under control of the owner of the IP > address actually making the connection. > > These limits are per mechanism or macro in the record, and are in > addition to the lookup limits specified above. Let me know if that works. Scott K On Tuesday, February 05, 2013 08:14:13 PM Murray S. Kucherawy wrote: > How about: > > When evaluating the "mx" mechanism, the number of MX resource records > queried MUST NOT exceed 10. If the evaluation of an "mx" mechanism results > in more than 10 resource records being , the "mx" > mechanism MUST produce a "permerror" result (see Section xxx). > > When evaluating the "ptr" mechanism, the number of PTR resource records > queried MUST NOT exceed 10. If the evaluation of a "ptr" mechanism results > in more than 10 resource records being returned, all records other than the > first 10 MUST be ignored. > > The reason for the disparity is that the set of and contents of the MX > record are under control of the domain owner, while the set of and contents > of PTR records are under control of the owner of the IP address actually > making the connection. > > These limits are per mechanism or macro in the record, and are in addition > to the lookup limits specified above. > > > > Could we change "10" to "a fixed but possibly configurable limit", and > indicate that most implementations use 10 as that limit? 10 is effectively > arbitrary, unless studies have shown that it's the best answer. > > Also, the ignoring of PTR replies beyond the first 10 renders the protocol > non-deterministic given that replies come back in a random order. Are we > okay with that? > > -MSK > > On Tue, Feb 5, 2013 at 7:13 PM, Scott Kitterman wrote: > > Sure. Do you have a suggestion? > > > > Scott K > > > > On Tuesday, February 05, 2013 07:08:35 PM Murray S. Kucherawy wrote: > > > Got it. Could we massage that paragraph in to explain the context of > > > the > > > rule being imposed? > > > > > > -MSK > > > > > > On Tue, Feb 5, 2013 at 3:02 PM, Scott Kitterman > > > > wrote: > > > > The difference is that the contents of the MX record are under control > > > > of > > > > > > the > > > > domain owner. The number of PTR records are under control of the > > > > owner of > > > > > > the > > > > IP address actually making the connection. If we allow for permerror > > > > on > > > > > > too > > > > many PTR, then that gives someone trying to avoid SPF fail an easy way > > > > to > > > > > > turn > > > > a fail into a permerror. A similar risk does not exist with MX. > > > > > > > > Scott K > > > > > > > > On Tuesday, February 05, 2013 01:35:55 PM Murray S. Kucherawy wrote: > > > > > Doesn't the same attack exist if one lists >10 MX records? > > > > > > > > > > Just wondering why MX isn't getting the same treatment as PTR in the > > > > > proposed new text. > > > > > > > > > > -MSK > > > > > > > > > > On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman > > > > > > > > wrote: > > > > > > On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote: > > > > > > > #43 New requirement for mx: or ptr records > > > > > > > > > > > > Issue: > > > > > > > in section 4.6.4, there is a new requirement that there must not > > > > be > > > > > > more > > > > > > > > > > > than 10 records for mx: or ptr:. This completely wrong for ptr: > > > > because > > > > > > > > > > > a > > > > > > > spammer could choose to send spam from a host with more than 10 > > > > PTR > > > > > > > > > records, thus forcing a domain's SPF record to return permerror, > > > > > > > > instead > > > > > > > > > > of > > > > > > > > > > > > > fail. If anything, more than 10 PTR records should cause the ptr: > > > > > > mechanism > > > > > > > > > > > > > to automatically not-match. It should also be made clear that > > > > > > > the > > > > > > > > %{p} > > > > > > > > > > > macro is valid no matter how many PTR records are returned. > > > > > > > > > > > > Proposed new text for 4.6.4 (in my local copy): > > > > > > > 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. If more than 10 "mx" records are returned for > > > > > > > this > > > > > > > further lookup, a permerror MUST be returned. If more than 10 > > > > > > > "ptr" > > > > > > > > > > > > > > records are returned for this further lookup (either due to use > > > > of > > > > > > > > > a "ptr" mechanisms, or the %{p} macro) processing MUST be > > > > terminated > > > > > > > > > after 10 records. This limit is per mechanism or macro in the > > > > > > > record and in addition to the lookup limits above. > > > > > > > > > > > > Comments please. If no one objects, I'll include it. > > > > > > > > > > > > Scott K > > > > > > _______________________________________________ > > > > > > spfbis mailing list > > > > > > spfbis@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/spfbis > > > > > > > > _______________________________________________ > > > > spfbis mailing list > > > > spfbis@ietf.org > > > > https://www.ietf.org/mailman/listinfo/spfbis > > > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Tue Feb 5 23:13:54 2013 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 0E9E021F88FD for ; Tue, 5 Feb 2013 23:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2hiTsdHEYnK for ; Tue, 5 Feb 2013 23:13:53 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 501A921F8921 for ; Tue, 5 Feb 2013 23:13:53 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CF52C20E410F; Wed, 6 Feb 2013 02:13:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360134832; bh=gqluNe527Btv8qTzPHYURitc5pVTZHEFuUPNs/ayMLU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KICIx3JhOhuLEv1zeTOuv2mhqIfznhw0nqU7p1VP4lFmz30AsAKqOD2kcj7j2VxHd FkvNj+4NZ18dJyFbrQbG7wVXak5CFpqQa0Ur6TteAgh8fsPJmOh71TEVYJu6+gbxP/ D9SH7vtM93l5lMqkW//OXWs2YZUpMMg2QYbrHi54= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9E6BE20E40B2; Wed, 6 Feb 2013 02:13:52 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 06 Feb 2013 02:13:50 -0500 Message-ID: <14949399.BDeG1EDbxJ@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 06 Feb 2013 07:13:54 -0000 On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote: > Hello, > > According to the SPFBIS WG Charter the working group was scheduled to > submit draft-ietf-spfbis-4408bis for publication in December > 2012. Here is the list of open issues [1]: > > #22 RFC 4408: Section 2.5.7 PermError on invalid domains after macro > expansion > > #24 RFC 4408: Reasonable DNS error limits > > #29 RFC 4408: Section 2.5.4 - mark on fail > > #34 Throw a temperror - Section 5.2 > > #35 authorized_spf domain name - Section 9.1.1 > > #36 RFC 2119 key words > > #37 spf classic > > #38 Deprecated > > #39 Temporary errors implied as only caused by DNS errors > > #40 Wildcard records > > #41 Multiple DNS errors > > #42 Record Evaluation > > #43 New requirement for mx: or ptr records > > #44 Section 5.4 does not mention requirement in section 4.6.4 > > #45 Section 5.5 steps > > #46 DNS reply in Section 5.7 > > #47 domain-spec > > #48 Section 8.1 - macro defs > > #49 IANA registry for SPF modifiers > > #50 Terminology > > #51 Remove A-R from 4408bis > > #52 Section 8.1 *Macro Definitions > > #53 Possible ABNF nit with Received-SPF > > #54 Section 9.2.1 of 4408bis > > #55 Section 9.2.2 Forwarding Services and Aliases > > #56 Section 9.2.2 Forwarding Services and Aliases > > #57 x-* fields in 4408bis > > #58 Local policy in 4408bis > > #59 Remove section 9.1.1 DNS Resource Considerations > > #6 RFC 4408 Section 10.1 - Processing limits needs clarification and > reorganization > > #33 Marked Failed Mail Exposure > > Regards, > S. Moonesamy > > 1. http://trac.tools.ietf.org/wg/spfbis/trac/report/1 Quite a number of issues were not up to date in the tracker. I've gone through and statused issues. Scott K From spf2@kitterman.com Tue Feb 5 23:19:35 2013 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 9AA5721F8921 for ; Tue, 5 Feb 2013 23:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Qi-Viod3ecu for ; Tue, 5 Feb 2013 23:19:35 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E1E9621F8645 for ; Tue, 5 Feb 2013 23:19:34 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6DAE520E410F; Wed, 6 Feb 2013 02:19:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360135174; bh=jJkxB5lcVB3kbwSfqBw+mgMJ9wVKYRVelsLIyvV84ns=; h=From:To:Subject:Date:In-Reply-To:References:From; b=L/kUDej8s5caCz/ztxX7rlY3ab3jZS3Dd1Tzg3T+qE1HzK8eETH3nJUt5r6ovjfEh uAXg5CJxuepvJC3jBIrh+vaZfZuWb5mbY5erMwcyKJsjr2lyt6oRGz7MQY0zVHYhF+ 56LmpHeVnON9RwzOMcJWQXy6fr5CAUg5IvMQnwa8= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4454D20E40B2; Wed, 6 Feb 2013 02:19:33 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 06 Feb 2013 02:19:32 -0500 Message-ID: <1899843.LY4PKNAfXb@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; 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] Revisit: Issue #38: Deprecated 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, 06 Feb 2013 07:19:35 -0000 On Tuesday, February 05, 2013 09:27:15 PM Murray S. Kucherawy wrote: > I think we could stand to get rid of the definition we have for > "Deprecated" in Section 1, but still leave the notations elsewhere in the > document. > > Operationally, we have to continue to support ptr and %p because people are > using them. That means compliant implementations still implement them. > We're basically stuck with it. The right thing to do is what's done in the > "ptr" description that explains why we don't like it anymore. > > -MSK Done. Thanks. Scott K From WebMaster@Commerco.Net Wed Feb 6 00:38:54 2013 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 5EF8121F8501 for ; Wed, 6 Feb 2013 00:38:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lHvvoIVtgbI for ; Wed, 6 Feb 2013 00:38:53 -0800 (PST) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8047221F85FE for ; Wed, 6 Feb 2013 00:38:48 -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:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=4/kGKTC8CSt1zdzjKPgvuHDOlQ3dStq4if7ZcCaKYe6PSnY5eLVhRdy73RCAf2JP9MfyHSFNolJ+rSZ8bpo1rNhg2NX1+V94bM+InRMc/GEkfCD2Jf5dlPMFdLdX1TLuZwI0FDD+sGfX1ztd9EoVnNWf2o9VKKlq914RDpwxJ4I= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.5) with ESMTP (EHLO [10.240.241.49]); Wed, 06 Feb 2013 08:38:45 +0000 Message-ID: <51121687.6040903@Commerco.Net> Date: Wed, 06 Feb 2013 01:38:31 -0700 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: "Murray S. Kucherawy" Subject: Re: [spfbis] Revisit: Issue #38: Deprecated 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, 06 Feb 2013 08:38:54 -0000 Murray, I have never cared to use the PTR syntax for many of the reasons already exhaustively covered in the most recent threads and then some. I am far more happy to use the IP4 syntax instead, as it does not depend upon the "kindness" (read responsiveness or willingness to adjust PTR record) of the IP address provider. My own experience with this has never been problematic, however there are documented cases where ISPs can be very difficult to work with on getting PTRs changed for whatever reasons. Also, in the 8 or so years that we have implemented SPF around here, as I recall, the IP4 record entries have only had to change once (perhaps twice). For smaller company implementations, using IP4 works great, as there are only going to be a few individual IP addresses for the approved sending MTAs. For larger company implementations, using IP4 works great (with a CIDR range), as the representation of the publisher is that the mail is coming from an MTA within their network. While less granular, the security seen in larger environments will be presumably better than that of smaller environments. Perhaps larger environments are also better suited to deal with a lack of granularity necessitated by using a CIDR range rather than an individual IP address (e.g., hopefully their network does not get hacked and a bogus MTA is established somewhere in the approved IP space within the CIDR range). Of course, those kinds of discussions are probably well beyond the scope of SPFbis. While there are obviously some good reasons to want to implement PTR (as some folks do this today in their TXT records), for many environments, it is simply not a feature of SPF needed in their TXT records. In my own view, PTR could be depreciated, however as doing so would result in breaking existing implementations without a show stopping reason to do so, perhaps simply advising against using PTR in TXT records may be best. Best, Alan M On 2/5/2013 10:27 PM, Murray S. Kucherawy wrote: > I think we could stand to get rid of the definition we have for > "Deprecated" in Section 1, but still leave the notations elsewhere in > the document. > > Operationally, we have to continue to support ptr and %p because people > are using them. That means compliant implementations still implement > them. We're basically stuck with it. The right thing to do is what's > done in the "ptr" description that explains why we don't like it anymore. > > -MSK > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From sm@elandsys.com Wed Feb 6 00:51:36 2013 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 9150021F8793 for ; Wed, 6 Feb 2013 00:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybp8tjcZNyGf for ; Wed, 6 Feb 2013 00:51:36 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0574121F86B0 for ; Wed, 6 Feb 2013 00:51:35 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.138.233]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r168pHDU007587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2013 00:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360140689; bh=A73yOpjLj90kV00j/dDsJBck0Df37EI/EilJ+PuSTdQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xH/eFChkE2qn+8cANkexm9MLnVP+zpblaXs9GF0JMACMna6op4hiK9fqMAxt9ww0W rFGgrPzvM76Ul2fpLbF8AkjanZD/n77PcobKyMnt8EgRJUDtMVabX5ZDjHgfXyFqMP ACp1UVR2ArR8JakFeyADMf+IRU802RQkVcoV0r50= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1360140689; i=@elandsys.com; bh=A73yOpjLj90kV00j/dDsJBck0Df37EI/EilJ+PuSTdQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Q3yq2qmQYPJFSGKdVI1tPjkArMa8ap46Nq33DFKly/kySrwnzlF8K3xHE5e2TTCPY GndUwjw4hf51v1yaAWLJP8MYI8JfzVx/7vRC9yG4zRAP09pvzvmmekp6ea7n1Ce16h gCl9CwaBfNlDZInI+hmnkFg8fMpOYaIwedahq06I= Message-Id: <6.2.5.6.2.20130206003135.09d272e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Feb 2013 00:46:13 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130131054739.0a324468@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Murray S. Kucherawy" Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis 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, 06 Feb 2013 08:51:36 -0000 At 21:09 05-02-2013, Murray S. Kucherawy wrote: >Since the list of open issues has been seriously trimmed by someone >since SM posted this > (only 16 left), I'll open a thread for each of the open ones now > with a comment on each based on the current draft version (-09). The working group is making progress if open issues are resolved. Thanks, Murray, for the separate threads. It does make it easier for me to track the discussions. A reading of the entire draft is needed at some point. That could be done during the WGLC. I have read all the comments posted by WG participants. I may ask questions once in a while to understand the arguments. Regards, S. Moonesamy From internet-drafts@ietf.org Thu Feb 7 00:11:52 2013 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 08C6021F8941; Thu, 7 Feb 2013 00:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDj1hRXCcI3b; Thu, 7 Feb 2013 00:11:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FB721F8906; Thu, 7 Feb 2013 00:11:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> Date: Thu, 07 Feb 2013 00:11:51 -0800 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-10.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, 07 Feb 2013 08:11:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Dom= ains in Email, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-10.txt Pages : 73 Date : 2013-02-07 Abstract: Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby an ADMD can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Thu Feb 7 00:18:10 2013 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 3C1E021F88CA for ; Thu, 7 Feb 2013 00:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMTqq1IRQbu6 for ; Thu, 7 Feb 2013 00:18:09 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 930FE21F886A for ; Thu, 7 Feb 2013 00:18:09 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AF1C020E407B; Thu, 7 Feb 2013 03:18:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360225088; bh=G4aoQtmZV7XadxOjT41r0rr6gi9BvYUythTFNb8NOgo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HbJln4dR2FpP285HpCWHPTmqxyjytvODGgQHTALjbd3o6VsyUu9IN36jq10B2b+Iy 81HNkaWh5rOpCzjEyNEfiLRF0+mPxL+G5XkX5TvcmLpwiQFCuH1gTQB7ZuunBNOLON 6vXQ+9xQ63wthwof0fAc90OpFPsEa2GxJH7UPnZ0= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8880F20E4076; Thu, 7 Feb 2013 03:18:08 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 07 Feb 2013 03:18:06 -0500 Message-ID: <1377522.ULX4pbEB9u@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> References: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-10.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, 07 Feb 2013 08:18:10 -0000 On Thursday, February 07, 2013 12:11:51 AM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the SPF Update Working Group of > the IETF. > > Title : Sender Policy Framework (SPF) for Authorizing Use > of Domains in Email, Version 1 Author(s) : Scott Kitterman > Filename : draft-ietf-spfbis-4408bis-10.txt > Pages : 73 > Date : 2013-02-07 I believe this update addresses these open issues in the tracker: #36 RFC 2119 key words #38 Deprecated #43 New requirement for mx: or ptr records #45 Section 5.5 steps #46 DNS reply in Section 5.7 #48 Section 8.1 - macro defs #52 Section 8.1 *Macro Definitions #33 Marked Failed Mail Exposure http://trac.tools.ietf.org/wg/spfbis/trac/report/1 Please review. I'll give people a bit of time to digest the revised draft and raise concerns if they have them before I mark the issues as fixed. Thanks to those who helped with the updates. Scott K From sm@elandsys.com Thu Feb 7 00:32:29 2013 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 F266421F8523 for ; Thu, 7 Feb 2013 00:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa-iqcJLseNT for ; Thu, 7 Feb 2013 00:32:27 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB4A21F8521 for ; Thu, 7 Feb 2013 00:32:27 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.130.194]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r178WEav013166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Feb 2013 00:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360225945; bh=dW/M3olTVvBm/k9IV5xdzaHXlG0iexBoatwBjrcQy2c=; h=Date:To:From:Subject:In-Reply-To:References; b=nFahUrvgzm4LvQxiNUni2kDsB3KcxcURxODmo3dNYMA1tZfBzlnaQY0r+gMvmx2f1 9nCoSIdInElz5N8+FtCAL3BZOIo3dJBmgSHvXYanvxgk89ScucYI1iOT65ZfO18FiM r09xfY/zyFTiC4pWOWrgdpkqa51cyW7yiBa6A6+A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1360225945; i=@elandsys.com; bh=dW/M3olTVvBm/k9IV5xdzaHXlG0iexBoatwBjrcQy2c=; h=Date:To:From:Subject:In-Reply-To:References; b=R+OE3g+Zj6F5ERXVEubJdlTZQGgEXEfsEK4tsekp4kslq9pIyB8pifH6/14x2/ueM MBsr9zEKJcYOo/hA1jcIzhtXpGwJ6kB6gfhVGHvMcdXenyysC3nLv2bjrjr2fNAtVh gOPzgnlrc16rfhe475NPwLRuwkiuRNFQ9aqTxNco= Message-Id: <6.2.5.6.2.20130207002731.0b1ddc38@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 07 Feb 2013 00:31:24 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1377522.ULX4pbEB9u@scott-latitude-e6320> References: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> <1377522.ULX4pbEB9u@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-10.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, 07 Feb 2013 08:32:29 -0000 At 00:18 07-02-2013, Scott Kitterman wrote: >I believe this update addresses these open issues in the tracker: > >#36 RFC 2119 key words >#38 Deprecated >#43 New requirement for mx: or ptr records >#45 Section 5.5 steps >#46 DNS reply in Section 5.7 >#48 Section 8.1 - macro defs >#52 Section 8.1 *Macro Definitions >#33 Marked Failed Mail Exposure > >http://trac.tools.ietf.org/wg/spfbis/trac/report/1 > >Please review. I'll give people a bit of time to digest the revised draft and Please note that Issue #29 [1] was closed a few days ago. Regards, S. Moonesamy 1. http://trac.tools.ietf.org/wg/spfbis/trac/ticket/29 From spf2@kitterman.com Thu Feb 7 00:38:04 2013 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 B22B921F860A for ; Thu, 7 Feb 2013 00:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVYXWoi6SzQB for ; Thu, 7 Feb 2013 00:38:03 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8709921F8506 for ; Thu, 7 Feb 2013 00:38:03 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 18AFD20E407B; Thu, 7 Feb 2013 03:38:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360226283; bh=4nmrwXewWnEYABxb6E/mLm+JBZGNAIZ1K56c8K+AF6U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bEIz5Ax9yrIuDDnUe3EHj97tUTezvpyw166a/FBDG2bp1gbNJbWkervbShtM/UsWN eDoOEXqSo6JnzFIpf8F3vz1kpdCtZ9Hfp7qPmxD2t8XWffVQB1Rem17e53MWZaDTgG ZIcVJDLPuXjDK6MtchI0ilFGHct79KcVTXjKGptw= Received: from scott-latitude-e6320.localnet (unknown [108.167.77.246]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DF6BC20E4076; Thu, 7 Feb 2013 03:38:02 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 07 Feb 2013 03:38:01 -0500 Message-ID: <6365284.TMsVqIu2gP@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130207002731.0b1ddc38@resistor.net> References: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> <1377522.ULX4pbEB9u@scott-latitude-e6320> <6.2.5.6.2.20130207002731.0b1ddc38@resistor.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] I-D Action: draft-ietf-spfbis-4408bis-10.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, 07 Feb 2013 08:38:04 -0000 On Thursday, February 07, 2013 12:31:24 AM S Moonesamy wrote: > At 00:18 07-02-2013, Scott Kitterman wrote: > >I believe this update addresses these open issues in the tracker: > > > >#36 RFC 2119 key words > >#38 Deprecated > >#43 New requirement for mx: or ptr records > >#45 Section 5.5 steps > >#46 DNS reply in Section 5.7 > >#48 Section 8.1 - macro defs > >#52 Section 8.1 *Macro Definitions > >#33 Marked Failed Mail Exposure > > > >http://trac.tools.ietf.org/wg/spfbis/trac/report/1 > > > >Please review. I'll give people a bit of time to digest the revised draft > >and > Please note that Issue #29 [1] was closed a few days ago. > > Regards, > S. Moonesamy > > 1. http://trac.tools.ietf.org/wg/spfbis/trac/ticket/29 Yes, because the text about which there was a specific complaint that caused it to be reopened no longer exists. I went through and closed a number of issues earlier in the week since their status in the tracker was not correct. Those actions are unrelated to this new revision. Scott K From superuser@gmail.com Thu Feb 7 00:45:07 2013 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 1982021F8633 for ; Thu, 7 Feb 2013 00:45:07 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E6B2gb4NcVV for ; Thu, 7 Feb 2013 00:45:06 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id CD56521F8630 for ; Thu, 7 Feb 2013 00:45:05 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id ds1so5744807wgb.2 for ; Thu, 07 Feb 2013 00:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ygNxdH1O7fk3Ea2HAA5ZNVdGZ7KfXOtR/nF5CM8/gL0=; b=0q3MEHhtn95VBu8N/UTPdXh2/9uduNvuW9UNZajki9OplfmX1SZ6JB4TBq6TjIOsMg DrHPfm1NkPaZaJVowOnqmKOr2WV7ugxW3rOscBk1aNUtqCfcVjYU6dzPRPGvUvF59zCE S2X8Kg/NSwA6VzfTkAPqL+qmWNGcqpXbIdqy8HaN9M4Zo6n6PE2T3YqLpzQpo4YFGI5S 2B6WmR4Ciko1jGcDgxqFv8BdA0T6Wk82E66tQmqdg5EP64dZbt+JVpuJXC2tpbaVNGVb OReZ4mX836IJj9Zoc6Iq1P56+i8Tl3+KFHl1JSlYYoNH/scOgL5xxrj6Vr5sqC7kbZoV jVSA== MIME-Version: 1.0 X-Received: by 10.180.73.80 with SMTP id j16mr973935wiv.5.1360226704805; Thu, 07 Feb 2013 00:45:04 -0800 (PST) Received: by 10.180.164.43 with HTTP; Thu, 7 Feb 2013 00:45:04 -0800 (PST) In-Reply-To: <1937618.TQ5hFNaY6t@scott-latitude-e6320> References: <1878869.epuRBHeDfC@scott-latitude-e6320> <1560860.2sJEDpXUvL@scott-latitude-e6320> <1937618.TQ5hFNaY6t@scott-latitude-e6320> Date: Thu, 7 Feb 2013 00:45:04 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043bdf388dd0c404d51e7597 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 07 Feb 2013 08:45:07 -0000 --f46d043bdf388dd0c404d51e7597 Content-Type: text/plain; charset=ISO-8859-1 It's true that changing this doesn't affect interoperability of policy evaluation, but it does affect anything that parses this field one way if we change it to the other. Consumers of this field are mostly what I'm concerned with here. However, if nobody's heard of something other than humans that eats Received-SPF fields, or if those that do exist already agree on how it's done, then I guess we just come to consensus on which of the two syntaxes we want and run with it. -MSK On Tue, Feb 5, 2013 at 10:40 PM, Scott Kitterman wrote: > I think we can pick what we want. Mechanism is there for forensics, not > for > filtering, so changing it won't affect interoperability. Personally, I > think > mx=example.com is a lot more useful than mechanism=mx since there may be > more > than one of a mechanism type in a record, but I'm open to either approach. > I > do think we should make it clear and then give an example. > > Scott K > > On Tuesday, February 05, 2013 10:35:03 PM Murray S. Kucherawy wrote: > > That makes it an open topic. Ugly. > > > > Do we have any indication of a consensus of what various implementations > > do? Do we need to undertake such a survey? > > > > -MSK > > > > On Tue, Feb 5, 2013 at 10:26 PM, Scott Kitterman > wrote: > > > I fear not. I looked in the internal pyspf tests and it has things > like > > > mechanism=mx/24, so at best it's not clear. Mail::SPF seems to only > put > > > the > > > mechanisms in comments and not use this bit of the ABNF. > > > > > > Unknown is the old name for temperror, so it used to be a valid result. > > > Perhaps a copy/paste from an old example. > > > > > > Scott K > > > > > > On Tuesday, February 05, 2013 09:57:09 PM Murray S. Kucherawy wrote: > > > > I think the ABNF is correct as-is, but there is no example that > > > > > > illustrates > > > > > > > the use of mechanisms within a Received-SPF, which would clear up the > > > > confusion. > > > > > > > > The current ABNF is mean to enable things like: > > > > > > > > Received-SPF: pass mx=something; a=something; ... > > > > > > > > So "mechanism" doesn't need to be quoted, because it expands into > all of > > > > the available mechanism names. What Barry was doing is assuming one > > > > > > wants > > > > > > > to produce: > > > > > > > > Received-SPF: pass mechanism=mx; ... > > > > > > > > ...which was not the intention. > > > > > > > > Does that sound right, Barry? Scott? > > > > > > > > There is an error in the example upthread though, because it's > > > > impossible > > > > to generate "Received-SPF: unknown ..." as "unknown" isn't a valid > > > > result > > > > string. > > > > > > > > -MSK > > > > > > > > On Tue, Feb 5, 2013 at 2:50 PM, Scott Kitterman > > > > > > wrote: > > > > > Need some help with this one: > > > > > > > > > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/53 > > > > > > > > > > Message posted by Barry Leiba on 4 Sept 2012: > > > > > that was intended to support unknown mechanisms. So, if you > had an > > > > > > SPF > > > > > > > > record from draft-mengwong-spf-00: > > > > > v=spf1 a mx ptr domainkeys:_dk.%{d} -all > > > > > > > > > > The Received-SPF header would look like: > > > > > Received-SPF: unknown domainkeys=_dk.example.com > > > > > > > > > > If that's the case, the text needs work to make it clear, because > it's > > > > > decidedly not. The text below the grammar lists key names and the > > > > > > meanings > > > > > > > > of > > > > > the values. "mechanism" is listed as a key name in that text. So > > > > > > there's a > > > > > > > > problem somewhere that needs to be cleared up. > > > > > > > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02608.html > > > > > > > > > > Downthread from the referenced message, there's a proposed > > > > > > simplification > > > > > > > > from > > > > > Arthur Thisell, but I think it's based on the (I believe incorrect) > > > > > assumption > > > > > that mechanism isn't used. > > > > > > > > > > Suggestions please. > > > > > > > > > > Scott K > > > > > _______________________________________________ > > > > > spfbis mailing list > > > > > spfbis@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/spfbis > > > > > > _______________________________________________ > > > spfbis mailing list > > > spfbis@ietf.org > > > https://www.ietf.org/mailman/listinfo/spfbis > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d043bdf388dd0c404d51e7597 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It's true that changing this doesn't aff= ect interoperability of policy evaluation, but it does affect anything that= parses this field one way if we change it to the other.=A0 Consumers of th= is field are mostly what I'm concerned with here.

However, if nobody's heard of something other than humans tha= t eats Received-SPF fields, or if those that do exist already agree on how = it's done, then I guess we just come to consensus on which of the two s= yntaxes we want and run with it.

-MSK


On Tue, Feb 5, 2013 at 10:40 PM, Scott Kitterman <spf2@kitterm= an.com> wrote:
I think we can pick what we want. =A0Mechani= sm is there for forensics, not for
filtering, so changing it won't affect interoperability. =A0Personally,= I think
mx=3Dexample.com is a = lot more useful than mechanism=3Dmx since there may be more
than one of a mechanism type in a record, but I'm open to either approa= ch. =A0I
do think we should make it clear and then give an example.

Scott K

On Tuesday, February 05, 2013 10:35:03 PM Murray S. Kucherawy wrote:
> That makes it an open topic. =A0Ugly.
>
> Do we have any indication of a consensus of what various implementatio= ns
> do? =A0Do we need to undertake such a survey?
>
> -MSK
>
> On Tue, Feb 5, 2013 at 10:26 PM, Scott Kitterman <spf2@kitterman.com> wrote:
> > I fear not. =A0I looked in the internal pyspf tests and it has th= ings like
> > mechanism=3Dmx/24, so at best it's not clear. =A0Mail::SPF se= ems to only put
> > the
> > mechanisms in comments and not use this bit of the ABNF.
> >
> > Unknown is the old name for temperror, so it used to be a valid r= esult.
> > Perhaps a copy/paste from an old example.
> >
> > Scott K
> >
> > On Tuesday, February 05, 2013 09:57:09 PM Murray S. Kucherawy wro= te:
> > > I think the ABNF is correct as-is, but there is no example t= hat
> >
> > illustrates
> >
> > > the use of mechanisms within a Received-SPF, which would cle= ar up the
> > > confusion.
> > >
> > > The current ABNF is mean to enable things like:
> > >
> > > Received-SPF: pass mx=3Dsomething; a=3Dsomething; ...
> > >
> > > So "mechanism" doesn't need to be quoted, beca= use it expands into all of
> > > the available mechanism names. =A0What Barry was doing is as= suming one
> >
> > wants
> >
> > > to produce:
> > >
> > > Received-SPF: pass mechanism=3Dmx; ...
> > >
> > > ...which was not the intention.
> > >
> > > Does that sound right, Barry? =A0Scott?
> > >
> > > There is an error in the example upthread though, because it= 's
> > > impossible
> > > to generate "Received-SPF: unknown ..." as "u= nknown" isn't a valid
> > > result
> > > string.
> > >
> > > -MSK
> > >
> > > On Tue, Feb 5, 2013 at 2:50 PM, Scott Kitterman <spf2@kitterman.com>
> >
> > wrote:
> > > > Need some help with this one:
> > > >
> > > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket= /53
> > > >
> > > > =A0Message posted by Barry Leiba on 4 Sept 2012:
> > > > =A0 =A0 that was intended to support unknown mechanisms= . So, if you had an
> >
> > SPF
> >
> > > > =A0 =A0 record from draft-mengwong-spf-00:
> > > > =A0 =A0 =A0 =A0 v=3Dspf1 a mx ptr domainkeys:_dk.%{d} -= all
> > > >
> > > > =A0 =A0 The Received-SPF header would look like:
> > > > =A0 =A0 =A0 =A0 Received-SPF: unknown domainkeys=3D_dk.example.com
> > > >
> > > > If that's the case, the text needs work to make it = clear, because it's
> > > > decidedly not. The text below the grammar lists key nam= es and the
> >
> > meanings
> >
> > > > of
> > > > the values. "mechanism" is listed as a key na= me in that text. So
> >
> > there's a
> >
> > > > problem somewhere that needs to be cleared up.
> > > >
> > > > http://www.ietf.org/mail-archive/w= eb/spfbis/current/msg02608.html
> > > >
> > > > Downthread from the referenced message, there's a p= roposed
> >
> > simplification
> >
> > > > from
> > > > Arthur Thisell, but I think it's based on the (I be= lieve incorrect)
> > > > assumption
> > > > that mechanism isn't used.
> > > >
> > > > Suggestions please.
> > > >
> > > > Scott K
> > > > _______________________________________________
> > > > spfbis mailing list
> > > > spfbis@ietf.org<= br> > > > > https://www.ietf.org/mailman/listinfo/spfbis
> >
> > _______________________________________________
> > spfbis mailing list
> > spfbis@ietf.org
> > https://www.ietf.org/mailman/listinfo/spfbis
_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--f46d043bdf388dd0c404d51e7597-- From spf2@kitterman.com Thu Feb 7 05:26:32 2013 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 9F40921F85CE for ; Thu, 7 Feb 2013 05:26:32 -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_92=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GreOckwEw7c for ; Thu, 7 Feb 2013 05:26:31 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id B696721F86EB for ; Thu, 7 Feb 2013 05:26:31 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id E1B1DD0408A; Thu, 7 Feb 2013 07:26:30 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360243590; bh=dQkR6kgLNPLcZuqCBHimF6lFO2x8QXsu09PlvxmRN+U=; h=In-Reply-To:References:Subject:From:Date:To:From; b=YIY2k/kfLeC29qnjaQs8IITr/GlCu1Lc9g/T4ayGMkhNeaQUbXQjzVCWDzAogwYGj Q3mEuCKtnSSjlvKpnWD608Acw4d91Ua7QLOgqZTiJfeK9Doq0Yvmrxtk9vnabbF5uq GkXNsMkyYmPQgUvDHiPg+mqpQUMLtrYEOkxxyZ7c= Received: from [IPV6:2600:100a:b002:cf92:c6a6:e5e2:391d:b90f] (unknown [IPv6:2600:100a:b002:cf92:c6a6:e5e2:391d:b90f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 53B4DD0405E; Thu, 7 Feb 2013 07:26:29 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: References: <1878869.epuRBHeDfC@scott-latitude-e6320> <1560860.2sJEDpXUvL@scott-latitude-e6320> <1937618.TQ5hFNaY6t@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 07 Feb 2013 07:26:23 -0600 To: "spfbis@ietf.org" Message-ID: <4485b963-5b95-4c78-afc5-6f13ec766a35@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 07 Feb 2013 13:26:32 -0000 There are non-human consumers of Received-SPF. None that I'm aware of care about mechanism. Scott K "Murray S. Kucherawy" wrote: >It's true that changing this doesn't affect interoperability of policy >evaluation, but it does affect anything that parses this field one way >if >we change it to the other. Consumers of this field are mostly what I'm >concerned with here. > >However, if nobody's heard of something other than humans that eats >Received-SPF fields, or if those that do exist already agree on how >it's >done, then I guess we just come to consensus on which of the two >syntaxes >we want and run with it. > >-MSK > > >On Tue, Feb 5, 2013 at 10:40 PM, Scott Kitterman >wrote: > >> I think we can pick what we want. Mechanism is there for forensics, >not >> for >> filtering, so changing it won't affect interoperability. Personally, >I >> think >> mx=example.com is a lot more useful than mechanism=mx since there may >be >> more >> than one of a mechanism type in a record, but I'm open to either >approach. >> I >> do think we should make it clear and then give an example. >> >> Scott K >> >> On Tuesday, February 05, 2013 10:35:03 PM Murray S. Kucherawy wrote: >> > That makes it an open topic. Ugly. >> > >> > Do we have any indication of a consensus of what various >implementations >> > do? Do we need to undertake such a survey? >> > >> > -MSK >> > >> > On Tue, Feb 5, 2013 at 10:26 PM, Scott Kitterman > >> wrote: >> > > I fear not. I looked in the internal pyspf tests and it has >things >> like >> > > mechanism=mx/24, so at best it's not clear. Mail::SPF seems to >only >> put >> > > the >> > > mechanisms in comments and not use this bit of the ABNF. >> > > >> > > Unknown is the old name for temperror, so it used to be a valid >result. >> > > Perhaps a copy/paste from an old example. >> > > >> > > Scott K >> > > >> > > On Tuesday, February 05, 2013 09:57:09 PM Murray S. Kucherawy >wrote: >> > > > I think the ABNF is correct as-is, but there is no example that >> > > >> > > illustrates >> > > >> > > > the use of mechanisms within a Received-SPF, which would clear >up the >> > > > confusion. >> > > > >> > > > The current ABNF is mean to enable things like: >> > > > >> > > > Received-SPF: pass mx=something; a=something; ... >> > > > >> > > > So "mechanism" doesn't need to be quoted, because it expands >into >> all of >> > > > the available mechanism names. What Barry was doing is >assuming one >> > > >> > > wants >> > > >> > > > to produce: >> > > > >> > > > Received-SPF: pass mechanism=mx; ... >> > > > >> > > > ...which was not the intention. >> > > > >> > > > Does that sound right, Barry? Scott? >> > > > >> > > > There is an error in the example upthread though, because it's >> > > > impossible >> > > > to generate "Received-SPF: unknown ..." as "unknown" isn't a >valid >> > > > result >> > > > string. >> > > > >> > > > -MSK >> > > > >> > > > On Tue, Feb 5, 2013 at 2:50 PM, Scott Kitterman > >> > > >> > > wrote: >> > > > > Need some help with this one: >> > > > > >> > > > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/53 >> > > > > >> > > > > Message posted by Barry Leiba on 4 Sept 2012: >> > > > > that was intended to support unknown mechanisms. So, if >you >> had an >> > > >> > > SPF >> > > >> > > > > record from draft-mengwong-spf-00: >> > > > > v=spf1 a mx ptr domainkeys:_dk.%{d} -all >> > > > > >> > > > > The Received-SPF header would look like: >> > > > > Received-SPF: unknown domainkeys=_dk.example.com >> > > > > >> > > > > If that's the case, the text needs work to make it clear, >because >> it's >> > > > > decidedly not. The text below the grammar lists key names and >the >> > > >> > > meanings >> > > >> > > > > of >> > > > > the values. "mechanism" is listed as a key name in that text. >So >> > > >> > > there's a >> > > >> > > > > problem somewhere that needs to be cleared up. >> > > > > >> > > > > >http://www.ietf.org/mail-archive/web/spfbis/current/msg02608.html >> > > > > >> > > > > Downthread from the referenced message, there's a proposed >> > > >> > > simplification >> > > >> > > > > from >> > > > > Arthur Thisell, but I think it's based on the (I believe >incorrect) >> > > > > assumption >> > > > > that mechanism isn't used. >> > > > > >> > > > > Suggestions please. >> > > > > >> > > > > Scott K >> > > > > _______________________________________________ >> > > > > spfbis mailing list >> > > > > spfbis@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/spfbis >> > > >> > > _______________________________________________ >> > > spfbis mailing list >> > > spfbis@ietf.org >> > > https://www.ietf.org/mailman/listinfo/spfbis >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> > > >------------------------------------------------------------------------ > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From barryleiba.mailing.lists@gmail.com Thu Feb 7 15:48:24 2013 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 A937421F89BA for ; Thu, 7 Feb 2013 15:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ReAjziY3Ndb for ; Thu, 7 Feb 2013 15:48:24 -0800 (PST) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id D643D21F89B3 for ; Thu, 7 Feb 2013 15:48:23 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id fy27so1962658vcb.7 for ; Thu, 07 Feb 2013 15:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zDTg+VVbrZRBIsGoDvlfi0m2tFaghkpT6+Si0HdPmMk=; b=JD7/ANnWufxaRbuxbB8XI/38rAuFx7153zv5hsbues7i6J1ISxV1/hPAw0qx4sAjHp 9OXUj0YSWNxSv0/qFIrk4OFszjcNKK28Z7UVKhKGG1tM37Bnggv2y1p9d0qCTSbHN4L1 uTvkHqfw2hMN4hzLpj4PWXGFH0NckdJ700XhONi0qdQJQ9G/Fo01Gzg8WTP6d0mWr0Vv CkaNURk4tt9Yfk4LkE9DVpJIosTiT2djCED26zps48TtUDPmWWlMEo9zZTD/l6BnCSqe wm2gQO6NJkiqLb3vkir9ah9S1FTSNM6jVMKBUTddrmfxWkhCfm9F4mc9qL2rca3QYBxV 0Maw== MIME-Version: 1.0 X-Received: by 10.220.157.18 with SMTP id z18mr4080870vcw.72.1360280903147; Thu, 07 Feb 2013 15:48:23 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Thu, 7 Feb 2013 15:48:22 -0800 (PST) In-Reply-To: <1582575.VsSs9YShWJ@scott-latitude-e6320> References: <1582575.VsSs9YShWJ@scott-latitude-e6320> Date: Thu, 7 Feb 2013 18:48:22 -0500 X-Google-Sender-Auth: UbYpfZF4xcDAhBCzSoJiZ-nNQG4 Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 07 Feb 2013 23:48:24 -0000 >> most of the lower case words have been changed to synonyms, a few have been >> changed into RFC 2119 keywords. I >> think most (but sadly, not all) of these capitalizations are wrong." >> >> Could this be made more specific? Which ones are wrong? > > Unfortunately Arthur hasn't been very active lately, so I was hoping someone > experienced with RFC lawyering could have a look and see if there were any > they felt were wrong. I've already gone back and fixed several that I > concluded in retrospect were wrong. There aren't many wrong ones, I think. Here's what I found in a brief pass through: -- Section 4.5 -- Starting with the set of records that were returned by the lookup, discard records that do not begin with a version section of exactly "v=spf1". Note that the version section is terminated either by an SP character or the end of the record. A record with a version section of "v=spf10" does not match and MUST be discarded. This "MUST" seems out of place, because there's no "MUST" in the first sentence. I think you should make it "and is discarded." -- Section 4.6 -- I don't see what the second paragraph adds to the first, and suggest eliminating it. -- Section 4.6.4 -- In the second paragraph, why are you mixing "MX resource records" in the first sentence with "A resource records" in the second sentence? Is this a typo, or intentional? If it's intentional, I would re-word it, which will probably correct the odd "MUST". -- Section 5 -- When any mechanism fetches host addresses to compare with , when is an IPv4 address, A records are fetched; when is an IPv6 address, AAAA records are fetched. Even if the SMTP connection uses IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) MUST still be considered an IPv4 address and MUST be evaluated using IPv4 mechanisms (i.e. "ip4" and "a"). Again, the lack of "MUST" in the first sentence makes the use of it in the second sentence odd. I'd make the "MUST ... be" constructions into "is". -- Section 10 -- The "SHOULD" in the first paragraph is wrong. If what you want to say is that the section isn't normative, then say it that way, as "and it is not a comprehensive list of normative requirements." Otherwise, just make it "should". Barry (participatorially) From hsantos@isdg.net Thu Feb 7 18:50:32 2013 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 AC24C21E8043 for ; Thu, 7 Feb 2013 18:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.215 X-Spam-Level: X-Spam-Status: No, score=-102.215 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEF0XU0p6Y4D for ; Thu, 7 Feb 2013 18:50:30 -0800 (PST) Received: from dkim.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1AF21E8034 for ; Thu, 7 Feb 2013 18:50:29 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4506; t=1360291824; h=Received:Received: Message-ID:From:To:Subject:Date:Organization:List-ID; bh=oa6kTJ2 Rds09vGA9d9P4OYEarY8=; b=oMZ+O85UHG8M8tOSpLLtNqtPI1f2RLFxGPY1tUw L9tr/HFTM4s17NW9aN/2FpZnW2LdMDo0haIGJy/qpVwvNBA+ukQXTZRtub2rzGwo +UC0cC9zspOHWhgFdX06G+D/qCgpqGkpmsNdN02ya1Tb/5Fl6KTPCyRkPE2gqfVY yz+0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 07 Feb 2013 21:50:24 -0500 Received: from main2 ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3428554310.26108.5468; Thu, 07 Feb 2013 21:50:24 -0500 Message-ID: <2AEC99CC845341BFB91A06E27B192F9D@addom.santronics.com> From: "Hector Santos" To: "Scott Kitterman" , References: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> <1377522.ULX4pbEB9u@scott-latitude-e6320> Date: Thu, 7 Feb 2013 21:48:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Subject: [spfbis] Section 2.3 - Genesis of 30 days delays? 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, 08 Feb 2013 02:50:32 -0000 Section 2.3, to the last paragraph, it added the 30 days sentence: When changing SPF records, care has to be taken to ensure that there is a transition period so that the old policy remains valid until all legitimate email can reasonably expect to have been checked. This can be as much as 30 days. Where does this 30 days come from? RFC4408 does not have this. Does this include MUA user delays (i.e. returning from vacation)? I ask because I find it unreasonable that anyone will wait 30 days to = deliver mail, thats a long time, and if so, how would one go about = designing or adding additional delivery strategies to minimize potential = policy conflicts with different receivers? Is there a 30 day caching of the last SPF record before comparing and = applying any new record available? IOW, for example, a lookup is done, = a lexical compare is done against the cached record if any. If = different, then we need to keep both around but only apply the old one = for 30 days? Anyway, I see no justification for this 30 day that seems to include MUA = delay considerations where it may be doing SPF verifications. Seems to = bit much to expect, MUAs expected to cache dual records [1], etc. The higher the days, the more it seems it would be a problem since the = range of days covers a longer time period regarding factoring delivery = strategies that will minimize potential policy conflicts with different = receivers. A lot can happen within 30 days, like sending tons of email, = multiple changes in fine tunning SPF reocrds, etc.=20 I would think just talking/reference about SMTP suggested guidelines of = 4-5 days for delivery retry delays is appropriate or take out the = sentence (keep like RFC4408 here). -- HLS 1] SMTP has a recommended 4-5 days retry suggestion. I believe SPF is = about SMTP to SMTP transports so the SPF-Receiver host will do the = checking and that will be within 4-5 days of getting the mail. At best, = with marking operations enabled, the Received-SPF (or Auth-Res now) = header will be added for the MUA to potentially see. This is deployment = assumption that the the receiver has a Process-But-Do-Nothing local = policy concept, i.e. its only MARKING SPF result, its taking no action = at the backend and puts all the mail in the user's pickup bin for POP3. = This means the MUA will need to have a SMTP Received Time Stamp trace = line (already there) but also recording of the old SPF record stored in = the RFC5322 header. Otherwise we expect the MUA to do this double = recording! This is a time-shifted problem, that was also available with = DKIM when the deployment was not yet done at receivers. A proposed = solution was offered for DKIM.=20 Partial DKIM Verifier Support using a DKIM-Received Trace = Headerhttp://tools.ietf.org/html/draft-santos-dkim-rcvd-00 A similar one would be needed for SPF with such a long delay expected = with MUA doing the verification - not the user's ISP (backend) SMTP = receiver. ----- Original Message -----=20 From: "Scott Kitterman" To: Sent: Thursday, February 07, 2013 3:18 AM Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-10.txt > On Thursday, February 07, 2013 12:11:51 AM internet-drafts@ietf.org = wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the SPF Update Working = Group of >> the IETF. >>=20 >> Title : Sender Policy Framework (SPF) for = Authorizing Use >> of Domains in Email, Version 1 Author(s) : Scott Kitterman >> Filename : draft-ietf-spfbis-4408bis-10.txt >> Pages : 73 >> Date : 2013-02-07 >=20 > I believe this update addresses these open issues in the tracker: >=20 > #36 RFC 2119 key words > #38 Deprecated > #43 New requirement for mx: or ptr records > #45 Section 5.5 steps > #46 DNS reply in Section 5.7 > #48 Section 8.1 - macro defs > #52 Section 8.1 *Macro Definitions > #33 Marked Failed Mail Exposure >=20 > http://trac.tools.ietf.org/wg/spfbis/trac/report/1 >=20 > Please review. I'll give people a bit of time to digest the revised = draft and=20 > raise concerns if they have them before I mark the issues as fixed. = Thanks to=20 > those who helped with the updates. >=20 > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From spf2@kitterman.com Thu Feb 7 20:06:59 2013 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 B8C9F21E8034 for ; Thu, 7 Feb 2013 20:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhlGkxMFoPA1 for ; Thu, 7 Feb 2013 20:06:59 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C8E771F0D05 for ; Thu, 7 Feb 2013 20:06:58 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4791720E4113; Thu, 7 Feb 2013 23:06:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360296417; bh=PX4EacGm9ydUUmhQmng1HDGQaFQ4KHLM7P4a6rrBgno=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aiEgHt5A5fQ3bHXY8YP3zIw6uNC3PNXDSjOjQ2gPGAEHtnpDmqtRa9dpjfDIDO2Y2 zSfeYWOMt0UeXtPUBnWUfHZ7c93LAgq+ubpAcJsiTaK7Aym51TyYXvTyTbyQCcQ5ge tU7JZwGqpIuNQKKtW5ziNnUSGxFEELO8gcpRmOmU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 29E2420E40FC; Thu, 7 Feb 2013 23:06:56 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 07 Feb 2013 23:06:53 -0500 Message-ID: <1614517.uns7AmPsly@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <2AEC99CC845341BFB91A06E27B192F9D@addom.santronics.com> References: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> <1377522.ULX4pbEB9u@scott-latitude-e6320> <2AEC99CC845341BFB91A06E27B192F9D@addom.santronics.com> 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 2.3 - Genesis of 30 days delays? 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, 08 Feb 2013 04:06:59 -0000 On Thursday, February 07, 2013 09:48:53 PM Hector Santos wrote: > Section 2.3, to the last paragraph, it added the 30 days sentence: > > When changing SPF records, care has to be taken to ensure that there > is a transition period so that the old policy remains valid until all > legitimate email can reasonably expect to have been checked. This > can be as much as 30 days. > > Where does this 30 days come from? RFC4408 does not have this. > > Does this include MUA user delays (i.e. returning from vacation)? > > I ask because I find it unreasonable that anyone will wait 30 days to > deliver mail, thats a long time, and if so, how would one go about > designing or adding additional delivery strategies to minimize potential > policy conflicts with different receivers? > > Is there a 30 day caching of the last SPF record before comparing and > applying any new record available? IOW, for example, a lookup is done, a > lexical compare is done against the cached record if any. If different, > then we need to keep both around but only apply the old one for 30 days? > > Anyway, I see no justification for this 30 day that seems to include MUA > delay considerations where it may be doing SPF verifications. Seems to bit > much to expect, MUAs expected to cache dual records [1], etc. > > The higher the days, the more it seems it would be a problem since the range > of days covers a longer time period regarding factoring delivery strategies > that will minimize potential policy conflicts with different receivers. A > lot can happen within 30 days, like sending tons of email, multiple changes > in fine tunning SPF reocrds, etc. > > I would think just talking/reference about SMTP suggested guidelines of 4-5 > days for delivery retry delays is appropriate or take out the sentence > (keep like RFC4408 here). > > -- > HLS > > 1] SMTP has a recommended 4-5 days retry suggestion. I believe SPF is about > SMTP to SMTP transports so the SPF-Receiver host will do the checking and > that will be within 4-5 days of getting the mail. At best, with marking > operations enabled, the Received-SPF (or Auth-Res now) header will be added > for the MUA to potentially see. This is deployment assumption that the the > receiver has a Process-But-Do-Nothing local policy concept, i.e. its only > MARKING SPF result, its taking no action at the backend and puts all the > mail in the user's pickup bin for POP3. This means the MUA will need to > have a SMTP Received Time Stamp trace line (already there) but also > recording of the old SPF record stored in the RFC5322 header. Otherwise we > expect the MUA to do this double recording! This is a time-shifted > problem, that was also available with DKIM when the deployment was not yet > done at receivers. A proposed solution was offered for DKIM. > > Partial DKIM Verifier Support using a DKIM-Received Trace > Headerhttp://tools.ietf.org/html/draft-santos-dkim-rcvd-00 A similar one > would be needed for SPF with such a long delay expected with MUA doing the > verification - not the user's ISP (backend) SMTP receiver. RFC 4408 says: > When changing SPF records, care must be taken to ensure that there is > a transition period so that the old policy remains valid until all > legitimate E-Mail has been checked. There was feedback suggesting this was too generic and we ought to make it more specific/actionable. 30 days was pulled from the original Microsoft Caller-ID for Email specification. I couldn't find any other recommendation. Whether you like it or not, people do do post-SMTP SPF validation, including in MUAs. A recommendation that just caters to fully connected SMTP operations will be too narrow. I'm not wedded to 30 days and am open to suggestions, but I do think it's better to make a more specific recommendation than RFC 4408 did and I don't think 4-5 days is long enough. Scott K From superuser@gmail.com Thu Feb 7 20:35:59 2013 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 1423C1F0D08 for ; Thu, 7 Feb 2013 20:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dKM+ApNwqDJ for ; Thu, 7 Feb 2013 20:35:58 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id AE2E41F0D05 for ; Thu, 7 Feb 2013 20:35:57 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so2573501wgd.4 for ; Thu, 07 Feb 2013 20:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QrZjCUwZLbxsrGtBZGTahIcNh0OmUEVCTsIqf2GkJ5E=; b=r2UN1QxmOrpnyjU3GLl/6VlGKsZEq/7kPpbH6pdZepd10u/QD/tNL57EXUjwtNc82S j/3Ww/uq8pygnfJNrvXkseXoiHrJwa8QHNEax5O5K3I3sLTf9kBjmDW0P3wpYGUIMqN1 N7JdvPBOsnUDbgCPQOOrKioI+eRrY8grOXgel4q2wVP6Q8YX3bJihWBqb/APfu3uIEWV CA5Dy1PxOhLhvd5Fnr54IYRSdVu+AI1ybA5MWawkdU7jLxXCICCsj9OL5c8Cg2Uf1vVT Vz2LK4yj26DO/HPeZiw97I2s0q+t2zXHwYiWb/IMoJKUXPUq3gQY4y5lQBJ8OPRkO+4K ulHg== MIME-Version: 1.0 X-Received: by 10.195.13.11 with SMTP id eu11mr7054063wjd.39.1360298156710; Thu, 07 Feb 2013 20:35:56 -0800 (PST) Received: by 10.180.164.43 with HTTP; Thu, 7 Feb 2013 20:35:56 -0800 (PST) In-Reply-To: <1614517.uns7AmPsly@scott-latitude-e6320> References: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> <1377522.ULX4pbEB9u@scott-latitude-e6320> <2AEC99CC845341BFB91A06E27B192F9D@addom.santronics.com> <1614517.uns7AmPsly@scott-latitude-e6320> Date: Thu, 7 Feb 2013 20:35:56 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bd91a846b5b8d04d52f18ba Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? 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, 08 Feb 2013 04:35:59 -0000 --047d7bd91a846b5b8d04d52f18ba Content-Type: text/plain; charset=ISO-8859-1 If you were to characterize the 30 days as a "consensus estimate" or some such regarding a reasonable maximum time one might expect mail to take to be either delivered or returned as undeliverable, it would appear less arbitrary. That assumes, of course, that such is the consensus. I for one would be fine with saying so; my own experience is that the average is substantially shorter, but I have configured systems (in the distant past, admittedly) that had a 28-day timeout. -MSK On Thu, Feb 7, 2013 at 8:06 PM, Scott Kitterman wrote: > On Thursday, February 07, 2013 09:48:53 PM Hector Santos wrote: > > Section 2.3, to the last paragraph, it added the 30 days sentence: > > > > When changing SPF records, care has to be taken to ensure that there > > is a transition period so that the old policy remains valid until all > > legitimate email can reasonably expect to have been checked. This > > can be as much as 30 days. > > > > Where does this 30 days come from? RFC4408 does not have this. > > > > Does this include MUA user delays (i.e. returning from vacation)? > > > > I ask because I find it unreasonable that anyone will wait 30 days to > > deliver mail, thats a long time, and if so, how would one go about > > designing or adding additional delivery strategies to minimize potential > > policy conflicts with different receivers? > > > > Is there a 30 day caching of the last SPF record before comparing and > > applying any new record available? IOW, for example, a lookup is done, a > > lexical compare is done against the cached record if any. If different, > > then we need to keep both around but only apply the old one for 30 days? > > > > Anyway, I see no justification for this 30 day that seems to include MUA > > delay considerations where it may be doing SPF verifications. Seems to > bit > > much to expect, MUAs expected to cache dual records [1], etc. > > > > The higher the days, the more it seems it would be a problem since the > range > > of days covers a longer time period regarding factoring delivery > strategies > > that will minimize potential policy conflicts with different receivers. > A > > lot can happen within 30 days, like sending tons of email, multiple > changes > > in fine tunning SPF reocrds, etc. > > > > I would think just talking/reference about SMTP suggested guidelines of > 4-5 > > days for delivery retry delays is appropriate or take out the sentence > > (keep like RFC4408 here). > > > > -- > > HLS > > > > 1] SMTP has a recommended 4-5 days retry suggestion. I believe SPF is > about > > SMTP to SMTP transports so the SPF-Receiver host will do the checking and > > that will be within 4-5 days of getting the mail. At best, with marking > > operations enabled, the Received-SPF (or Auth-Res now) header will be > added > > for the MUA to potentially see. This is deployment assumption that the > the > > receiver has a Process-But-Do-Nothing local policy concept, i.e. its only > > MARKING SPF result, its taking no action at the backend and puts all the > > mail in the user's pickup bin for POP3. This means the MUA will need to > > have a SMTP Received Time Stamp trace line (already there) but also > > recording of the old SPF record stored in the RFC5322 header. Otherwise > we > > expect the MUA to do this double recording! This is a time-shifted > > problem, that was also available with DKIM when the deployment was not > yet > > done at receivers. A proposed solution was offered for DKIM. > > > > Partial DKIM Verifier Support using a DKIM-Received Trace > > Headerhttp://tools.ietf.org/html/draft-santos-dkim-rcvd-00 A similar one > > would be needed for SPF with such a long delay expected with MUA doing > the > > verification - not the user's ISP (backend) SMTP receiver. > > RFC 4408 says: > > > When changing SPF records, care must be taken to ensure that there is > > a transition period so that the old policy remains valid until all > > legitimate E-Mail has been checked. > > There was feedback suggesting this was too generic and we ought to make it > more specific/actionable. 30 days was pulled from the original Microsoft > Caller-ID for Email specification. I couldn't find any other > recommendation. > > Whether you like it or not, people do do post-SMTP SPF validation, > including > in MUAs. A recommendation that just caters to fully connected SMTP > operations > will be too narrow. > > I'm not wedded to 30 days and am open to suggestions, but I do think it's > better to make a more specific recommendation than RFC 4408 did and I don't > think 4-5 days is long enough. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --047d7bd91a846b5b8d04d52f18ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If you were to characterize the 30 days as a &qu= ot;consensus estimate" or some such regarding a reasonable maximum tim= e one might expect mail to take to be either delivered or returned as undel= iverable, it would appear less arbitrary.

That assumes, of course, that such is the consensus.=A0 I for one= would be fine with saying so; my own experience is that the average is sub= stantially shorter, but I have configured systems (in the distant past, adm= ittedly) that had a 28-day timeout.

-MSK


On Thu, Feb 7, 2013 at 8:06 PM, Scott Kitterman <spf2@kitterma= n.com> wrote:
On T= hursday, February 07, 2013 09:48:53 PM Hector Santos wrote:
> Section 2.3, to the last paragraph, it added the 30 days sentence:
>
> =A0 =A0When changing SPF records, care has to be taken to ensure that = there
> =A0 =A0is a transition period so that the old policy remains valid unt= il all
> =A0 =A0legitimate email can reasonably expect to have been checked. = =A0This
> =A0 =A0can be as much as 30 days.
>
> Where does this 30 days come from? RFC4408 does not have this.
>
> Does this include MUA user delays (i.e. returning from vacation)?
>
> I ask because I find it unreasonable that anyone will wait 30 days to<= br> > deliver mail, thats a long time, and if so, how would one go about
> designing or adding additional delivery strategies to minimize potenti= al
> policy conflicts with different receivers?
>
> Is there a 30 day caching of the last SPF record before comparing and<= br> > applying any new record available? =A0IOW, for example, a lookup is do= ne, a
> lexical compare is done against the cached record if any. If different= ,
> then we need to keep both around but only apply the old one for 30 day= s?
>
> Anyway, I see no justification for this 30 day that seems to include M= UA
> delay considerations where it may be doing SPF verifications. =A0Seems= to bit
> much to expect, MUAs expected to cache dual records [1], etc.
>
> The higher the days, the more it seems it would be a problem since the= range
> of days covers a longer time period regarding factoring delivery strat= egies
> that will minimize potential policy conflicts with different receivers= . =A0A
> lot can happen within 30 days, like sending tons of email, multiple ch= anges
> in fine tunning SPF reocrds, etc.
>
> I would think just talking/reference about SMTP suggested guidelines o= f 4-5
> days for delivery retry delays is appropriate or take out the sentence=
> (keep like RFC4408 here).
>
> --
> HLS
>
> 1] SMTP has a recommended 4-5 days retry suggestion. I believe SPF is = about
> SMTP to SMTP transports so the SPF-Receiver host will do the checking = and
> that will be within 4-5 days of getting the mail. At best, with markin= g
> operations enabled, the Received-SPF (or Auth-Res now) header will be = added
> for the MUA to potentially see. This is deployment assumption that the= the
> receiver has a Process-But-Do-Nothing local policy concept, i.e. its o= nly
> MARKING SPF result, its taking no action at the backend and puts all t= he
> mail in the user's pickup bin =A0for POP3. =A0This means the MUA w= ill need to
> have a SMTP Received Time Stamp trace line (already there) but also > recording of the old SPF record stored in the RFC5322 header. Otherwis= e we
> expect the MUA to do this double recording! =A0This is a time-shifted<= br> > problem, that was also available with DKIM when the deployment was not= yet
> done at receivers. A proposed solution was offered for DKIM.
>
> Partial DKIM Verifier Support using a DKIM-Received Trace
> Headerhttp://tools.ietf.org/html/draft-santos-dkim-rcvd-00= A similar one
> would be needed for SPF with such a long delay expected with MUA doing= the
> verification - not the user's ISP (backend) SMTP receiver.

RFC 4408 says:

> =A0 =A0When changing SPF records, care must be taken to ensure that th= ere is
> =A0 =A0a transition period so that the old policy re= mains valid until all
> =A0 =A0legitimate E-Mail has been checked.

There was feedback suggesting this was too generic and we ought to make it<= br> more specific/actionable. =A030 days was pulled from the original Microsoft=
Caller-ID for Email specification. =A0I couldn't find any other recomme= ndation.

Whether you like it or not, people do do post-SMTP SPF validation, includin= g
in MUAs. =A0A recommendation that just caters to fully connected SMTP opera= tions
will be too narrow.

I'm not wedded to 30 days and am open to suggestions, but I do think it= 's
better to make a more specific recommendation than RFC 4408 did and I don&#= 39;t
think 4-5 days is long enough.

Scott K
_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--047d7bd91a846b5b8d04d52f18ba-- From superuser@gmail.com Thu Feb 7 20:42:28 2013 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 30AB61F0D05 for ; Thu, 7 Feb 2013 20:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1p-IzYanYAwV for ; Thu, 7 Feb 2013 20:42:27 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8CB321F854F for ; Thu, 7 Feb 2013 20:42:26 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so366874wid.17 for ; Thu, 07 Feb 2013 20:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=C5DTDXhcwEIkPywyinqMs/a5nskSLql6kJ3tkwI8oAc=; b=WFJT9q3vIJs2a8Vuo7a7E5AhxlyRtAWsVSmHkmpYXoo2Inx/ecE+lk7fR2AY08J9sN 0oSJK0IO03Iy1qVC3waDPyFHy68rvIzuIvQFgmoyir+5U4k+CbEjjI8kqHhfC1Hrin7s cKDXXSM7z7bkEi1E9LsYxwal+JH0PMygldBqHrT0xlYcCDiDgFd4+O5WD0wXjDG5o8ML 1Ykr6DxkFgkEIEQ4XUO3OV66dN9ChC+KUUGk3THp5MSHLC/yRXHaHlBPTqR+t+S1b43P M/OuAv5a5Vx4BL27w6ycfItzWGCoqC33HeS9OIa4YMUzeAprwrQf9uGI9k2Zth92w+Su u8NA== MIME-Version: 1.0 X-Received: by 10.194.174.196 with SMTP id bu4mr7034598wjc.35.1360298545878; Thu, 07 Feb 2013 20:42:25 -0800 (PST) Received: by 10.180.164.43 with HTTP; Thu, 7 Feb 2013 20:42:25 -0800 (PST) In-Reply-To: References: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> <1377522.ULX4pbEB9u@scott-latitude-e6320> <2AEC99CC845341BFB91A06E27B192F9D@addom.santronics.com> <1614517.uns7AmPsly@scott-latitude-e6320> Date: Thu, 7 Feb 2013 20:42:25 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e0149331a9d954004d52f2f33 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? 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, 08 Feb 2013 04:42:28 -0000 --089e0149331a9d954004d52f2f33 Content-Type: text/plain; charset=ISO-8859-1 I should add that I don't support the notion of recording in the header the SPF record or DKIM key data that were discovered by the receiving MTA. That stuff is supposed to be evaluate at receipt time, not later by the MUA when it gets around to doing so. There was a lengthy appendix added to RFC5451 that talked about all the reasons you don't want to do it that way. The point of the "30 days" statement is to remind operators that mail can be delayed in transit. Suppose, for example, you have an SPF record that authorizes some third party to send mail on your behalf, but that contract is ending so you plan to remove the authorization. If at time T0 that third party sends something you want to get out, then at T1 you revoke that authorization, and then at T2 the actual delivery attempt occurs, the mail will get rejected. The point this is trying to make is that the time between T0 and T2 could be longer than the operator might realize. -MSK On Thu, Feb 7, 2013 at 8:35 PM, Murray S. Kucherawy wrote: > If you were to characterize the 30 days as a "consensus estimate" or some > such regarding a reasonable maximum time one might expect mail to take to > be either delivered or returned as undeliverable, it would appear less > arbitrary. > > That assumes, of course, that such is the consensus. I for one would be > fine with saying so; my own experience is that the average is substantially > shorter, but I have configured systems (in the distant past, admittedly) > that had a 28-day timeout. > > -MSK > > > On Thu, Feb 7, 2013 at 8:06 PM, Scott Kitterman wrote: > >> On Thursday, February 07, 2013 09:48:53 PM Hector Santos wrote: >> > Section 2.3, to the last paragraph, it added the 30 days sentence: >> > >> > When changing SPF records, care has to be taken to ensure that there >> > is a transition period so that the old policy remains valid until all >> > legitimate email can reasonably expect to have been checked. This >> > can be as much as 30 days. >> > >> > Where does this 30 days come from? RFC4408 does not have this. >> > >> > Does this include MUA user delays (i.e. returning from vacation)? >> > >> > I ask because I find it unreasonable that anyone will wait 30 days to >> > deliver mail, thats a long time, and if so, how would one go about >> > designing or adding additional delivery strategies to minimize potential >> > policy conflicts with different receivers? >> > >> > Is there a 30 day caching of the last SPF record before comparing and >> > applying any new record available? IOW, for example, a lookup is done, >> a >> > lexical compare is done against the cached record if any. If different, >> > then we need to keep both around but only apply the old one for 30 days? >> > >> > Anyway, I see no justification for this 30 day that seems to include MUA >> > delay considerations where it may be doing SPF verifications. Seems to >> bit >> > much to expect, MUAs expected to cache dual records [1], etc. >> > >> > The higher the days, the more it seems it would be a problem since the >> range >> > of days covers a longer time period regarding factoring delivery >> strategies >> > that will minimize potential policy conflicts with different receivers. >> A >> > lot can happen within 30 days, like sending tons of email, multiple >> changes >> > in fine tunning SPF reocrds, etc. >> > >> > I would think just talking/reference about SMTP suggested guidelines of >> 4-5 >> > days for delivery retry delays is appropriate or take out the sentence >> > (keep like RFC4408 here). >> > >> > -- >> > HLS >> > >> > 1] SMTP has a recommended 4-5 days retry suggestion. I believe SPF is >> about >> > SMTP to SMTP transports so the SPF-Receiver host will do the checking >> and >> > that will be within 4-5 days of getting the mail. At best, with marking >> > operations enabled, the Received-SPF (or Auth-Res now) header will be >> added >> > for the MUA to potentially see. This is deployment assumption that the >> the >> > receiver has a Process-But-Do-Nothing local policy concept, i.e. its >> only >> > MARKING SPF result, its taking no action at the backend and puts all the >> > mail in the user's pickup bin for POP3. This means the MUA will need >> to >> > have a SMTP Received Time Stamp trace line (already there) but also >> > recording of the old SPF record stored in the RFC5322 header. Otherwise >> we >> > expect the MUA to do this double recording! This is a time-shifted >> > problem, that was also available with DKIM when the deployment was not >> yet >> > done at receivers. A proposed solution was offered for DKIM. >> > >> > Partial DKIM Verifier Support using a DKIM-Received Trace >> > Headerhttp://tools.ietf.org/html/draft-santos-dkim-rcvd-00 A similar >> one >> > would be needed for SPF with such a long delay expected with MUA doing >> the >> > verification - not the user's ISP (backend) SMTP receiver. >> >> RFC 4408 says: >> >> > When changing SPF records, care must be taken to ensure that there is >> > a transition period so that the old policy remains valid until all >> > legitimate E-Mail has been checked. >> >> There was feedback suggesting this was too generic and we ought to make it >> more specific/actionable. 30 days was pulled from the original Microsoft >> Caller-ID for Email specification. I couldn't find any other >> recommendation. >> >> Whether you like it or not, people do do post-SMTP SPF validation, >> including >> in MUAs. A recommendation that just caters to fully connected SMTP >> operations >> will be too narrow. >> >> I'm not wedded to 30 days and am open to suggestions, but I do think it's >> better to make a more specific recommendation than RFC 4408 did and I >> don't >> think 4-5 days is long enough. >> >> Scott K >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> > > --089e0149331a9d954004d52f2f33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I should add that I don't support the notion of r= ecording in the header the SPF record or DKIM key data that were discovered= by the receiving MTA.=A0 That stuff is supposed to be evaluate at receipt = time, not later by the MUA when it gets around to doing so.=A0 There was a = lengthy appendix added to RFC5451 that talked about all the reasons you don= 't want to do it that way.

The point of the "30 days" statement is to remind = operators that mail can be delayed in transit.=A0=A0 Suppose, for example, = you have an SPF record that authorizes some third party to send mail on you= r behalf, but that contract is ending so you plan to remove the authorizati= on.=A0 If at time T0 that third party sends something you want to get out, = then at T1 you revoke that authorization, and then at T2 the actual deliver= y attempt occurs, the mail will get rejected.=A0 The point this is trying t= o make is that the time between T0 and T2 could be longer than the operator= might realize.

-MSK


On Thu, Feb 7, 2013 at 8:35 PM, Murray S. Kucherawy <superuse= r@gmail.com> wrote:
If you were to ch= aracterize the 30 days as a "consensus estimate" or some such reg= arding a reasonable maximum time one might expect mail to take to be either= delivered or returned as undeliverable, it would appear less arbitrary.
That assumes, of course, that such is the consensus.=A0 I for one= would be fine with saying so; my own experience is that the average is sub= stantially shorter, but I have configured systems (in the distant past, adm= ittedly) that had a 28-day timeout.

-MSK=


On Thu, Feb 7, 2013 at = 8:06 PM, Scott Kitterman <spf2@kitterman.com> wrote:
On Thursday, February 07, 2013 09:= 48:53 PM Hector Santos wrote:
> Section 2.3, to the last paragraph, it added the 30 days sentence:
>
> =A0 =A0When changing SPF records, care has to be taken to ensure that = there
> =A0 =A0is a transition period so that the old policy remains valid unt= il all
> =A0 =A0legitimate email can reasonably expect to have been checked. = =A0This
> =A0 =A0can be as much as 30 days.
>
> Where does this 30 days come from? RFC4408 does not have this.
>
> Does this include MUA user delays (i.e. returning from vacation)?
>
> I ask because I find it unreasonable that anyone will wait 30 days to<= br> > deliver mail, thats a long time, and if so, how would one go about
> designing or adding additional delivery strategies to minimize potenti= al
> policy conflicts with different receivers?
>
> Is there a 30 day caching of the last SPF record before comparing and<= br> > applying any new record available? =A0IOW, for example, a lookup is do= ne, a
> lexical compare is done against the cached record if any. If different= ,
> then we need to keep both around but only apply the old one for 30 day= s?
>
> Anyway, I see no justification for this 30 day that seems to include M= UA
> delay considerations where it may be doing SPF verifications. =A0Seems= to bit
> much to expect, MUAs expected to cache dual records [1], etc.
>
> The higher the days, the more it seems it would be a problem since the= range
> of days covers a longer time period regarding factoring delivery strat= egies
> that will minimize potential policy conflicts with different receivers= . =A0A
> lot can happen within 30 days, like sending tons of email, multiple ch= anges
> in fine tunning SPF reocrds, etc.
>
> I would think just talking/reference about SMTP suggested guidelines o= f 4-5
> days for delivery retry delays is appropriate or take out the sentence=
> (keep like RFC4408 here).
>
> --
> HLS
>
> 1] SMTP has a recommended 4-5 days retry suggestion. I believe SPF is = about
> SMTP to SMTP transports so the SPF-Receiver host will do the checking = and
> that will be within 4-5 days of getting the mail. At best, with markin= g
> operations enabled, the Received-SPF (or Auth-Res now) header will be = added
> for the MUA to potentially see. This is deployment assumption that the= the
> receiver has a Process-But-Do-Nothing local policy concept, i.e. its o= nly
> MARKING SPF result, its taking no action at the backend and puts all t= he
> mail in the user's pickup bin =A0for POP3. =A0This means the MUA w= ill need to
> have a SMTP Received Time Stamp trace line (already there) but also > recording of the old SPF record stored in the RFC5322 header. Otherwis= e we
> expect the MUA to do this double recording! =A0This is a time-shifted<= br> > problem, that was also available with DKIM when the deployment was not= yet
> done at receivers. A proposed solution was offered for DKIM.
>
> Partial DKIM Verifier Support using a DKIM-Received Trace
> Headerhttp://tools.ietf.org/html/draft-santos-dkim-rcvd-00= A similar one
> would be needed for SPF with such a long delay expected with MUA doing= the
> verification - not the user's ISP (backend) SMTP receiver.

RFC 4408 says:

> =A0 =A0When changing SPF records, care must be taken to ensure that th= ere is
> =A0 =A0a transition period so that the old policy remains valid u= ntil all
> =A0 =A0legitimate E-Mail has been checked.

There was feedback suggesting this was too generic and we ought to make it<= br> more specific/actionable. =A030 days was pulled from the original Microsoft=
Caller-ID for Email specification. =A0I couldn't find any other recomme= ndation.

Whether you like it or not, people do do post-SMTP SPF validation, includin= g
in MUAs. =A0A recommendation that just caters to fully connected SMTP opera= tions
will be too narrow.

I'm not wedded to 30 days and am open to suggestions, but I do think it= 's
better to make a more specific recommendation than RFC 4408 did and I don&#= 39;t
think 4-5 days is long enough.

Scott K
_______________________________________________
spfbis mailing list
spfbis@ietf.org = https://www.ietf.org/mailman/listinfo/spfbis


--089e0149331a9d954004d52f2f33-- From sm@elandsys.com Thu Feb 7 21:22:44 2013 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 2B7761F0D08 for ; Thu, 7 Feb 2013 21:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC3u9HPUFWSo for ; Thu, 7 Feb 2013 21:22:42 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CA521F84F3 for ; Thu, 7 Feb 2013 21:22:40 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.128.116]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r185MF3k017365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Feb 2013 21:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360300954; bh=bwoKJp63rYFge0e0A/M8ISpzJ2Ctl3NbsUX/YqIyu6Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YOTGp3o/REBAa60le4ulaF6iUpMedhX4vEWrUk4djAd0uRorF4j9dXaqr1HGYpNgC 1Rrva7Y7p68ZwbpcEjdBPTPJm9gXT36vyVOeFrDg7OCFWq68rXs+ZR3b33SMKPI8Nq GvJ+WAv0mg4hkBUn2zzdjxzQl1T3qqsxEyqvxjjg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1360300954; i=@elandsys.com; bh=bwoKJp63rYFge0e0A/M8ISpzJ2Ctl3NbsUX/YqIyu6Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bIGd9WQ+zQ+weDN8QC3JH9WpDcLPiAOcreo1hF0MO0th7x7mgF5NzrXh8b+u+tTmb TzNSvk/RvNNVjcvWgwhBxRtb4A3V9IGSPOtscKsUN5/2O7nHdYy/7ebQTFa39SifmV qA5C/VJfJYx24It81uLmKPlk/nbHI6OT6eu8bLSk= Message-Id: <6.2.5.6.2.20130207211859.09b859a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 07 Feb 2013 21:22:02 -0800 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> <1377522.ULX4pbEB9u@scott-latitude-e6320> <2AEC99CC845341BFB91A06E27B192F9D@addom.santronics.com> <1614517.uns7AmPsly@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? 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, 08 Feb 2013 05:22:44 -0000 Hi Murray, At 20:35 07-02-2013, Murray S. Kucherawy wrote: >If you were to characterize the 30 days as a "consensus estimate" or >some such regarding a reasonable maximum time one might expect mail >to take to be either delivered or returned as undeliverable, it >would appear less arbitrary. See http://www.ietf.org/mail-archive/web/spfbis/current/msg02559.html and http://www.ietf.org/mail-archive/web/spfbis/current/msg01842.html for the "30 days" text. Regards, S. Moonesamy From superuser@gmail.com Thu Feb 7 21:56:02 2013 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 1F67D21F892C for ; Thu, 7 Feb 2013 21:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.376 X-Spam-Level: X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY1GMJHBmLwf for ; Thu, 7 Feb 2013 21:56:01 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4C91121F8921 for ; Thu, 7 Feb 2013 21:56:01 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id o1so406631wic.11 for ; Thu, 07 Feb 2013 21:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=68/RHe3LQQSjgNo55l/tjvKo0XFYzgHFxYd0Ep7FQ+I=; b=N/Rcy0ouu7+KtJZQm9eYEsZrU6h9IhRZ+l6Hf5uG5PaOep3ZVSVih9lUxw4OJXfzGe WpCPFxfFt7HszOL++bdeecdA2swHyq6kNMDisX1DnaRlpo3gEmZB0bFxHSLtLD7vlg12 Grz0wwnRrX4KpzD0rZTYg++qs7T3+9LP67fkxR9MU4KtoUnoBK/iQwb0BY620zNV7/ta KQTJ9r5RmJcD5QtA/akOdz/BKC3lfT2ZQj430KegDvbRrdSrO9iAdOJn/pLSsRwfmuu4 0p5U26g7AMrp30hQsc3AR/nEoMGUD1hP0b/bL+awZ+EBUboqrL5sSBENNhxIiSNGSSjU 6++A== MIME-Version: 1.0 X-Received: by 10.195.13.11 with SMTP id eu11mr7285519wjd.39.1360302960425; Thu, 07 Feb 2013 21:56:00 -0800 (PST) Received: by 10.180.164.43 with HTTP; Thu, 7 Feb 2013 21:55:59 -0800 (PST) In-Reply-To: <6.2.5.6.2.20130207211859.09b859a8@resistor.net> References: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> <1377522.ULX4pbEB9u@scott-latitude-e6320> <2AEC99CC845341BFB91A06E27B192F9D@addom.santronics.com> <1614517.uns7AmPsly@scott-latitude-e6320> <6.2.5.6.2.20130207211859.09b859a8@resistor.net> Date: Thu, 7 Feb 2013 21:55:59 -0800 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7bd91a84be3cac04d53036f0 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? 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, 08 Feb 2013 05:56:02 -0000 --047d7bd91a84be3cac04d53036f0 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the reminder. Scott, we should make sure we didn't drop any of the things in the second thread in the long period since it petered out. However, the fact that 30 days is what the older Caller ID drafts said doesn't mean it's not an arbitrary number. I think something more general (see upthread) is probably more appropriate. -MSK On Thu, Feb 7, 2013 at 9:22 PM, S Moonesamy wrote: > Hi Murray, > > At 20:35 07-02-2013, Murray S. Kucherawy wrote: > >> If you were to characterize the 30 days as a "consensus estimate" or some >> such regarding a reasonable maximum time one might expect mail to take to >> be either delivered or returned as undeliverable, it would appear less >> arbitrary. >> > > See http://www.ietf.org/mail-**archive/web/spfbis/current/**msg02559.htmland > http://www.ietf.org/mail-**archive/web/spfbis/current/**msg01842.htmlfor the "30 days" text. > > Regards, > S. Moonesamy > --047d7bd91a84be3cac04d53036f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the reminder.=A0 Scott, we should make sur= e we didn't drop any of the things in the second thread in the long per= iod since it petered out.

However, the fact that 30 days = is what the older Caller ID drafts said doesn't mean it's not an ar= bitrary number.=A0 I think something more general (see upthread) is probabl= y more appropriate.

-MSK


On Thu, Feb 7, 2013 at 9:22 PM, S Moonesamy &l= t;sm+ietf@elandsy= s.com> wrote:
Hi Murray,

At 20:35 07-02-2013, Murray S. Kucherawy wrote:
If you were to characterize the 30 days as a "consensus estimate"= or some such regarding a reasonable maximum time one might expect mail to = take to be either delivered or returned as undeliverable, it would appear l= ess arbitrary.

See http://www.ietf.org/mail-archive/web/spfbis= /current/msg02559.html and http://www.ietf.= org/mail-archive/web/spfbis/current/msg01842.html for the= "30 days" text.

Regards,
S. Moonesamy

--047d7bd91a84be3cac04d53036f0-- From spf2@kitterman.com Thu Feb 7 21:59:04 2013 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 6E2E821F8962 for ; Thu, 7 Feb 2013 21:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGUIamsgnwXm for ; Thu, 7 Feb 2013 21:59:03 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 87BF521F8901 for ; Thu, 7 Feb 2013 21:59:03 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B011520E4113; Fri, 8 Feb 2013 00:59:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360303142; bh=8UTIsoL+w3tZC2Ne3CbmlTTNzuDVHwHmMsc+aHb/Dtc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=j6VNUG9LyTKxUSRtnSNpdgs7lO+32AEOzWSJPCL0QwG/JMhWd5sFWcsFN/2vxKSmO R0lmxA45oAFuzY4uj+GhhLlHqZmGIvcHoSFLsbGG71vL1HRCA1x5d/GV98+Z+BbzJv 2BVwJwKbk1ZLBihFYGN6QEy02UJfdqCRJhXzYd7U= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 91DC820E40FC; Fri, 8 Feb 2013 00:59:02 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 08 Feb 2013 00:59:01 -0500 Message-ID: <1423386.EJzyTaZKf7@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130207211859.09b859a8@resistor.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 2.3 - Genesis of 30 days delays? 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, 08 Feb 2013 05:59:04 -0000 I don't have any objection to going back to the general advice in 4408. I'm not convinced we can do better. Scott K On Thursday, February 07, 2013 09:55:59 PM Murray S. Kucherawy wrote: > Thanks for the reminder. Scott, we should make sure we didn't drop any of > the things in the second thread in the long period since it petered out. > > However, the fact that 30 days is what the older Caller ID drafts said > doesn't mean it's not an arbitrary number. I think something more general > (see upthread) is probably more appropriate. > > -MSK > > On Thu, Feb 7, 2013 at 9:22 PM, S Moonesamy wrote: > > Hi Murray, > > > > At 20:35 07-02-2013, Murray S. Kucherawy wrote: > >> If you were to characterize the 30 days as a "consensus estimate" or some > >> such regarding a reasonable maximum time one might expect mail to take to > >> be either delivered or returned as undeliverable, it would appear less > >> arbitrary. > > > > See > > http://www.ietf.org/mail-**archive/web/spfbis/current/**msg02559.html > p://www.ietf.org/mail-archive/web/spfbis/current/msg02559.html>and > > http://www.ietf.org/mail-**archive/web/spfbis/current/**msg01842.html > p://www.ietf.org/mail-archive/web/spfbis/current/msg01842.html>for the "30 > > days" text. > > > > Regards, > > S. Moonesamy From johnl@iecc.com Thu Feb 7 22:12:35 2013 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 C9F5321F89B9 for ; Thu, 7 Feb 2013 22:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.027 X-Spam-Level: X-Spam-Status: No, score=-111.027 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0daWJVG35uv for ; Thu, 7 Feb 2013 22:12:34 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9109921F848B for ; Thu, 7 Feb 2013 22:12:32 -0800 (PST) Received: (qmail 93524 invoked from network); 8 Feb 2013 06:12:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Feb 2013 06:12:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5114974f.xn--yuvv84g.k1302; i=johnl@user.iecc.com; bh=kuoAxxiKZsh8aC2lKyWkNrppE1CFkj/DxvvxfOqc+rA=; b=llPHcfxvENYTxX4kCP2JpZzTugwv38AShzjL8TJfA+/kHJvXx+c3YoP6M8h6KkxorC0oFFcXfzz4DjTyZ6BfWjertANZjvc2vjxScu1Kz7Z2pSVJ3euu06q0+86seThPxDXQMe2U3BXpIED9ZpK5ze8ryFsqtDDVggduqok4oU4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5114974f.xn--yuvv84g.k1302; olt=johnl@user.iecc.com; bh=kuoAxxiKZsh8aC2lKyWkNrppE1CFkj/DxvvxfOqc+rA=; b=bDebkX5wjl2FiOl+Q33nKhmEY0zo+QHBm093jvcdonor/egyTqKIHyGUOem2qlKswbBC24Y8SHLDxO7/nwW0VefNLBY/KUS0sheXVYBTQEdeFqM9FUwkJspuGa4TmuimkXvA5C+HPMeOE40MQ1f05W7AS9+SPp212lPQm3YKQMg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 8 Feb 2013 06:12:09 -0000 Message-ID: <20130208061209.3588.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20130207211859.09b859a8@resistor.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: sm+ietf@elandsys.com Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? 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, 08 Feb 2013 06:12:36 -0000 >>If you were to characterize the 30 days as a "consensus estimate" or >>some such regarding a reasonable maximum time one might expect mail >>to take to be either delivered or returned as undeliverable, it >>would appear less arbitrary. The reality is that we're pulling it out of our rears. RFC 5321 says that SMTP deliveries can take five days, and my understanding has always been that you should be prepared for mail to trickle in for up to a week. But do we have any idea about the actual practices of people who do off line SPF verification? Do they wait a week? A month? A year? In DKIM (yes, I know this isn't DKIM) we made a concrete decision that DKIM isn't for archival verification of messages, it's for checking messages in transit, and in that way SPF is similar. I would also remember that SPF records depend on MX, A, and other records that have their own update schedules. My preference would be to point to 5321 for how long a message might be in transit, and to note that while it's not forbidden to do offline checks, the closer to the time of receipt you do the checks, the more likely you are to get the answer that the domain owner intended. From hsantos@isdg.net Fri Feb 8 04:51:08 2013 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 1EB9221F8810 for ; Fri, 8 Feb 2013 04:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.257 X-Spam-Level: X-Spam-Status: No, score=-102.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5PuPJGZ82ta for ; Fri, 8 Feb 2013 04:51:07 -0800 (PST) Received: from dkim.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECFC21F8806 for ; Fri, 8 Feb 2013 04:51:06 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1640; t=1360327861; h=Received:Received: Message-ID:From:To:Subject:Date:Organization:List-ID; bh=UIchk1B Jhcg7CV+wBORTyIiQ5HU=; b=K9US9cXJopiE36psHevuO5hdid09+ldL2y/6pNC EOoJecC/m2ZRsIzz771O8e2glUcgUZTD1M8zX9vxJMviXdve8iIgjj1h9W1sj/VP EhxdnW2GsMWc0g8O9VBEvuv9JKIXqJag9LrNMFdfV5XQqkwqNiQF/D4gFBMSfksm hYcw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 08 Feb 2013 07:51:01 -0500 Received: from main2 ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3464590682.26813.2996; Fri, 08 Feb 2013 07:51:00 -0500 Message-ID: <9F5D1AD2919D47B58D430E4AFC953D3D@addom.santronics.com> From: "Hector Santos" To: References: <20130208061209.3588.qmail@joyce.lan> Date: Fri, 8 Feb 2013 07:49:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Cc: sm+ietf@elandsys.com Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? 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, 08 Feb 2013 12:51:08 -0000 +1 ----- Original Message -----=20 From: "John Levine" To: Cc: Sent: Friday, February 08, 2013 1:12 AM Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? >>>If you were to characterize the 30 days as a "consensus estimate" or=20 >>>some such regarding a reasonable maximum time one might expect mail=20 >>>to take to be either delivered or returned as undeliverable, it=20 >>>would appear less arbitrary. >=20 > The reality is that we're pulling it out of our rears. >=20 > RFC 5321 says that SMTP deliveries can take five days, and my > understanding has always been that you should be prepared for mail to > trickle in for up to a week. But do we have any idea about the actual > practices of people who do off line SPF verification? Do they wait a > week? A month? A year? >=20 > In DKIM (yes, I know this isn't DKIM) we made a concrete decision that > DKIM isn't for archival verification of messages, it's for checking > messages in transit, and in that way SPF is similar. I would also > remember that SPF records depend on MX, A, and other records that have > their own update schedules. >=20 > My preference would be to point to 5321 for how long a message might > be in transit, and to note that while it's not forbidden to do offline > checks, the closer to the time of receipt you do the checks, the more > likely you are to get the answer that the domain owner intended. >=20 > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From superuser@gmail.com Fri Feb 8 07:40:26 2013 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 2BEE821F8A80 for ; Fri, 8 Feb 2013 07:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nHJv-hLFfHc for ; Fri, 8 Feb 2013 07:40:25 -0800 (PST) Received: from mail-we0-x230.google.com (we-in-x0230.1e100.net [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF7621F8AA3 for ; Fri, 8 Feb 2013 07:40:25 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so3059438wey.21 for ; Fri, 08 Feb 2013 07:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zSPCcsFlb/mQHpM+6b8M47NhlUomPqdvd+EXvTBRXg4=; b=hn/Y4JSh4r7snsFCTxZw2pV/zC+RJyCVVcJniESGxPPxtIRAGcfzgT9RBpoWJoQXUO mmmtciD9CZBSQgwV9wPSmtjTTzDkp2CIOjZAxmqr1/vnF/bhprI4Ke5Kq0Kct3DCI2J+ 7fOoXL1oUw79VGpUsxBfy4+fv+myyArRyKs33k6Pr+jJppojz7noHymZ0WaWZIW4g6NU 0iGoqqQcBPYysI32YY7IriM6a9Jkon8ylGl/qVfpxi5Q0DkIiCo/5gorWj/U5kG7v8DK 6upM2SmaBe8N7FkeZS4exNpljyGi4zLrJ96lMA6U/ogDHf9KB6QI1BOjgVeI9dWJ/uko ciow== MIME-Version: 1.0 X-Received: by 10.194.174.196 with SMTP id bu4mr10595975wjc.35.1360338024290; Fri, 08 Feb 2013 07:40:24 -0800 (PST) Received: by 10.180.164.43 with HTTP; Fri, 8 Feb 2013 07:40:23 -0800 (PST) In-Reply-To: <20130208061209.3588.qmail@joyce.lan> References: <6.2.5.6.2.20130207211859.09b859a8@resistor.net> <20130208061209.3588.qmail@joyce.lan> Date: Fri, 8 Feb 2013 07:40:23 -0800 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=089e0149331ab65b6c04d5386005 Cc: "spfbis@ietf.org" , SM Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? 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, 08 Feb 2013 15:40:26 -0000 --089e0149331ab65b6c04d5386005 Content-Type: text/plain; charset=ISO-8859-1 Works for me. On Thu, Feb 7, 2013 at 10:12 PM, John Levine wrote: > >>If you were to characterize the 30 days as a "consensus estimate" or > >>some such regarding a reasonable maximum time one might expect mail > >>to take to be either delivered or returned as undeliverable, it > >>would appear less arbitrary. > > The reality is that we're pulling it out of our rears. > > RFC 5321 says that SMTP deliveries can take five days, and my > understanding has always been that you should be prepared for mail to > trickle in for up to a week. But do we have any idea about the actual > practices of people who do off line SPF verification? Do they wait a > week? A month? A year? > > In DKIM (yes, I know this isn't DKIM) we made a concrete decision that > DKIM isn't for archival verification of messages, it's for checking > messages in transit, and in that way SPF is similar. I would also > remember that SPF records depend on MX, A, and other records that have > their own update schedules. > > My preference would be to point to 5321 for how long a message might > be in transit, and to note that while it's not forbidden to do offline > checks, the closer to the time of receipt you do the checks, the more > likely you are to get the answer that the domain owner intended. > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --089e0149331ab65b6c04d5386005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Works for me.


=
On Thu, Feb 7, 2013 at 10:12 PM, John Levine <joh= nl@taugh.com> wrote:
>>If you were to cha= racterize the 30 days as a "consensus estimate" or
>>some such regarding a reasonable maximum time one might expect mail=
>>to take to be either delivered or returned as undeliverable, it
>>would appear less arbitrary.

The reality is that we're pulling it out of our rears.

RFC 5321 says that SMTP deliveries can take five days, and my
understanding has always been that you should be prepared for mail to
trickle in for up to a week. =A0But do we have any idea about the actual practices of people who do off line SPF verification? =A0Do they wait a
week? A month? A year?

In DKIM (yes, I know this isn't DKIM) we made a concrete decision that<= br> DKIM isn't for archival verification of messages, it's for checking=
messages in transit, and in that way SPF is similar. =A0I would also
remember that SPF records depend on MX, A, and other records that have
their own update schedules.

My preference would be to point to 5321 for how long a message might
be in transit, and to note that while it's not forbidden to do offline<= br> checks, the closer to the time of receipt you do the checks, the more
likely you are to get the answer that the domain owner intended.

_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--089e0149331ab65b6c04d5386005-- From hsantos@isdg.net Fri Feb 8 08:23:39 2013 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 4094421F87EE for ; Fri, 8 Feb 2013 08:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.291 X-Spam-Level: X-Spam-Status: No, score=-102.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlakwPciLCeq for ; Fri, 8 Feb 2013 08:23:37 -0800 (PST) Received: from groups.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE8521F8581 for ; Fri, 8 Feb 2013 08:23:36 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3008; t=1360340606; h=Received:Received: Message-ID:From:To:Subject:Date:Organization:List-ID; bh=Y3iftlD BjMSDJ1Qzb0CGow07+Sc=; b=i5tioqBuFfMK7X02+dUxsDMLcZ+NtD0/NhtAAIj GlJ/1/Z8q23dSlQ+RY7oAVLbAdFqfXvM7YnjnqeTFn6lOe8N79wC1coNK/o7up5B oT+QcYG2wJ2wj0XY74FsLU3LSwD/Gs023nR5c95SYEIipwVi+28jAMyr3xUIKpzM yrLQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 08 Feb 2013 11:23:26 -0500 Received: from main2 ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3477335480.26813.5180; Fri, 08 Feb 2013 11:23:25 -0500 Message-ID: <0CDCD566300E410A995621453688AC93@addom.santronics.com> From: "Hector Santos" To: "Murray S. Kucherawy" References: <6.2.5.6.2.20130207211859.09b859a8@resistor.net><20130208061209.3588.qmail@joyce.lan> Date: Fri, 8 Feb 2013 11:21:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Cc: spfbis@ietf.org, SM Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? 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, 08 Feb 2013 16:23:39 -0000 I think if anything needs to be stated, is possibly an example sentence = illustrating a type of SPF policy change which could affect existing = mail in the delivery/outbound queue(s). Offhand, its only an issue when the IP::DOMAIN LMAP/SPF association = changes - not an issue for minor corrections and policy updates where = the IP::DOMAIN association does not change. Like I could decide after = BIS is published to change all our current PTR SPF usage to specific IP4 = rules. A big change for our DNS records maintenance procedure (someone = needs to be aware IP/Machine changes requires updating SPF records), but = overall, the IP::DOMAIN will be effectively the same so bo problem for = emails in the loop. This can help ease readers who now see the concerns = of PTR usage and feel ok the change will not hurt the mail. The general SMTP guideline 4-5 days as part of a typical mail = delivery retry strategies -- HLS ----- Original Message -----=20 From: "Murray S. Kucherawy" To: "John Levine" Cc: ; "SM" Sent: Friday, February 08, 2013 10:40 AM Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? > Works for me. >=20 >=20 > On Thu, Feb 7, 2013 at 10:12 PM, John Levine wrote: >=20 >> >>If you were to characterize the 30 days as a "consensus estimate" = or >> >>some such regarding a reasonable maximum time one might expect mail >> >>to take to be either delivered or returned as undeliverable, it >> >>would appear less arbitrary. >> >> The reality is that we're pulling it out of our rears. >> >> RFC 5321 says that SMTP deliveries can take five days, and my >> understanding has always been that you should be prepared for mail to >> trickle in for up to a week. But do we have any idea about the = actual >> practices of people who do off line SPF verification? Do they wait a >> week? A month? A year? >> >> In DKIM (yes, I know this isn't DKIM) we made a concrete decision = that >> DKIM isn't for archival verification of messages, it's for checking >> messages in transit, and in that way SPF is similar. I would also >> remember that SPF records depend on MX, A, and other records that = have >> their own update schedules. >> >> My preference would be to point to 5321 for how long a message might >> be in transit, and to note that while it's not forbidden to do = offline >> checks, the closer to the time of receipt you do the checks, the more >> likely you are to get the answer that the domain owner intended. >> >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> > -------------------------------------------------------------------------= ------- > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From hsantos@isdg.net Fri Feb 8 08:30:58 2013 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 2FD9221F8750 for ; Fri, 8 Feb 2013 08:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.313 X-Spam-Level: X-Spam-Status: No, score=-101.313 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, FAKE_REPLY_C=2.012, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KirfUwm3OmjE for ; Fri, 8 Feb 2013 08:30:57 -0800 (PST) Received: from groups.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 23A5D21F86B3 for ; Fri, 8 Feb 2013 08:30:57 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3736; t=1360341050; h=Received:Received: Message-ID:From:To:Subject:Date:Organization:List-ID; bh=VxQIN2f E7R6NfM4X6ETaZXIHVMU=; b=cJDRE+6+EmImHSxJbRu3UsyH7Ky2HBTZzT1uBVw D86eFGE1+WdcP9UCU0PLmaWRRDcBLXtSOf3ouVHlnfo9c5dt2GDKcL8nmTxeiYlh q2AGE2vfMpSiUkDwD8KDzxCfpoF72COHhluN5F2MKBcfa4sE7y+X3DZwThOyNrZk LYLY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 08 Feb 2013 11:30:50 -0500 Received: from main2 ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3477779068.26813.1620; Fri, 08 Feb 2013 11:30:49 -0500 Message-ID: From: "Hector Santos" To: "Murray S. Kucherawy" Date: Fri, 8 Feb 2013 11:29:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Cc: spfbis@ietf.org, SM Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? 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, 08 Feb 2013 16:30:58 -0000 (Hit SEND to soon, I was going to propose some sample text in the end = there) The general SMTP guideline of 4-5 days is part of a typical=20 mail delivery retry strategy [RFC5321]. False positives can occur when SPF policies are alter and the IP::DOMAIN SPF associates changes. A change, such as updating records to=20 replace PTR with IP4/IP6 rules, should not be a concern with existing mail in delivery queues. -- HLS ----- Original Message -----=20 From: "Hector Santos" To: "Murray S. Kucherawy" Cc: ; "SM" Sent: Friday, February 08, 2013 11:21 AM Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? I think if anything needs to be stated, is possibly an example sentence = illustrating a type of SPF policy change which could affect existing = mail in the delivery/outbound queue(s). Offhand, its only an issue when the IP::DOMAIN LMAP/SPF association = changes - not an issue for minor corrections and policy updates where = the IP::DOMAIN association does not change. Like I could decide after = BIS is published to change all our current PTR SPF usage to specific IP4 = rules. A big change for our DNS records maintenance procedure (someone = needs to be aware IP/Machine changes requires updating SPF records), but = overall, the IP::DOMAIN will be effectively the same so bo problem for = emails in the loop. This can help ease readers who now see the concerns = of PTR usage and feel ok the change will not hurt the mail. The general SMTP guideline 4-5 days as part of a typical mail = delivery retry strategies -- HLS ----- Original Message -----=20 From: "Murray S. Kucherawy" To: "John Levine" Cc: ; "SM" Sent: Friday, February 08, 2013 10:40 AM Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? > Works for me. >=20 >=20 > On Thu, Feb 7, 2013 at 10:12 PM, John Levine wrote: >=20 >> >>If you were to characterize the 30 days as a "consensus estimate" = or >> >>some such regarding a reasonable maximum time one might expect mail >> >>to take to be either delivered or returned as undeliverable, it >> >>would appear less arbitrary. >> >> The reality is that we're pulling it out of our rears. >> >> RFC 5321 says that SMTP deliveries can take five days, and my >> understanding has always been that you should be prepared for mail to >> trickle in for up to a week. But do we have any idea about the = actual >> practices of people who do off line SPF verification? Do they wait a >> week? A month? A year? >> >> In DKIM (yes, I know this isn't DKIM) we made a concrete decision = that >> DKIM isn't for archival verification of messages, it's for checking >> messages in transit, and in that way SPF is similar. I would also >> remember that SPF records depend on MX, A, and other records that = have >> their own update schedules. >> >> My preference would be to point to 5321 for how long a message might >> be in transit, and to note that while it's not forbidden to do = offline >> checks, the closer to the time of receipt you do the checks, the more >> likely you are to get the answer that the domain owner intended. >> >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> > -------------------------------------------------------------------------= ------- > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From spf2@kitterman.com Fri Feb 8 08:53:16 2013 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 2743E21F8B1D for ; Fri, 8 Feb 2013 08:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXNu8iB8mR2p for ; Fri, 8 Feb 2013 08:53:15 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7F021F854E for ; Fri, 8 Feb 2013 08:53:15 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 813C120E40C9; Fri, 8 Feb 2013 11:53:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360342394; bh=w2c4t6qcMFZOg+cyfp+bvqRE1kcCXk3SrkYj5pb0gAQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HUOJiL5K+7cf0Bue97IGkv2ZaQyb4jc2Bvs+jveFl4RWkD+/g7qjMfYOe+dFQGqSY dPuH+U9It+9uUfPabg8S2pqHrSxHcNUeWzQHWuC/5+6WdC+cFqHQ00Rg2YLzMXrkU8 nKLGWsTax27TNSYgbApIAKYlBPhsof7EkbkSpjHE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 37A7C20E40B0; Fri, 8 Feb 2013 11:53:13 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 08 Feb 2013 11:53:09 -0500 Message-ID: <6022027.EyeqQlmeK2@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <1377522.ULX4pbEB9u@scott-latitude-e6320> References: <20130207081151.28602.18588.idtracker@ietfa.amsl.com> <1377522.ULX4pbEB9u@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] I-D Action: draft-ietf-spfbis-4408bis-10.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: Fri, 08 Feb 2013 16:53:16 -0000 On Thursday, February 07, 2013 03:18:06 AM Scott Kitterman wrote: > On Thursday, February 07, 2013 12:11:51 AM internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the SPF Update Working Group of > > the IETF. > > > > Title : Sender Policy Framework (SPF) for Authorizing > > Use > > > > of Domains in Email, Version 1 Author(s) : Scott Kitterman > > > > Filename : draft-ietf-spfbis-4408bis-10.txt > > Pages : 73 > > Date : 2013-02-07 > > I believe this update addresses these open issues in the tracker: > > #36 RFC 2119 key words > #38 Deprecated > #43 New requirement for mx: or ptr records > #45 Section 5.5 steps > #46 DNS reply in Section 5.7 > #48 Section 8.1 - macro defs > #52 Section 8.1 *Macro Definitions > #33 Marked Failed Mail Exposure > > http://trac.tools.ietf.org/wg/spfbis/trac/report/1 > > Please review. I'll give people a bit of time to digest the revised draft > and raise concerns if they have them before I mark the issues as fixed. > Thanks to those who helped with the updates. I only got feedback on #36, so I'll leave that open and close the rest of the listed issues. I'll address #36 and the results of the Section 2.3 discussion in -11. I'll give specific feedback on the issue #36 comments once I've had time to digest them. Thanks, Scott K From spf2@kitterman.com Fri Feb 8 13:13:19 2013 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 5D07D21F8C0B for ; Fri, 8 Feb 2013 13:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5pP89fpIT+p for ; Fri, 8 Feb 2013 13:13:18 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 714B221F8AB1 for ; Fri, 8 Feb 2013 13:13:18 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8421620E40C9; Fri, 8 Feb 2013 16:13:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360357997; bh=ZZrx4hGAxiSJf8PJllYk7Wbdv33LdhrKiK8mv4owo0U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ffkxwgd/e+4CLQnlKco+rF0FxbfbjcRhiszWsk98bsfwcYohrT2anuF/3GWQrWU1c tp3qYq6wfTmMhlKAt5bBiFAdiWHbXWow5qNtvjWruiEwMffEllm7OiE5L3PNlRpykF oqaviOR3pRLvn6hv37eejhJO/xpSAC4PTkutpOyA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 67AD520E40BE; Fri, 8 Feb 2013 16:13:16 -0500 (EST) From: Scott Kitterman To: "spfbis@ietf.org" Date: Fri, 08 Feb 2013 16:13:09 -0500 Message-ID: <21604708.4WkHlj1qTs@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <1582575.VsSs9YShWJ@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] Revisit: Issue #36: RFC 2119 key words 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, 08 Feb 2013 21:13:19 -0000 On Thursday, February 07, 2013 06:48:22 PM Barry Leiba wrote: > >> most of the lower case words have been changed to synonyms, a few have > >> been > >> changed into RFC 2119 keywords. I > >> think most (but sadly, not all) of these capitalizations are wrong." > >> > >> Could this be made more specific? Which ones are wrong? > > > > Unfortunately Arthur hasn't been very active lately, so I was hoping > > someone experienced with RFC lawyering could have a look and see if there > > were any they felt were wrong. I've already gone back and fixed several > > that I concluded in retrospect were wrong. > > There aren't many wrong ones, I think. Here's what I found in a brief > pass through: > > -- Section 4.5 -- > Starting with the set of records that were returned by the lookup, > discard records that do not begin with a version section of exactly > "v=spf1". Note that the version section is terminated either by an > SP character or the end of the record. A record with a version > section of "v=spf10" does not match and MUST be discarded. > > This "MUST" seems out of place, because there's no "MUST" in the first > sentence. I think you should make it "and is discarded." Done. > -- Section 4.6 -- > I don't see what the second paragraph adds to the first, and suggest > eliminating it. That particular text is unchanged from RFC 4408. IIRC, the reason it is there was there was some question back in the day about how processing should work. As an example: You get a message from a domain what has this SPF record: v=spf1 a:relay.example.com foo:bar.example.com -all This is a syntactically invalid record because there is no mechanism foo. The question the second paragraph was meant to address is, "What is the correct result for a message from relay.example.com?" It's either pass (strict left to right processing) or permerror (all errors must be detected). The correct answer is it's a permerror and we want to make that clear. My preference would be to leave it alone, but I'm open to suggestions for better wording. > -- Section 4.6.4 -- > In the second paragraph, why are you mixing "MX resource records" in > the first sentence with "A resource records" in the second sentence? > Is this a typo, or intentional? If it's intentional, I would re-word > it, which will probably correct the odd "MUST". What I was trying to communicate there is something like the following sequence: - Do mx lookup for the domain. - One or more a records returned - If the number of a records is =< 10, then do a lookups to find the relevant IP addresses - If the number of a records is > 10, don't do any lookups and return a permerror. When I look at it, I think it says that, but obviously it's not clear. Wording suggestions appreciated. > -- Section 5 -- > When any mechanism fetches host addresses to compare with , when > is an IPv4 address, A records are fetched; when is an IPv6 > address, AAAA records are fetched. Even if the SMTP connection uses > IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) > MUST still be considered an IPv4 address and MUST be evaluated using > IPv4 mechanisms (i.e. "ip4" and "a"). > > Again, the lack of "MUST" in the first sentence makes the use of it in > the second sentence odd. I'd make the "MUST ... be" constructions > into "is". The construction I'm going for here is: if $CONDITION then MUST $STUFF It didn't strike me as odd, but I guess it is. Using the IP4: mechanisms for IPv4 mapped IPv6 addresses is an interoperability requirement. How would you suggest going about it? > -- Section 10 -- > The "SHOULD" in the first paragraph is wrong. If what you want to say > is that the section isn't normative, then say it that way, as "and it > is not a comprehensive list of normative requirements." Otherwise, > just make it "should". Done. Thanks for the review. Scott K From sm@resistor.net Fri Feb 8 13:36:30 2013 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 95B5921F8C05 for ; Fri, 8 Feb 2013 13:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P3iiDzRsSCh for ; Fri, 8 Feb 2013 13:36:30 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4E121F8C03 for ; Fri, 8 Feb 2013 13:36:29 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r18LaP5r022401 for ; Fri, 8 Feb 2013 13:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360359389; bh=bl1HLxO3xVbaiVAGeJQkLanIGPw5H3imZFsHyOg41x4=; h=Date:To:From:Subject:In-Reply-To:References; b=yZoOZ2VUr2jWTYHOVLIj0N47N3fC7COd7DM/C7JMmAJL5AFr0Q9vYd82N9PjKkL2M OQaB8q2rVUBtSxoic/RcrNR4b9ti0yG4VVZaRHTao0+B8FmeN3mT0wNZDoxRiJ7CG9 1jfQWajR/odQXFuzZFr7zrH+H1awl+L4p+Htu4/E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360359389; i=@resistor.net; bh=bl1HLxO3xVbaiVAGeJQkLanIGPw5H3imZFsHyOg41x4=; h=Date:To:From:Subject:In-Reply-To:References; b=wgSABHBG+Y5+JUyRF7deOq3NUWB2Fy+hRaNP0wVbAFOMq9ECqiO3pQQ/r/AylLYO3 joERpc93rMNfs4BqwETAWtr+ljNV7EDODIbLuSGoeEtdUFGFifjifN5+m4UdJ3j3Rb eYy7ez9E7qDgagz4DRdvx+eaOEjsLPLnzwj2VliE= Message-Id: <6.2.5.6.2.20130208132347.054bf1e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 08 Feb 2013 13:35:39 -0800 To: spfbis@ietf.org From: SM In-Reply-To: References: <1582575.VsSs9YShWJ@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 08 Feb 2013 21:36:30 -0000 At 15:48 07-02-2013, Barry Leiba wrote: >-- Section 5 -- > When any mechanism fetches host addresses to compare with , when > is an IPv4 address, A records are fetched; when is an IPv6 > address, AAAA records are fetched. Even if the SMTP connection uses > IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) > MUST still be considered an IPv4 address and MUST be evaluated using > IPv4 mechanisms (i.e. "ip4" and "a"). > >Again, the lack of "MUST" in the first sentence makes the use of it in >the second sentence odd. I'd make the "MUST ... be" constructions >into "is". The second sentence in Section 5 looks incorrect. An IPv4-mapped IPv6 address is not used for an IPv6 connection. Regards, -sm From spf2@kitterman.com Fri Feb 8 13:43:39 2013 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 6B78E21F8B6E for ; Fri, 8 Feb 2013 13:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAKuMzWFiWeB for ; Fri, 8 Feb 2013 13:43:38 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C304421F8B61 for ; Fri, 8 Feb 2013 13:43:38 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3ECCD20E40C9; Fri, 8 Feb 2013 16:43:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360359818; bh=Gq/bKdbHS8+6Oxz4oiNWZqaCuXQU7yNAcdV+5HLs/h8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OWIiaKb69NiFfvt/mzkWxKcYhxK0VqWyrRvkhMar5N5s9GnFFj/OAmxxMSiaNxnOw CGPnXTVxinfd+CbR6Wnh8maXkUhjyDqN1bRdZsovlgz3SU5AiM/t7JykK/KVNK50S7 gmyG8OmULuc1aQwpBlzPFlS2moCMZrK4WaUE5qL8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2959E20E40BE; Fri, 8 Feb 2013 16:43:37 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 08 Feb 2013 16:43:37 -0500 Message-ID: <1631200.9rmLqgtUTV@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130208132347.054bf1e0@resistor.net> References: <6.2.5.6.2.20130208132347.054bf1e0@resistor.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] Revisit: Issue #36: RFC 2119 key words 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, 08 Feb 2013 21:43:39 -0000 On Friday, February 08, 2013 01:35:39 PM SM wrote: > At 15:48 07-02-2013, Barry Leiba wrote: > >-- Section 5 -- > > > > When any mechanism fetches host addresses to compare with , when > > is an IPv4 address, A records are fetched; when is an IPv6 > > address, AAAA records are fetched. Even if the SMTP connection uses > > IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) > > MUST still be considered an IPv4 address and MUST be evaluated using > > IPv4 mechanisms (i.e. "ip4" and "a"). > > > >Again, the lack of "MUST" in the first sentence makes the use of it in > >the second sentence odd. I'd make the "MUST ... be" constructions > >into "is". > > The second sentence in Section 5 looks incorrect. An IPv4-mapped > IPv6 address is not used for an IPv6 connection. If you're on a pure IPv6 host and you get a connection from ::ffff:192.0.2.1, isn't that an IPv6 connection? Scott K From barryleiba.mailing.lists@gmail.com Fri Feb 8 13:57:08 2013 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 22FD821F8C07 for ; Fri, 8 Feb 2013 13:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkp-pcE+mW9X for ; Fri, 8 Feb 2013 13:57:07 -0800 (PST) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 40FC421F89FC for ; Fri, 8 Feb 2013 13:57:07 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id cz10so3665259veb.7 for ; Fri, 08 Feb 2013 13:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1Is88GpHaVFmCa6zTHHO6uR1hlN01OhNyRkOWmwvFG0=; b=Lp2W87sDsBn3LyPyYkiixiwPPHMJYsROWav+lLOAD+UgznH11rSkTnZsToQOSKV6C/ B0KuxpANk7PtcGU+Z1khN/+Za21xPz2yztqB0e9JkxAsdIkusgybejQ4peukG5pYfvmF u+UHFVR+nkicpVZgK0C21H+lbdIe0ntbDFMdeqivohy/DIfU+yvAvUcUylpz4Zr5QeSc WK+RRjrSsHUqLtEOiv+bTLb4X96OevgcdXphG1iPyEv7Q9SNJA+7X3XqmLi4bm2smgS3 fpQQpN3UG0EY8pITCM2sRVz7coL2bv2KMz1fjZLAFzu0mEXYLXnUao/WVIsGnyojLZVJ Y3Hg== MIME-Version: 1.0 X-Received: by 10.58.106.161 with SMTP id gv1mr8869285veb.35.1360360626649; Fri, 08 Feb 2013 13:57:06 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Fri, 8 Feb 2013 13:57:05 -0800 (PST) In-Reply-To: <21604708.4WkHlj1qTs@scott-latitude-e6320> References: <1582575.VsSs9YShWJ@scott-latitude-e6320> <21604708.4WkHlj1qTs@scott-latitude-e6320> Date: Fri, 8 Feb 2013 16:57:05 -0500 X-Google-Sender-Auth: 2lN_iKCDMNyy3yF6-5d7AvJX2TU Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 08 Feb 2013 21:57:08 -0000 >> -- Section 4.6 -- >> I don't see what the second paragraph adds to the first, and suggest >> eliminating it. > > That particular text is unchanged from RFC 4408. IIRC, the reason it is there > was there was some question back in the day about how processing should work. > As an example: > > You get a message from a domain what has this SPF record: > > v=spf1 a:relay.example.com foo:bar.example.com -all > > This is a syntactically invalid record because there is no mechanism foo. The > question the second paragraph was meant to address is, "What is the correct > result for a message from relay.example.com?" It's either pass (strict left > to right processing) or permerror (all errors must be detected). The correct > answer is it's a permerror and we want to make that clear. I think the first paragraph already says what you need. Maybe a small tweak to it will make you happier: OLD The check_host() function parses and interprets the SPF record to find a result for the current test. If there are any syntax errors, check_host() returns immediately with the result "permerror". NEW The check_host() function parses and interprets the SPF record to find a result for the current test. If there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation. ...and then remove the second paragraph. Works? >> -- Section 4.6.4 -- >> In the second paragraph, why are you mixing "MX resource records" in >> the first sentence with "A resource records" in the second sentence? >> Is this a typo, or intentional? If it's intentional, I would re-word >> it, which will probably correct the odd "MUST". > > What I was trying to communicate there is something like the following > sequence: > > - Do mx lookup for the domain. > - One or more a records returned > - If the number of a records is =< 10, then do a lookups to find the relevant > IP addresses > - If the number of a records is > 10, don't do any lookups and return a > permerror. > > When I look at it, I think it says that, but obviously it's not clear. > Wording suggestions appreciated. Right, but you start by talking about how many MX lookups there are. What you say in your explanation above is that there's one, and the issue is how many A records that expands to. As written, it seems to say that you can do up to 10 MX lookups, and each of those can result in up to 10 A lookups, for a total of 110 DNS lookups. Is that what you mean? Are you trying to limit the total number of lookups in an SPF-record evaluation? Or just the total number from any one clause? Maybe this is enough to help you with wording... or maybe when you answer the questions above, I can take a stab. >> -- Section 5 -- >> When any mechanism fetches host addresses to compare with , when >> is an IPv4 address, A records are fetched; when is an IPv6 >> address, AAAA records are fetched. Even if the SMTP connection uses >> IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) >> MUST still be considered an IPv4 address and MUST be evaluated using >> IPv4 mechanisms (i.e. "ip4" and "a"). >> >> Again, the lack of "MUST" in the first sentence makes the use of it in >> the second sentence odd. I'd make the "MUST ... be" constructions >> into "is". > > The construction I'm going for here is: > > if $CONDITION then MUST $STUFF > > It didn't strike me as odd, but I guess it is. Using the IP4: mechanisms for > IPv4 mapped IPv6 addresses is an interoperability requirement. How would you > suggest going about it? Just as I said: make them "is", and it works. Remember that not all normative text has to have 2119 key words, and this paragraph strikes me as an example (and, BTW, I would put the record type names in quotes; it's not bad for "MX" and "AAAA" to lack them, but "A" without the quotes looks confusing): NEW-1 When any mechanism fetches host addresses to compare with , when is an IPv4 address, "A" records are fetched; when is an IPv6 address, "AAAA" records are fetched. Even if the SMTP connection uses IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) is still considered an IPv4 address and is evaluated using IPv4 mechanisms (i.e. "ip4" and "a"). Or better, I think: NEW-2 When any mechanism fetches host addresses to compare with an IPv4 address, it fetches "A" records; when comparing with an IPv6 address, it fetches "AAAA" records. Even if the SMTP connection uses IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) is still treated as an IPv4 address and is evaluated using IPv4 mechanisms. (Modulo your discussion with SM, of course.) Barry From sm@resistor.net Fri Feb 8 14:31:24 2013 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 CB34421F8B6E for ; Fri, 8 Feb 2013 14:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jeJ9slIlRK7 for ; Fri, 8 Feb 2013 14:31:23 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 839E821F8C09 for ; Fri, 8 Feb 2013 14:31:23 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r18MVHwp021843 for ; Fri, 8 Feb 2013 14:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360362681; bh=KEbSIh0QIUU/LM20WpoWFtNCIzSVF7EHC1AdOJlzjDs=; h=Date:To:From:Subject:In-Reply-To:References; b=gu5jU2lph+MsQ5fs4nCLIyohAPeoR5V/9xdQY9jUSbCf2b+H1MFNPZTMjGs7P3uc2 ztq6Kgf6GjDSuxwvUR+YVjQxGvbv+rW9eyVKyb9DUWtKyjUOzmwjgGVj3EwCSo6Qzu EIOLqM7Rkx7EnjHXw7gzT+0VqktXh8VEDSd1EUwo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360362681; i=@resistor.net; bh=KEbSIh0QIUU/LM20WpoWFtNCIzSVF7EHC1AdOJlzjDs=; h=Date:To:From:Subject:In-Reply-To:References; b=xOgS26lvTJtV7iEcoB37QektWjmkYreBhBevjnCWg5RLuGPzSQ/nu4Qkw1GAs/Vph AVTclJ6q95DoBC1GDayLg/a/vB9GV/rmDhP+uVDUzneorbUoZuoCqwYn3FXkDy7Ye3 pNlBdady1176rGRm1CxJ8rleHXc39KnH8qDubIFk= Message-Id: <6.2.5.6.2.20130208141307.0a0d9560@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 08 Feb 2013 14:21:36 -0800 To: spfbis@ietf.org From: SM In-Reply-To: <1631200.9rmLqgtUTV@scott-latitude-e6320> References: <6.2.5.6.2.20130208132347.054bf1e0@resistor.net> <1631200.9rmLqgtUTV@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 08 Feb 2013 22:31:24 -0000 Hi Scott, At 13:43 08-02-2013, Scott Kitterman wrote: >If you're on a pure IPv6 host and you get a connection from ::ffff:192.0.2.1, >isn't that an IPv6 connection? No, as it is an IPv4 connection. The IP address format is useful to make the application protocol independent. Regards, -sm From spf2@kitterman.com Fri Feb 8 16:32:25 2013 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 2AAF321F8C67 for ; Fri, 8 Feb 2013 16:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c-wSelMAeTx for ; Fri, 8 Feb 2013 16:32:24 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6258521F8C66 for ; Fri, 8 Feb 2013 16:32:24 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4E6C120E40C9; Fri, 8 Feb 2013 19:32:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360369943; bh=txVR/KhYZLGP2ptzCbllpEhycLLTnIYN+20MMMeooOI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZSef3IPTpdfh+PL0n/6oH8FzaBfJVkfOk0g+CoXkwHp/VPCLc4482NhcAOSLv22wy SLxLu0/EAZsgXWGjAuVboZeXF33Ff5oaZKSy634rzxHny+aYmDaR8gNzLI1q2iI2Oi Zg0/tHCXBWQNy5HCJiSHFLdHkd8G2qZPShgPIRdU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 15C6520E40BE; Fri, 8 Feb 2013 19:32:22 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 08 Feb 2013 19:32:18 -0500 Message-ID: <1624739.Q2hu5zvn8A@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130208141307.0a0d9560@resistor.net> References: <1631200.9rmLqgtUTV@scott-latitude-e6320> <6.2.5.6.2.20130208141307.0a0d9560@resistor.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] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 00:32:25 -0000 On Friday, February 08, 2013 02:21:36 PM SM wrote: > Hi Scott, > > At 13:43 08-02-2013, Scott Kitterman wrote: > >If you're on a pure IPv6 host and you get a connection from > >::ffff:192.0.2.1, isn't that an IPv6 connection? > > No, as it is an IPv4 connection. The IP address format is useful to > make the application protocol independent. OK. I do think it's important that people know to use the ip4: mechansim for mapped addresses. How would you word it? Scott K From spf2@kitterman.com Fri Feb 8 16:51:25 2013 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 CD3FC21F8C3E for ; Fri, 8 Feb 2013 16:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRCQKkXA3SrA for ; Fri, 8 Feb 2013 16:51:25 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2779621F8C32 for ; Fri, 8 Feb 2013 16:51:25 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A26D520E40C9; Fri, 8 Feb 2013 19:51:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360371084; bh=nCM2NFB+Rgc/51EDMkEP/wzDWwrh7m3T/HvGoBZ6lwY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ri+rCg019DsmRzfFKnkNfh2duBt4B3TR9StmmazatHaln6bcuFbjNKqAgZNdI+IIS tdu+h95rTjOmjttUhdMy2RKkAxdhRUL9rw7gUTrLRmPBHKJ5Y1PeXtoHZIgMyL8wkS ub5Tr3lXAuexDA1jd+qHOx0fCKbRKCd3eQ6kSAd4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 849E020E40BE; Fri, 8 Feb 2013 19:51:24 -0500 (EST) From: Scott Kitterman To: "spfbis@ietf.org" Date: Fri, 08 Feb 2013 19:51:23 -0500 Message-ID: <3176279.ZD4dlLcq5n@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <21604708.4WkHlj1qTs@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] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 00:51:25 -0000 On Friday, February 08, 2013 04:57:05 PM Barry Leiba wrote: > >> -- Section 4.6.4 -- > >> In the second paragraph, why are you mixing "MX resource records" in > >> the first sentence with "A resource records" in the second sentence? > >> Is this a typo, or intentional? If it's intentional, I would re-word > >> it, which will probably correct the odd "MUST". > > > > What I was trying to communicate there is something like the following > > > > sequence: > > - Do mx lookup for the domain. > > - One or more a records returned > > - If the number of a records is =< 10, then do a lookups to find the > >relevant> > > IP addresses > > > > - If the number of a records is > 10, don't do any lookups and return a > > > > permerror. > > > > When I look at it, I think it says that, but obviously it's not clear. > > Wording suggestions appreciated. > > Right, but you start by talking about how many MX lookups there are. > What you say in your explanation above is that there's one, and the > issue is how many A records that expands to. > > As written, it seems to say that you can do up to 10 MX lookups, and > each of those can result in up to 10 A lookups, for a total of 110 DNS > lookups. Is that what you mean? Yes. This is the basis for the infamous 111 DNS lookups. > Are you trying to limit the total number of lookups in an SPF-record > evaluation? Or just the total number from any one clause? For a single term (clause). > Maybe this is enough to help you with wording... or maybe when you > answer the questions above, I can take a stab. Please do. Scott K From barryleiba.mailing.lists@gmail.com Fri Feb 8 20:20:24 2013 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 C1B1F21F8C09 for ; Fri, 8 Feb 2013 20:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.874 X-Spam-Level: X-Spam-Status: No, score=-102.874 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeG+pO2CucpV for ; Fri, 8 Feb 2013 20:20:24 -0800 (PST) Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2F46421F8C05 for ; Fri, 8 Feb 2013 20:20:24 -0800 (PST) Received: by mail-vb0-f42.google.com with SMTP id ff1so2775749vbb.15 for ; Fri, 08 Feb 2013 20:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=o21CQTesQQ4e1CZYejCjhZ0BI0+WRgsz5p6yJ2S4Ufs=; b=qcNahBXuhiBD6lQkpTfDoBm+ihzT+hHz1G2D/Yzjo9XXNFTd9Wk071Ec7yULaakcci 9IAV8uSIWi9Q9AHTYx0+SRZw7thT3DfTfDPsg1iGYazKsPbBTZraafY5q/TGpb5LkfmV tCBje8nrHRE99Pki7cLH6X8pwhRHIrp+Z3A3wReVqvEitbAB9qz1mmhFR/oNZwFKd06t 2OUWAngBzwCCSFoR6/WhpKDXJsuuE7zsdsVvglo4BnSZ4WsHS2JH2yPb0/lBfpqstkQl 55h83oJFjnI7749u/KZHOT1WaaOAhr//Ebgq4GA88OslpQ9xcK1TUgJOhTCz+5q5WNIx m2nQ== MIME-Version: 1.0 X-Received: by 10.58.188.48 with SMTP id fx16mr9896847vec.22.1360383623465; Fri, 08 Feb 2013 20:20:23 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Fri, 8 Feb 2013 20:20:23 -0800 (PST) In-Reply-To: <3176279.ZD4dlLcq5n@scott-latitude-e6320> References: <21604708.4WkHlj1qTs@scott-latitude-e6320> <3176279.ZD4dlLcq5n@scott-latitude-e6320> Date: Fri, 8 Feb 2013 23:20:23 -0500 X-Google-Sender-Auth: HB5nouxhCteFcHjvb9i2rmwW-qY Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 04:20:24 -0000 >> > What I was trying to communicate there is something like the following >> > sequence: >> > - Do mx lookup for the domain. >> > - One or more a records returned >> > - If the number of a records is =< 10, then do a lookups to find the >> > relevant IP addresses >> > - If the number of a records is > 10, don't do any lookups and return a >> > permerror. >> > >> > When I look at it, I think it says that, but obviously it's not clear. >> > Wording suggestions appreciated. ... >> Are you trying to limit the total number of lookups in an SPF-record >> evaluation? Or just the total number from any one clause? > > For a single term (clause). OK, let's try this: OLD When evaluating the "mx" mechanism, the number of MX resource records queried MUST NOT exceed 10. If the evaluation of an "mx" mechanism results in more than 10 A resource records to be queried, the "mx" mechanism MUST produce a "permerror" result. NEW When evaluating the "mx" mechanism, the number of "MX" resource records queried MUST NOT exceed 10, and the evaluation of each "MX" record MUST NOT result in querying more than 10 "A" resource records. If either of these limits is exceeded, the "mx" mechanism MUST produce a "permerror" result. Does that work? Barry From sm@resistor.net Fri Feb 8 22:20:01 2013 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 94B6721F8C6C for ; Fri, 8 Feb 2013 22:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNTEkZULD9ma for ; Fri, 8 Feb 2013 22:20:00 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D5E21F8C6F for ; Fri, 8 Feb 2013 22:20:00 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r196JtST000118 for ; Fri, 8 Feb 2013 22:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360390799; bh=/XMPzjoIig7511lNAtDm+JzuOgqjcFsABgPnHWbK7bw=; h=Date:To:From:Subject:In-Reply-To:References; b=QfBvhSsWTUjrL2xjtlZgOt6vFRTL69L/mpPq0s/RPlPLUw2oTpWjIEhpJfEtIcMWT s2DHyPjUJEA6WzQsDzXbuQ3pJnjvKAXj3zPhE7f5BbSvUFZFjCF5XYTJVhgBKd9hBB KlcgDjpaSE60ABQRGgSVCWM1PryJxixr+o5DAevw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360390799; i=@resistor.net; bh=/XMPzjoIig7511lNAtDm+JzuOgqjcFsABgPnHWbK7bw=; h=Date:To:From:Subject:In-Reply-To:References; b=IVgrnbxCWqlDUFd+2M8pLkL8EOPVe8RrmAq5icCBL6bs9fSx7nCkHfRJjQhWK7sL8 Qs+pmFcTQ4TS3yQYMFGXTyJ+X4mW8sJ4DjU2lKRnhERPdQV006b3KPQJ2p61851RWY vsXlW+tWH2skCMEudynkxE6WDc4+wjl5j+3TCAMs= Message-Id: <6.2.5.6.2.20130208213219.0b2df410@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 08 Feb 2013 21:36:16 -0800 To: spfbis@ietf.org From: SM In-Reply-To: <1624739.Q2hu5zvn8A@scott-latitude-e6320> References: <1631200.9rmLqgtUTV@scott-latitude-e6320> <6.2.5.6.2.20130208141307.0a0d9560@resistor.net> <1624739.Q2hu5zvn8A@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 06:20:01 -0000 Hi Scott, At 16:32 08-02-2013, Scott Kitterman wrote: >OK. I do think it's important that people know to use the ip4: mechansim for >mapped addresses. How would you word it? I'll look up how this is usually handled and sent text. Regards, -sm From spf2@kitterman.com Fri Feb 8 22:35:51 2013 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 C769621F8C96 for ; Fri, 8 Feb 2013 22:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmJ+wO4hzT8u for ; Fri, 8 Feb 2013 22:35:50 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C7D2521F8C8C for ; Fri, 8 Feb 2013 22:35:50 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3ADE820E40C9; Sat, 9 Feb 2013 01:35:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360391750; bh=UcmuXQNCm2q/E3u1ZtwWdddFj+QYUjM34+inyFpbFMU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GozG1qeXy13udVrm0rWI/ekM69u72d8fC1r6BACUJJLNaxN4nzMjONjjh+GhjK0Ho x9ggWOhXkOEudGxaL9YFRsQAa9OypGgVSioaCPiLXXSPlCZlqVuUpkfUclNlG243Qf WnZN5zzgt2hkZYttsVqyGcSWUVQcpquU/LWdY4kA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2246420E40BE; Sat, 9 Feb 2013 01:35:49 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 09 Feb 2013 01:35:49 -0500 Message-ID: <1795240.3KDEi5jglR@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130208213219.0b2df410@resistor.net> References: <1624739.Q2hu5zvn8A@scott-latitude-e6320> <6.2.5.6.2.20130208213219.0b2df410@resistor.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] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 06:35:51 -0000 On Friday, February 08, 2013 09:36:16 PM SM wrote: > Hi Scott, > > At 16:32 08-02-2013, Scott Kitterman wrote: > >OK. I do think it's important that people know to use the ip4: mechansim > >for mapped addresses. How would you word it? > > I'll look up how this is usually handled and sent text. > Thanks, Scott K From spf2@kitterman.com Fri Feb 8 22:43:47 2013 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 2B17421F8B9B for ; Fri, 8 Feb 2013 22:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhHuyZf6wfuQ for ; Fri, 8 Feb 2013 22:43:46 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 64DE821F883B for ; Fri, 8 Feb 2013 22:43:46 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E4D0A20E40C9; Sat, 9 Feb 2013 01:43:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360392225; bh=5M4EQPOtmhqNw3z9to5bDjL9uZPftZxR8jOJU0zqZHM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MAbhISEia+M4Im7mLaYomDIltAx1m7GWvbKTnMK+wh4YHM21/yDnzo6S1PUlkjUWJ NLsB6/S/ejn0DQ7yB+CxCLhpJGakaZCU+sdKpF54IuFLyqtccTBMo9OaIUhCbLGQhk 9OTMOaXccv+o4SfR8FTaB3wfk/oKlxvv2sc6MIR8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CDF0A20E40BE; Sat, 9 Feb 2013 01:43:45 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 09 Feb 2013 01:43:44 -0500 Message-ID: <3722169.rLGDakIFq2@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <3176279.ZD4dlLcq5n@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] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 06:43:47 -0000 On Friday, February 08, 2013 11:20:23 PM Barry Leiba wrote: > >> > What I was trying to communicate there is something like the following > >> > > >> > sequence: > >> > - Do mx lookup for the domain. > >> > - One or more a records returned > >> > - If the number of a records is =< 10, then do a lookups to find the > >> > > >> > relevant IP addresses > >> > > >> > - If the number of a records is > 10, don't do any lookups and return > >> > a > >> > > >> > permerror. > >> > > >> > When I look at it, I think it says that, but obviously it's not clear. > >> > Wording suggestions appreciated. > > ... > > >> Are you trying to limit the total number of lookups in an SPF-record > >> evaluation? Or just the total number from any one clause? > > > > For a single term (clause). > > OK, let's try this: > > OLD > When evaluating the "mx" mechanism, the number of MX resource records > queried MUST NOT exceed 10. If the evaluation of an "mx" mechanism > results in more than 10 A resource records to be queried, the "mx" > mechanism MUST produce a "permerror" result. > > NEW > When evaluating the "mx" mechanism, the number of "MX" resource > records queried MUST NOT exceed 10, and the evaluation of each "MX" > record MUST NOT result in querying more than 10 "A" resource records. > If either of these limits is exceeded, the "mx" mechanism MUST produce a > "permerror" result. > > Does that work? Close. There is an overall limit for mechanisms that cause DNS lookups to 10 of which 'mx' is only one type. You can't have 10 'mx', 10 'a', and 10 'include'. Perhaps: > When evaluating the "mx" mechanism, the number of "MX" resource > records queried is included in the overall limit of 10 mechanisms/ > modifiers the cause DNS look ups described above. The evaluation of each > "MX" record MUST NOT result in querying more than 10 "A" resource > records. If this limit is exceeded, the "mx" mechanism MUST produce a > "permerror" result. How's that? The overall limit of 10 mechansims/modifiers is in the previous paragraph. Scott K From sm@resistor.net Sat Feb 9 02:48:51 2013 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 7814521F87AC for ; Sat, 9 Feb 2013 02:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHNV0P9vAC85 for ; Sat, 9 Feb 2013 02:48:50 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE30921F879D for ; Sat, 9 Feb 2013 02:48:50 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r19AmiFV025234 for ; Sat, 9 Feb 2013 02:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360406929; bh=a5giBSgr+vOzjK7PyGAxN1KZ7flwp0/IdmFKOnZDSME=; h=Date:To:From:Subject:In-Reply-To:References; b=X2lnS2xYkhVK1YAMKp5eXO03uuDIe4EkHtrHzY/X590YgfcIVxuKmNuI1d9pQIWeb B4xEFf9buyHEWolbuRmzOhgF7jUdC/6K5vzOf76fiVxZywU3INyWI5EEoL4yxfsNM1 goLji32xJIYtMG7wSTKei+mHgI/KjdddxNTaeVaA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360406929; i=@resistor.net; bh=a5giBSgr+vOzjK7PyGAxN1KZ7flwp0/IdmFKOnZDSME=; h=Date:To:From:Subject:In-Reply-To:References; b=DeA+qINcSnVgYIQPIDlo+jzs/wVPYPWaNcxOunnR5T9CuqIcH/Y2RG1+Vttk5cBWx Qgg+49gO4LbGOZPeg2PVZDWhXPfrIBiFKLiohGoQvcYzrEC1HCsbxFcR23698lJeyI 3oOVLA8sZYxqdK39oUEddk5hUQfhj2hYDVrROuDs= Message-Id: <6.2.5.6.2.20130209005510.0a9eefd0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 09 Feb 2013 02:28:03 -0800 To: spfbis@ietf.org From: SM In-Reply-To: <3722169.rLGDakIFq2@scott-latitude-e6320> References: <3176279.ZD4dlLcq5n@scott-latitude-e6320> <3722169.rLGDakIFq2@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 10:48:51 -0000 Hello, Section 5 of draft-ietf-spfbis-4408bis-10 has the following: 'When any mechanism fetches host addresses to compare with , when is an IPv4 address, A records are fetched; when is an IPv6 address, AAAA records are fetched. Even if the SMTP connection uses IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) MUST still be considered an IPv4 address and MUST be evaluated using IPv4 mechanisms (i.e. "ip4" and "a").' The requirement is incorrect. I did not understand what "host addresses" means. One of the problems is that the discussion is not about the IP-layer protocol which is used; it is about how IP addresses are handled by an application. One alternative is to drop the paragraph. Another alternative is: Some mechanisms designate IP addresses to be compared against the IP address of the SMTP client; A RRs are fetched if the SMTP client is using IPv4; AAAA RRs are fetched if the SMTP client is using IPv6. Regards, -sm From sm@elandsys.com Sat Feb 9 02:55:37 2013 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 C2CE221F8B8B for ; Sat, 9 Feb 2013 02:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrWl+gmQRTAP for ; Sat, 9 Feb 2013 02:55:37 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2966721F8B81 for ; Sat, 9 Feb 2013 02:55:36 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.154.63]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r19AtJj9002533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Feb 2013 02:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360407331; bh=bYNIUXhr6sbzaXhtlATKMQ2HKPndIYyJxIHdqszvcHM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=K7g+7m+yan+fDdNltLmwSbxZPIpPs7kNxe1DEjfFO4Lui7sSw3yFwF5rpykRdQvCv rS1tzgiTyRyr8OgoeFSYYl/G7JTACPqDzn4BJXgIW4jE5IKqc1UAIDt8uiSYNAftuD r5R3f8j7nFvwp5YK85GBStnRyZFIFQNo6OI/Jzs0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1360407331; i=@elandsys.com; bh=bYNIUXhr6sbzaXhtlATKMQ2HKPndIYyJxIHdqszvcHM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Td5euoYoXGUfnSy6mnndYVX3KmBhFCE7wuRvz9PrJ8+EFqaDUH3VikQpOzeUh/tm4 EGsUw1szUSABhqYgTnicTfvw3yY+l4sPC4ZYvyoT4CzmIhTQrjsE3K/OWqTqhhU5+G Fw6oiDtf1BGg3aI9s8aVtMSEH2rjI+NelzVsH4rg= Message-Id: <6.2.5.6.2.20130208232355.0a7e7b38@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 08 Feb 2013 23:57:00 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <21604708.4WkHlj1qTs@scott-latitude-e6320> <3176279.ZD4dlLcq5n@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Murray S. Kucherawy" Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 10:55:37 -0000 At 20:20 08-02-2013, Barry Leiba wrote: >OK, let's try this: > >OLD > When evaluating the "mx" mechanism, the number of MX resource records > queried MUST NOT exceed 10. If the evaluation of an "mx" mechanism > results in more than 10 A resource records to be queried, the "mx" > mechanism MUST produce a "permerror" result. > >NEW > When evaluating the "mx" mechanism, the number of "MX" resource > records queried MUST NOT exceed 10, and the evaluation of each "MX" > record MUST NOT result in querying more than 10 "A" resource records. > If either of these limits is exceeded, the "mx" mechanism MUST produce a > "permerror" result. > >Does that work? Thanks to Barry Leiba for the review. As background information there was some discussion last year about having DNS lookup limits together ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html ). Section 5.4 of RFC 4408 mentions that: "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." From Section 10.1: "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." The requirements ("MUST", etc.) are confusing. The "new" text mentions "A" RRs. It should also cover "AAAA" RRs. My reading of the rationale is that it is to limit the number of DNS lookups. Wouldn't it be easier to explain this in terms of DNS lookups? The implementation can keep a counter of the number of DNS lookups and the function handling DNS can return the appropriate result (not SPF result). Murray Kucherawy commented on this at http://www.ietf.org/mail-archive/web/spfbis/current/msg03162.html Is the concern the number of DNS lookups or how to prevent a different SPF result from being returned? Regards, S. Moonesamy From vesely@tana.it Sat Feb 9 03:54:06 2013 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 2EF6F21F8BB7 for ; Sat, 9 Feb 2013 03:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.186 X-Spam-Level: X-Spam-Status: No, score=-4.186 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AamseAXo1tCb for ; Sat, 9 Feb 2013 03:54:05 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 27EBC21F8BB9 for ; Sat, 9 Feb 2013 03:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1360410843; bh=7p4VbXLrI1Ty+Qu88452r00y3EiaRXNWTSEXwSc68Hg=; l=1902; h=Date:From:To:References:In-Reply-To; b=ezZTNaEhiXDOfgI6mE1tDQRJmxbR7fKG4Bx+UNHGjaikPd6xOOzdODJ/OmMOHvquE 7U+vnJ59rac3cM/388jtnVizd1m+JjyVeQpq6UJPe//F5BxOflso/fbXbpq2Ri7Tuu QjfYfceQ0fcrGBjQjo1PVX3EYkgW2ZhCWYkIpRUA= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sat, 09 Feb 2013 12:54:03 +0100 id 00000000005DC039.00000000511638DB.0000274C Message-ID: <511638DA.7050508@tana.it> Date: Sat, 09 Feb 2013 12:54:02 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <21604708.4WkHlj1qTs@scott-latitude-e6320> <3176279.ZD4dlLcq5n@scott-latitude-e6320> In-Reply-To: <3176279.ZD4dlLcq5n@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 11:54:06 -0000 On Sat 09/Feb/2013 01:51:23 +0100 Scott Kitterman wrote: > On Friday, February 08, 2013 04:57:05 PM Barry Leiba wrote: >>>> -- Section 4.6.4 -- >>>> In the second paragraph, why are you mixing "MX resource records" in >>>> the first sentence with "A resource records" in the second sentence? >>>> Is this a typo, or intentional? If it's intentional, I would re-word >>>> it, which will probably correct the odd "MUST". >>> >>> When I look at it, I think it says that, but obviously it's not clear. >>> Wording suggestions appreciated. >> >> Right, but you start by talking about how many MX lookups there are. >> What you say in your explanation above is that there's one, and the >> issue is how many A records that expands to. >> >> As written, it seems to say that you can do up to 10 MX lookups, and >> each of those can result in up to 10 A lookups, for a total of 110 DNS >> lookups. Is that what you mean? > > Yes. This is the basis for the infamous 111 DNS lookups. Can't we remove those paragraphs, please? They're just misplaced, and break the One Definition Rule. I'd propose something like: The "mx" and "ptr" mechanisms, and the %{p} macro, are subject to their own limits, as specified in the corresponding sections below, which are in addition to the lookup limits specified in this section. NOTE: The limit for "mx" (Section 5.4) is treated differently from the limit for "ptr" and the %{p} macro (Section 5.5). The reason for that disparity is that the set of and contents of the MX record are under control of the domain owners, while the set of and contents of PTR records are not always delegated and can thus be under control of their network providers. Text like that could replace all of the four central paragraphs of Section 4.6.4. BTW, Section 5.5 should recall that part of it is also valid for the %{p} macro. jm2c From spf2@kitterman.com Sat Feb 9 04:42:31 2013 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 458A821F8A08 for ; Sat, 9 Feb 2013 04:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAYaTrOXABhh for ; Sat, 9 Feb 2013 04:42:30 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7C55321F8A06 for ; Sat, 9 Feb 2013 04:42:30 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 9C676D0408A; Sat, 9 Feb 2013 06:42:29 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360413749; bh=CyxQuoS1fiHVKufHC23hWBWNq+CaWNo4J5C/TqeCKOw=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Ui2Z51/85QmbA7eH4DLGwhd9RsmCC7ILTai4z2Ca1GA5aKVsXIFJ1Kr3AQVOaLphc RuTEDfmOZ7XM1bQLRZ0oFObO0JJ9GCU9D0Oz6rk1z1Kl49/aZhtcTgcakAdYjOK4na 7vSw/Z8Gzn2wTmreHr+N5Rx0y59Nwxy/DYqeb6dM= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 315ABD0405F; Sat, 9 Feb 2013 06:42:28 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130208232355.0a7e7b38@resistor.net> References: <21604708.4WkHlj1qTs@scott-latitude-e6320> <3176279.ZD4dlLcq5n@scott-latitude-e6320> <6.2.5.6.2.20130208232355.0a7e7b38@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 09 Feb 2013 07:42:25 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 12:42:31 -0000 S Moonesamy wrote: >At 20:20 08-02-2013, Barry Leiba wrote: >>OK, let's try this: >> >>OLD >> When evaluating the "mx" mechanism, the number of MX resource >records >> queried MUST NOT exceed 10. If the evaluation of an "mx" >mechanism >> results in more than 10 A resource records to be queried, the "mx" >> mechanism MUST produce a "permerror" result. >> >>NEW >> When evaluating the "mx" mechanism, the number of "MX" resource >> records queried MUST NOT exceed 10, and the evaluation of each >"MX" >> record MUST NOT result in querying more than 10 "A" resource >records. >> If either of these limits is exceeded, the "mx" mechanism MUST >produce a >> "permerror" result. >> >>Does that work? > >Thanks to Barry Leiba for the review. > >As background information there was some discussion last year about >having DNS lookup limits together ( >http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html ). > >Section 5.4 of RFC 4408 mentions that: > > "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." > > From Section 10.1: > >"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." > >The requirements ("MUST", etc.) are confusing. The "new" text >mentions "A" RRs. It should also cover "AAAA" RRs. > >My reading of the rationale is that it is to limit the number of DNS >lookups. Wouldn't it be easier to explain this in terms of DNS >lookups? The implementation can keep a counter of the number of DNS >lookups and the function handling DNS can return the appropriate >result (not SPF result). > >Murray Kucherawy commented on this at >http://www.ietf.org/mail-archive/web/spfbis/current/msg03162.html Is >the concern the number of DNS lookups or how to prevent a different >SPF result from being returned? Not in a way that's backward compatible. Scott K From spf2@kitterman.com Sat Feb 9 04:46:10 2013 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 3E7CF21F8AD4 for ; Sat, 9 Feb 2013 04:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoCMcjfPCe-Z for ; Sat, 9 Feb 2013 04:46:09 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 441FD21F8A0C for ; Sat, 9 Feb 2013 04:46:09 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id C755BD0408A; Sat, 9 Feb 2013 06:46:08 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360413968; bh=1d2uDaW3Fq2O3PxoB9oJWYRXoiMLAtOx8dIav6OmZuc=; h=In-Reply-To:References:Subject:From:Date:To:From; b=ObDCJAhDoLR7jkhXYlwjd1FicrbRITGUkVsXntMBtACK1S0R7KGz+ctIo97PSdFbr ucoeWNhvPV1BAb/hD1/V1El/Ru9pj6N9yfO1Tpn5T+rIp7bIq+gTCSFOEN5UtI/mi0 FdjcN+vqXaD0ndcnHuLTHsm046wP6aDuBQAHQBy0= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6DB3DD0405F; Sat, 9 Feb 2013 06:46:08 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: <511638DA.7050508@tana.it> References: <21604708.4WkHlj1qTs@scott-latitude-e6320> <3176279.ZD4dlLcq5n@scott-latitude-e6320> <511638DA.7050508@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 09 Feb 2013 07:46:04 -0500 To: spfbis@ietf.org Message-ID: <80a07a66-c28d-4bc6-892d-618f9722f239@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 12:46:10 -0000 Alessandro Vesely wrote: >On Sat 09/Feb/2013 01:51:23 +0100 Scott Kitterman wrote: >> On Friday, February 08, 2013 04:57:05 PM Barry Leiba wrote: >>>>> -- Section 4.6.4 -- >>>>> In the second paragraph, why are you mixing "MX resource records" >in >>>>> the first sentence with "A resource records" in the second >sentence? >>>>> Is this a typo, or intentional? If it's intentional, I would >re-word >>>>> it, which will probably correct the odd "MUST". >>>> >>>> When I look at it, I think it says that, but obviously it's not >clear. >>>> Wording suggestions appreciated. >>> >>> Right, but you start by talking about how many MX lookups there are. >>> What you say in your explanation above is that there's one, and the >>> issue is how many A records that expands to. >>> >>> As written, it seems to say that you can do up to 10 MX lookups, and >>> each of those can result in up to 10 A lookups, for a total of 110 >DNS >>> lookups. Is that what you mean? >> >> Yes. This is the basis for the infamous 111 DNS lookups. > >Can't we remove those paragraphs, please? They're just misplaced, and >break the One Definition Rule. I'd propose something like: > > The "mx" and "ptr" mechanisms, and the %{p} macro, are subject to > their own limits, as specified in the corresponding sections below, > which are in addition to the lookup limits specified in this section. > > NOTE: > The limit for "mx" (Section 5.4) is treated differently from the > limit for "ptr" and the %{p} macro (Section 5.5). The reason for > that disparity is that the set of and contents of the MX record > are under control of the domain owners, while the set of and > contents of PTR records are not always delegated and can thus be > under control of their network providers. > >Text like that could replace all of the four central paragraphs of >Section 4.6.4. > >BTW, Section 5.5 should recall that part of it is also valid for the >%{p} macro. > >jm2c We can't organise it like that because they are part of an overall 10 lookuplimit that is not per mechanism. Scott K From barryleiba.mailing.lists@gmail.com Sat Feb 9 06:48:38 2013 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 46C8421F89E5 for ; Sat, 9 Feb 2013 06:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.88 X-Spam-Level: X-Spam-Status: No, score=-102.88 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ET8Eyp-Og-WJ for ; Sat, 9 Feb 2013 06:48:37 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id AE0E121F89E1 for ; Sat, 9 Feb 2013 06:48:37 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id d16so2929359vcd.40 for ; Sat, 09 Feb 2013 06:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JZIN9nXqC9eLIElRG5EFMpB2M/HpU8hxRAMlQJYPqEc=; b=ltTLQw9k8UPcdb4/bC94dKmef5mWseOorgfKcW/M5jwdywHjp2NLrqbT/8MN8oKSCM P8+wN7rtuhIMXtgyG44FZjtHPRikBN0HAiIKrrHOwoStV1CfzdckgGUeUVshC4Nzy/Qc zO426PEdTbhZJuE4h6X0yYKv10kIpdZpGuxwwdBL+y75JyZ+f7Jh+NmhwGUkLPV8EDOH s21byqj0HlTCI5Vuq3dVeuJ8/X3f+M7xIsuSGqY/fCJs1lYD8It4hhSznOeeH8AhcjQv uqKZFWlhHP0euFjHmnMVetEI9YI/hI89roV2Z0jTLlpGmO2DbkhORDQTMB+htPxSFLXp ymog== MIME-Version: 1.0 X-Received: by 10.52.67.133 with SMTP id n5mr9937123vdt.24.1360421317191; Sat, 09 Feb 2013 06:48:37 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Sat, 9 Feb 2013 06:48:36 -0800 (PST) In-Reply-To: <3722169.rLGDakIFq2@scott-latitude-e6320> References: <3176279.ZD4dlLcq5n@scott-latitude-e6320> <3722169.rLGDakIFq2@scott-latitude-e6320> Date: Sat, 9 Feb 2013 09:48:36 -0500 X-Google-Sender-Auth: LKEnJS1vkSARCDcJT1JYElLEbrM Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 14:48:38 -0000 > Close. There is an overall limit for mechanisms that cause DNS lookups to 10 > of which 'mx' is only one type. You can't have 10 'mx', 10 'a', and 10 > 'include'. Perhaps: > >> When evaluating the "mx" mechanism, the number of "MX" resource >> records queried is included in the overall limit of 10 mechanisms/ >> modifiers the cause DNS look ups described above. The evaluation of each >> "MX" record MUST NOT result in querying more than 10 "A" resource >> records. If this limit is exceeded, the "mx" mechanism MUST produce a >> "permerror" result. > > How's that? The overall limit of 10 mechansims/modifiers is in the previous > paragraph. I like that; thanks. b From spf2@kitterman.com Sat Feb 9 07:52:03 2013 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 1F72721F89E9 for ; Sat, 9 Feb 2013 07:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk-hnLw9VO-b for ; Sat, 9 Feb 2013 07:52:02 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5803B21F89E1 for ; Sat, 9 Feb 2013 07:52:02 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 861B820E411A; Sat, 9 Feb 2013 10:52:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360425121; bh=hASxiYVvBI9eM8KN/3dLvIQaWQBMDiZ1pRdyLZfph04=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RdwzdbpaGukDFUVbwm/VbQ4sj7DYCrjW9VzgC67F2Msg/XZ/YKDCf6a1FiojJfhqf 1eSruwMjIO34hhg09VLqOoP7biPvtohDpQk5iL+1wFbjQOUKbZKSYgoOeDPbDtpx94 QiHYnIDYofG+hTmmMoHGq5EUEEJ9kS7KzIqL6S8I= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6452820E4085; Sat, 9 Feb 2013 10:52:01 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 09 Feb 2013 10:51:56 -0500 Message-ID: <5624408.myXgWtMdf7@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130209005510.0a9eefd0@resistor.net> References: <3722169.rLGDakIFq2@scott-latitude-e6320> <6.2.5.6.2.20130209005510.0a9eefd0@resistor.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] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 15:52:03 -0000 On Saturday, February 09, 2013 02:28:03 AM SM wrote: > Hello, > > Section 5 of draft-ietf-spfbis-4408bis-10 has the following: > > 'When any mechanism fetches host addresses to compare with , when > is an IPv4 address, A records are fetched; when is an IPv6 > address, AAAA records are fetched. Even if the SMTP connection uses > IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) > MUST still be considered an IPv4 address and MUST be evaluated using > IPv4 mechanisms (i.e. "ip4" and "a").' > > The requirement is incorrect. I did not understand what "host > addresses" means. One of the problems is that the discussion is not > about the IP-layer protocol which is used; it is about how IP > addresses are handled by an application. One alternative is to drop > the paragraph. > > Another alternative is: > > Some mechanisms designate IP addresses to be compared against the > IP address of the SMTP client; A RRs are fetched if the SMTP client > is using IPv4; AAAA RRs are fetched if the SMTP client is using IPv6. > That rather looses the point about IPv4 mapped addresses. It's in there specifically because people were getting it wrong. I'm happy to word it in a better way, I think we need to be explicit on the subject. Scott K From sm@resistor.net Sat Feb 9 09:03:49 2013 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 DD6C121F8846 for ; Sat, 9 Feb 2013 09:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T73ZQtGovH4z for ; Sat, 9 Feb 2013 09:03:48 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C0321F883B for ; Sat, 9 Feb 2013 09:03:48 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r19H3bNp004258 for ; Sat, 9 Feb 2013 09:03:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360429427; bh=pD/xv4oH2GTLgYdnbxQrUFOdXnRDnLL0jru0xvnODl8=; h=Date:To:From:Subject:In-Reply-To:References; b=ry1YnQ/aLqWjXxcfGyrlLOlD4lhFgtRaesz0Dyy2A92U9kzn/1IQ4rTerguVupLcC IB2OqMakxz0yGdAM5QRBx2LcCRP/Mj4VJkbxwZooInjbpGpBFwAoszacOuRuKIMZgr Lz+Wks4HeqcJMIkVmDOTmhOrFPgjJmiIva56wRoI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360429427; i=@resistor.net; bh=pD/xv4oH2GTLgYdnbxQrUFOdXnRDnLL0jru0xvnODl8=; h=Date:To:From:Subject:In-Reply-To:References; b=lXYjUnO23vSwlPm6aIq6ONS8fIcC7lnWJsJN0FTkcVkFH3r7Gm2nxnSPlXsrJblAt NdpJczGyPnFsOLAj9kV/ZkkPMy9jz5txi+OWHEWJIE0mGhyTPftZkE/EvEHSA47OYG sNPJzQ63B1R+akNEwI4H1B0qMB+g8iktARnmzDKQ= Message-Id: <6.2.5.6.2.20130209081508.0b16eb98@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 09 Feb 2013 08:46:39 -0800 To: spfbis@ietf.org From: SM In-Reply-To: <5624408.myXgWtMdf7@scott-latitude-e6320> References: <3722169.rLGDakIFq2@scott-latitude-e6320> <6.2.5.6.2.20130209005510.0a9eefd0@resistor.net> <5624408.myXgWtMdf7@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 17:03:50 -0000 Hi Scott, At 07:51 09-02-2013, Scott Kitterman wrote: >That rather looses the point about IPv4 mapped addresses. It's in there >specifically because people were getting it wrong. I'm happy to word it in a >better way, I think we need to be explicit on the subject. Ok. I would have missed the issue if Barry Leiba did not comment about that text. I spent some time going through various RFCs related to the subject. I concluded that it was easier to avoid the subject of "IPv4-mapped IPv6 address" as it is not easy to fix. Regards, -sm From spf2@kitterman.com Sat Feb 9 09:07:53 2013 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 43C5D21F85E2 for ; Sat, 9 Feb 2013 09:07:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvTScojt-xNF for ; Sat, 9 Feb 2013 09:07:52 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9A07521F85DA for ; Sat, 9 Feb 2013 09:07:52 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EAA9C20E411A; Sat, 9 Feb 2013 12:07:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360429672; bh=zF2X0xjnfo5IYjq3CFuB6ZoSKy+QiZpVuzOuZUDNCnk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jz7Z7EYL9ZFg9ejs6sx5/MPHLLzqzfZDs52Jdrah76RhHRmemsbid7zhv1yxiqBvq ZlU9iqt0w/dFMgY58fZ41rmm7SszDNz0zuXXt/Nux7UinFL6JlT97q0l3Zfy8Qzy56 WH2Y1hU2O0gS20uV5PHdQjp4qU1e7guywwMbOPA0= Received: from scott-latitude-e6320.localnet (0.sub-70-192-198.myvzw.com [70.192.198.0]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BE90B20E4085; Sat, 9 Feb 2013 12:07:51 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 09 Feb 2013 12:07:50 -0500 Message-ID: <1393849.RHELxDUEac@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130209081508.0b16eb98@resistor.net> References: <5624408.myXgWtMdf7@scott-latitude-e6320> <6.2.5.6.2.20130209081508.0b16eb98@resistor.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] Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 17:07:53 -0000 On Saturday, February 09, 2013 08:46:39 AM SM wrote: > Hi Scott, > > At 07:51 09-02-2013, Scott Kitterman wrote: > >That rather looses the point about IPv4 mapped addresses. It's in there > >specifically because people were getting it wrong. I'm happy to word it in > >a better way, I think we need to be explicit on the subject. > > Ok. > > I would have missed the issue if Barry Leiba did not comment about > that text. I spent some time going through various RFCs related to > the subject. I concluded that it was easier to avoid the subject of > "IPv4-mapped IPv6 address" as it is not easy to fix. I don't think not mentioning it is a good option. I'll figure something out. Scott K From johnl@iecc.com Sat Feb 9 10:05:12 2013 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 53C3A21F87E0 for ; Sat, 9 Feb 2013 10:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.048 X-Spam-Level: X-Spam-Status: No, score=-111.048 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ+fZh0hZ4SX for ; Sat, 9 Feb 2013 10:05:06 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CC89021F87AF for ; Sat, 9 Feb 2013 10:05:05 -0800 (PST) Received: (qmail 83669 invoked from network); 9 Feb 2013 18:05:01 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Feb 2013 18:05:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=51168fcd.xn--3zv.k1302; i=johnl@user.iecc.com; bh=hR4UqbRE8T/U1o/W2SAGBeridNna95zl/Ib+/NkY9ls=; b=OKdbAnokp7/blg1xSTE4VBzE+WFOhTrw10ItjG8tipm9+RtevoSuJf70aFLYnF+dQ0EKkNbLXHg7xxENNZ+QpPGmXkXdSeT2zQFOoBeo1Ub4tRGmfSdpA8hd/lEnAUyVr0O+TEvZBpqwchNlbe5AxiH4DtEIkRYEYFg5h2C8iHs= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=51168fcd.xn--3zv.k1302; olt=johnl@user.iecc.com; bh=hR4UqbRE8T/U1o/W2SAGBeridNna95zl/Ib+/NkY9ls=; b=MTsdiwxQ4VlI5tkx+8nBwfMc3i3XuOSBUJo0lJ6FudzZsRZ1CcmxicUFe3DKUIcBcwXmxztPY9zSe6FUuyM5olVE8BnfFxKs6y/2oCJXVgOLMZ1hvndlNSFAlehpPgMGuZG9jMODj/TV3SE136A0GqZVQeJAtnp+OQNcXvPxUB4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 9 Feb 2013 18:04:39 -0000 Message-ID: <20130209180439.28612.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 18:05:12 -0000 >> "IPv4-mapped IPv6 address" as it is not easy to fix. > >I don't think not mentioning it is a good option. I'll figure something out. Perhaps don't explain them, just mention them, e.g. SPF implementations on IPv6 servers need to handle both AAAA and A records, for clients on IPv4 mapped IPv6 addresses [RFC4291]. If a coder doesn't know enough about IPv6 to know what they are already, we're not going to solve that problem. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From spf2@kitterman.com Sat Feb 9 10:16:58 2013 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 776F321F87EE for ; Sat, 9 Feb 2013 10:16:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEDtv-jF9y9i for ; Sat, 9 Feb 2013 10:16:57 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D014121F84DA for ; Sat, 9 Feb 2013 10:16:57 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0625C20E411A; Sat, 9 Feb 2013 13:16:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360433817; bh=iFkdWiY8kBvsBPNcw+WYmkrMjQhY7OljY2i9KejPmxU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=W9YaS6anYyUs8noUF2L6uH7HZeBlXl7UluQqwLu41nzoqjTUlxwAWjbfGNB/C9W4N HvfMZeoU+tUtOUFodBZRLjprA8QE8Y7KbGRCJ6PlRpqaXg0+PiLw5AvjAcrcLhfzua B2uAMcivu6f+Kh5MSjBgunZSaOmMqa2NshYJy5Lg= Received: from scott-latitude-e6320.localnet (0.sub-70-192-198.myvzw.com [70.192.198.0]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C9D7220E4085; Sat, 9 Feb 2013 13:16:56 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 09 Feb 2013 13:16:51 -0500 Message-ID: <8836998.ABI8ExWKvx@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <20130209180439.28612.qmail@joyce.lan> References: <20130209180439.28612.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 18:16:58 -0000 On Saturday, February 09, 2013 06:04:39 PM John Levine wrote: > >> "IPv4-mapped IPv6 address" as it is not easy to fix. > > > >I don't think not mentioning it is a good option. I'll figure something > >out. > Perhaps don't explain them, just mention them, e.g. > > SPF implementations on IPv6 servers need to handle both AAAA and A > records, for clients on IPv4 mapped IPv6 addresses [RFC4291]. > > If a coder doesn't know enough about IPv6 to know what they are already, > we're not going to solve that problem. For coders writing SPF libraries, I think that's sufficient. Thanks. I lot of people that try to write SPF records for their domains are much less technical (imagine for a moment how much the average non-technical domain owner knows about DNS and then realize half of them know less than that). Most of them don't read RFCs, so maybe it's not important, but perhaps something like: > SPF implementations on IPv6 servers need to handle both AAAA and A > records, for clients on IPv4 mapped IPv6 addresses [RFC4291]. IPv4 IP > addresses are listed an SPF record using the "ip4" mechanism as IPv4 > addresses. Scott K From barryleiba.mailing.lists@gmail.com Sat Feb 9 11:31:19 2013 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 E2B9C21F84E4 for ; Sat, 9 Feb 2013 11:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.89 X-Spam-Level: X-Spam-Status: No, score=-102.89 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPPrRAmVmVRT for ; Sat, 9 Feb 2013 11:31:19 -0800 (PST) Received: from mail-vb0-f52.google.com (mail-vb0-f52.google.com [209.85.212.52]) by ietfa.amsl.com (Postfix) with ESMTP id 587F921F84DA for ; Sat, 9 Feb 2013 11:31:19 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id fa15so2969958vbb.39 for ; Sat, 09 Feb 2013 11:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=vvn9QDAn/eM/kw++yjSCDZ1KCEMfTKCVX+3lUncO1PM=; b=FDrc3KhyVtl2FoJYPNlRwffcP7OZn0GaP7SAAGFoQFwbQhJ1k19CYtm3aAfVa7cH4J xFAkii+Oe6HucHOPSnBiFoyNKNzf7F4Zu1VWQ/Jp5TbHIXqYr6+/VQgzK2CIA+Diu4q1 aJPtSIK0ENNWIH0hOL2K+5wumRPnN4eRZoHhfmcSLsT+pk3oy+W+PsNOz/J7BIjkXVdd QBsqEu3+39Yl7uY2CndrqFFfjoELeazWU1VV2802IR4G3lUPa6g25W7gmfN4/KBOStaw d0d1CTd+W/v39x2cU4ZcDHni3PGd3vHQ4+qs7U+V88K6AIeMf+hwPtWZmoMVhYl2Q+kA fvcQ== MIME-Version: 1.0 X-Received: by 10.52.24.229 with SMTP id x5mr5360268vdf.84.1360438278610; Sat, 09 Feb 2013 11:31:18 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Sat, 9 Feb 2013 11:31:18 -0800 (PST) In-Reply-To: <8836998.ABI8ExWKvx@scott-latitude-e6320> References: <20130209180439.28612.qmail@joyce.lan> <8836998.ABI8ExWKvx@scott-latitude-e6320> Date: Sat, 9 Feb 2013 14:31:18 -0500 X-Google-Sender-Auth: 8rlnZ5KkQvILPJKTHFeUug9pWdg Message-ID: From: Barry Leiba To: "spfbis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 19:31:20 -0000 >> If a coder doesn't know enough about IPv6 to know what they are already, >> we're not going to solve that problem. ... > I lot of people that try to write SPF records for their domains are much less > technical (imagine for a moment how much the average non-technical domain > owner knows about DNS and then realize half of them know less than that). A side note on these comments, which we shouldn't further discuss here (maybe take it to if you like) is that directorate reviewers and other-area ADs often comment on something for which the response is that anyone in the [X] community will understand this, and we don't need to explain it. I have a mixed view of that. On the one hand, no document can explain (nor cite) everything, and there'll always be stuff for which we have to assume knowledge. On the other hand, we all know about plenty of poor implementations done by people who *did not* understand what we assumed they would. This goes to a broader question of how accessible our standards specifications need to be to those who are *not* expert in the technology they're trying to work with. I have it on my list of topics to discuss at this year's IESG "retreat". Back to the real topics at hand.... Barry From sm@resistor.net Sat Feb 9 15:21:34 2013 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 BEC5221F859D for ; Sat, 9 Feb 2013 15:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V37361NsvZW for ; Sat, 9 Feb 2013 15:21:34 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2621221F8581 for ; Sat, 9 Feb 2013 15:21:34 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r19NLRo1015728; Sat, 9 Feb 2013 15:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360452092; bh=WYjsiYX5Ib0qV1ltzX7tbAd6wkpVIvKXC222Ykjsas8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=CGF5X/uwDggEzx5XwVjAZ8mstR79WqaQShUa3IEN6GL+I+Tcy5MfSYWLBInBnohFb SgRZANxcCGxPFDVO8KFzBRZJSvWCWdFLyw2vnkcaj/zDuNB6lofd9QZDTZfYQdxykk QgR/WGrpvQqD8qc2OFOFYzPJ0JTcg5C7aF+++EOU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360452092; i=@resistor.net; bh=WYjsiYX5Ib0qV1ltzX7tbAd6wkpVIvKXC222Ykjsas8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NkjphGq7UYpDe2oLSYnLV/eiWNL3sGWiBoueZpxasLwCVp2tJL0xr5y4QUga0G0Wr VVtAXMqdsKIkoW+Xo1l0Ru+HU5czn/HjVoVVqwUfy0cmQm9ch0vTYYUWRhN/FtKF4k 0ZNyfLsBbQsA1PAQ9eud1NzB3tUVsjWH0cpu6V6o= Message-Id: <6.2.5.6.2.20130209144846.0b0129e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 09 Feb 2013 15:21:22 -0800 To: John Levine From: SM In-Reply-To: <20130209180439.28612.qmail@joyce.lan> References: <20130209180439.28612.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 09 Feb 2013 23:21:34 -0000 Hi John, At 10:04 09-02-2013, John Levine wrote: > >> "IPv4-mapped IPv6 address" as it is not easy to fix. > > > >I don't think not mentioning it is a good option. I'll figure > something out. > >Perhaps don't explain them, just mention them, e.g. > > SPF implementations on IPv6 servers need to handle both AAAA and A records, > for clients on IPv4 mapped IPv6 addresses [RFC4291]. The SPF implementation would have to support IPv6 [1]. A reviewer may ask what the above means. Somebody would then have to explain that. Regards, -sm 1. "v=spf1 ip4:12.22.58.0/26 ip4:64.170.98.0/26 ip4:209.208.19.192/27 ip6:2607:f170:8000:1500::0/64 ip6:2001:1890:123a::0/56 ip6:2001:1890:126c::0/56 -all" From johnl@iecc.com Sat Feb 9 16:55:26 2013 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 AD37721F85E6 for ; Sat, 9 Feb 2013 16:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.065 X-Spam-Level: X-Spam-Status: No, score=-111.065 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlNTnBXSq0zZ for ; Sat, 9 Feb 2013 16:55:26 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CDA4B21F85DB for ; Sat, 9 Feb 2013 16:55:25 -0800 (PST) Received: (qmail 84934 invoked from network); 10 Feb 2013 00:55:24 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Feb 2013 00:55:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5116effc.xn--i8sz2z.k1302; i=johnl@user.iecc.com; bh=AsYd5ymOOXy7zIbdJh/dEEOOmUnaMQSagdDQd9Q32WE=; b=HFq/rlAuGSb0AKQh45No7ljmD17nW0zS8MzL5Xp14i8ZtsvnpSi3b+u0VWjLAGzq3ol+Xfj97qSgsci7dJhvYlPS0c+8RmbagkMeylCR81+fAhx+i+kZlDSEVFp+E0gnSEe8MabuvaXZeCOW4lvuTfrJSopb42T2T712K6zlw1Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5116effc.xn--i8sz2z.k1302; olt=johnl@user.iecc.com; bh=AsYd5ymOOXy7zIbdJh/dEEOOmUnaMQSagdDQd9Q32WE=; b=RBDykHNijpC2k2E2QkVtiMUfup0xV9Hs0h8sIiPNOfGO8WW0x3nFWNOLCA1wGJ8HwR+26sAmVn9vVOVvgm+++KTl3Qeyfy09JJGchmp9uacy+RayIonhQewIdI7xLL47DGZbYilsUpKf7bp3syGdNQjfPN71SSvUYF6rYg8cZDY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 10 Feb 2013 00:55:01 -0000 Message-ID: <20130210005501.30210.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20130209144846.0b0129e0@resistor.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: sm@resistor.net Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 10 Feb 2013 00:55:26 -0000 >>Perhaps don't explain them, just mention them, e.g. >> >> SPF implementations on IPv6 servers need to handle both AAAA and A records, >> for clients on IPv4 mapped IPv6 addresses [RFC4291]. > >The SPF implementation would have to support IPv6 [1]. A reviewer >may ask what the above means. Somebody would then have to explain that. If they do, which I think is unlikely, the answer is "It's part of IPv6 addressing. See the reference." Having actually written IPv6 mail software, I can say it really is something that anyone who programs for IPv6 would know about. It's like writing DNS software and knowing what SRV records are. From spf2@kitterman.com Sat Feb 9 17:11:54 2013 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 A100C21F8421 for ; Sat, 9 Feb 2013 17:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQCWrN6XyMUl for ; Sat, 9 Feb 2013 17:11:54 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id F07C721F841E for ; Sat, 9 Feb 2013 17:11:53 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 30031D0408A; Sat, 9 Feb 2013 19:11:53 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360458713; bh=OZh8pmoeyIjHVm1TkDDLwmibh5SeW9TRCp2l3QVPlGI=; h=In-Reply-To:References:Subject:From:Date:To:From; b=ZUi7qBs+Vh8jIoTW2cpl+6yNf+rQUHJ15sijPmOh+/GE2Nk+WdRiq2I6HEr3L4XRj wphemR/1mO9T+lKwNB0xElEGX8VvqRhwyIpQajPNsjNV3ZnuTRXnRHoSGiVJs0FfcW tSzKa9daPDQNXzZTAssYJRavTfq8WxFN7sQhYQuY= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A40ADD0405F; Sat, 9 Feb 2013 19:11:51 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130209144846.0b0129e0@resistor.net> References: <20130209180439.28612.qmail@joyce.lan> <6.2.5.6.2.20130209144846.0b0129e0@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 09 Feb 2013 20:11:49 -0500 To: spfbis@ietf.org Message-ID: <79175ced-f6cd-42a7-9dee-24a546eeef9a@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 10 Feb 2013 01:11:54 -0000 SM wrote: >Hi John, >At 10:04 09-02-2013, John Levine wrote: >> >> "IPv4-mapped IPv6 address" as it is not easy to fix. >> > >> >I don't think not mentioning it is a good option. I'll figure >> something out. >> >>Perhaps don't explain them, just mention them, e.g. >> >> SPF implementations on IPv6 servers need to handle both AAAA and A >records, >> for clients on IPv4 mapped IPv6 addresses [RFC4291]. > >The SPF implementation would have to support IPv6 [1]. A reviewer >may ask what the above means. Somebody would then have to explain >that. > >Regards, >-sm > >1. "v=spf1 ip4:12.22.58.0/26 ip4:64.170.98.0/26 ip4:209.208.19.192/27 >ip6:2607:f170:8000:1500::0/64 ip6:2001:1890:123a::0/56 >ip6:2001:1890:126c::0/56 -all" IPv6 support isn't optional, so I'm not sure what you mean? Scott K From hsantos@isdg.net Sat Feb 9 17:35:16 2013 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 D66D421F859A for ; Sat, 9 Feb 2013 17:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.827 X-Spam-Level: X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtbNCQzMk21o for ; Sat, 9 Feb 2013 17:35:16 -0800 (PST) Received: from mail.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CCBFC21F88B2 for ; Sat, 9 Feb 2013 17:35:15 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1779; t=1360460107; h=Received:Received: Message-ID:From:To:Subject:Date:Organization:List-ID; bh=n+ZJfM0 3DuvQzc4HhvbwSt5X4hg=; b=PA3SqA57H4OAAq/nUKGxnPim6o4VDAHNc1gKEfl WWRDZuT539wNjqJDkPQpoGGdYuuOXPY6d2sz2hlBBkBwdFvt58hFU1Ua6iUJSHEg JsUeu46LTYLVp3s3fdgL0oLTl6FP3/7nfASwKO9K2NWd6Cz8Bk6nLPn/sQk7+4TD CGJk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 09 Feb 2013 20:35:07 -0500 Received: from main2 ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3596834585.27537.3888; Sat, 09 Feb 2013 20:35:06 -0500 Message-ID: <983049F5325A4B7A8830A7D8F926B60D@addom.santronics.com> From: "Hector Santos" To: "SM" References: <20130209180439.28612.qmail@joyce.lan> <6.2.5.6.2.20130209144846.0b0129e0@resistor.net> Date: Sat, 9 Feb 2013 20:33:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Cc: spfbis@ietf.org Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 10 Feb 2013 01:35:17 -0000 There are two versions of IP6 support at the receiver side. - SPF IP6 syntaxes, directive parsing support, and - A Full implementation with IP6 Stack/Layer support. At the publisher side, it needs to do IP4/IP6 mapping or provide the = policy that will work for either IP4 or IP6 ready receivers. I believe our IP4 only SPF verifier code right now skips over IP6 rules. BIS needs to ready for the spectrum of possible IP4/IP6 interfaces, = including that many still don't a sh-t about IP6. Don't wish people = time enforcing something that is still impractical for many still today. =20 ----- Original Message -----=20 From: "SM" To: "John Levine" Cc: Sent: Saturday, February 09, 2013 6:21 PM Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words > Hi John, > At 10:04 09-02-2013, John Levine wrote: >> >> "IPv4-mapped IPv6 address" as it is not easy to fix. >> > >> >I don't think not mentioning it is a good option. I'll figure=20 >> something out. >> >>Perhaps don't explain them, just mention them, e.g. >> >> SPF implementations on IPv6 servers need to handle both AAAA and A = records, >> for clients on IPv4 mapped IPv6 addresses [RFC4291]. >=20 > The SPF implementation would have to support IPv6 [1]. A reviewer=20 > may ask what the above means. Somebody would then have to explain = that. >=20 > Regards, > -sm >=20 > 1. "v=3Dspf1 ip4:12.22.58.0/26 ip4:64.170.98.0/26 = ip4:209.208.19.192/27=20 > ip6:2607:f170:8000:1500::0/64 ip6:2001:1890:123a::0/56=20 > ip6:2001:1890:126c::0/56 -all" =20 >=20 > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From hsantos@isdg.net Sat Feb 9 17:37:26 2013 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 1BF8C21F857C for ; Sat, 9 Feb 2013 17:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.82 X-Spam-Level: X-Spam-Status: No, score=-101.82 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX6pvS09Vd6g for ; Sat, 9 Feb 2013 17:37:25 -0800 (PST) Received: from mail.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 63B3121F84C9 for ; Sat, 9 Feb 2013 17:37:25 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=789; t=1360460243; h=Received:Received: Message-ID:From:To:Subject:Date:Organization:List-ID; bh=Bnz2y2c I4majR7RIGBjVffoCvrc=; b=qPhv72a64wgvV0YTs3EgE0ilZUxB1dPPOflmBKo TAlenqNoRn17PMPw0cxBycnIEeSbfhBPPydR+kHA78M+vD8Dt+roCdkaL+QKMkBH kLpD6BxanucLoW6SlY35KMDNZMuPVnm7rzvKuhGqlNDwoI2vcxJMW6pRpjHoFb0s Z17E= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 09 Feb 2013 20:37:23 -0500 Received: from main2 ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3596971180.27537.1472; Sat, 09 Feb 2013 20:37:22 -0500 Message-ID: <94C670644D8844E0B11F74C2835538EC@addom.santronics.com> From: "Hector Santos" To: "Scott Kitterman" , References: <20130209180439.28612.qmail@joyce.lan><6.2.5.6.2.20130209144846.0b0129e0@resistor.net> <79175ced-f6cd-42a7-9dee-24a546eeef9a@email.android.com> Date: Sat, 9 Feb 2013 20:35:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4721 Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 10 Feb 2013 01:37:26 -0000 ----- Original Message -----=20 From: "Scott Kitterman" To: Sent: Saturday, February 09, 2013 8:11 PM Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words >>-sm >> >>1. "v=3Dspf1 ip4:12.22.58.0/26 ip4:64.170.98.0/26 = ip4:209.208.19.192/27=20 >>ip6:2607:f170:8000:1500::0/64 ip6:2001:1890:123a::0/56=20 >>ip6:2001:1890:126c::0/56 -all" =20 >=20 > IPv6 support isn't optional, so I'm not sure what you mean?=20 Parsing support is the minimum scott, i.e. so that you don't generate a = PermError, etc. The publisher needs to be told that it can not assume a = IP6 only world. If he has IP6 interest, he needs to be aware of mapping = and IP4 level stacks and the policy should, if possible, reflect it. -- From spf2@kitterman.com Sat Feb 9 20:48:51 2013 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 739B021F8A08 for ; Sat, 9 Feb 2013 20:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OKtZXw72hRo for ; Sat, 9 Feb 2013 20:48:50 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 765D021F88C8 for ; Sat, 9 Feb 2013 20:48:50 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0434F20E40EF; Sat, 9 Feb 2013 23:48:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360471727; bh=2zlbybNLqENEggQrAr7F9+vPCnerD4YZrA0bPhI6pjw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NsZ1HDWff998sv5yeudrO+IwL4D3T9pyTVfjO007D3KgKryk7CSCFucdBU5rLFQHv EIaZKfsuXlGxTbUAClBX2dcZ8CGuo3lPszazWThSHXy2+RIeJwCJeJtiyS5yLV71YM tnPSxFRAf1lJzQDmYvh5XAp64RD86AuU58gA96rc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E28FE20E4085; Sat, 9 Feb 2013 23:48:46 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 09 Feb 2013 23:48:45 -0500 Message-ID: <50414866.zTIuQ6drbJ@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <983049F5325A4B7A8830A7D8F926B60D@addom.santronics.com> References: <20130209180439.28612.qmail@joyce.lan> <6.2.5.6.2.20130209144846.0b0129e0@resistor.net> <983049F5325A4B7A8830A7D8F926B60D@addom.santronics.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 10 Feb 2013 04:48:51 -0000 On Saturday, February 09, 2013 08:33:33 PM Hector Santos wrote: > There are two versions of IP6 support at the receiver side. > > - SPF IP6 syntaxes, directive parsing support, and > - A Full implementation with IP6 Stack/Layer support. > > At the publisher side, it needs to do IP4/IP6 mapping or provide the policy > that will work for either IP4 or IP6 ready receivers. > > I believe our IP4 only SPF verifier code right now skips over IP6 rules. > > BIS needs to ready for the spectrum of possible IP4/IP6 interfaces, > including that many still don't a sh-t about IP6. Don't wish people time > enforcing something that is still impractical for many still today. If you are on an IPv4 only host, you'll never need to match an ip6: mechanism, so no need to worry about it. If you check SPF with a code base that doesn't know about ip6: and AAAA on a host with IPv6 connectivity, you're doomed and there's nothing a specification can do to help you. For specific cases, it may be OK to deploy code that doesn't process the IPv6 related SPF features, but for general purpose systems, you really do need it. Scott K From spf2@kitterman.com Sat Feb 9 20:50:02 2013 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 151F521F8439 for ; Sat, 9 Feb 2013 20:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Muqi16F16Hz for ; Sat, 9 Feb 2013 20:50:01 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 966B921F8419 for ; Sat, 9 Feb 2013 20:50:01 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2733820E40EF; Sat, 9 Feb 2013 23:50:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360471801; bh=FxYJj2wuUHbylQ67q+MP693OZbFdo/Z+wlLVwaH+Jz8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CNeSuSd1AqrtwrevGyBOhIQdvxWLI8WaOVcN80sQpCHfMjLSGuEfjmDTbcK8UcmX8 FgtOu4W7Pj16fh/QW3nTBRqOjJKru0sev+qLT5NBjoAds4cLIW+/sqlVB8VWM02yyS 3D2PcotPB7P3s3jdg76c3jw+khmrs1TUAHijZOZ8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1371820E4085; Sat, 9 Feb 2013 23:50:01 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 09 Feb 2013 23:50 -0500 Message-ID: <1895804.Rp2kUT9VT9@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <94C670644D8844E0B11F74C2835538EC@addom.santronics.com> References: <20130209180439.28612.qmail@joyce.lan> <79175ced-f6cd-42a7-9dee-24a546eeef9a@email.android.com> <94C670644D8844E0B11F74C2835538EC@addom.santronics.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 10 Feb 2013 04:50:02 -0000 On Saturday, February 09, 2013 08:35:49 PM Hector Santos wrote: > ----- Original Message ----- > From: "Scott Kitterman" > To: > Sent: Saturday, February 09, 2013 8:11 PM > Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words > > >>-sm > >> > >>1. "v=spf1 ip4:12.22.58.0/26 ip4:64.170.98.0/26 ip4:209.208.19.192/27 > >>ip6:2607:f170:8000:1500::0/64 ip6:2001:1890:123a::0/56 > >>ip6:2001:1890:126c::0/56 -all" > >> > > IPv6 support isn't optional, so I'm not sure what you mean? > > Parsing support is the minimum scott, i.e. so that you don't generate a > PermError, etc. The publisher needs to be told that it can not assume a IP6 > only world. If he has IP6 interest, he needs to be aware of mapping and IP4 > level stacks and the policy should, if possible, reflect it. I think my proposed language does that. Scott K From spf2@kitterman.com Sat Feb 9 21:35:08 2013 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 EF48721F85B2 for ; Sat, 9 Feb 2013 21:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+W9NNxDMZwN for ; Sat, 9 Feb 2013 21:35:07 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E10A421F857C for ; Sat, 9 Feb 2013 21:35:06 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6CB6120E40EF; Sun, 10 Feb 2013 00:35:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360474506; bh=fUOEMEHIXTm6Q1lI7YFT5wHSuaQZO9BsQTpnAXi5mV0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JZHao1aOs8yzvrVdNhri7TleI6M/FeuwEl5Chy/VqHak+BIQ9wcTzGNyFMx95rK82 tYKg4wJ9a/7TDQ9soAqjuGo/4myEdMaT3EX/uAAX8Ep1sthAdEfVSjRoP5WvBhDZoC fB5Ku+yn7fnxDjGRJTCYXBdkeG1vends4lJXp76w= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4FC7720E4085; Sun, 10 Feb 2013 00:35:05 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 10 Feb 2013 00:35:05 -0500 Message-ID: <5300181.l3Opc6fWii@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <20130208061209.3588.qmail@joyce.lan> References: <20130208061209.3588.qmail@joyce.lan> 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 2.3 - Genesis of 30 days delays? 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, 10 Feb 2013 05:35:08 -0000 On Friday, February 08, 2013 06:12:09 AM John Levine wrote: > >>If you were to characterize the 30 days as a "consensus estimate" or > >>some such regarding a reasonable maximum time one might expect mail > >>to take to be either delivered or returned as undeliverable, it > >>would appear less arbitrary. > > The reality is that we're pulling it out of our rears. > > RFC 5321 says that SMTP deliveries can take five days, and my > understanding has always been that you should be prepared for mail to > trickle in for up to a week. But do we have any idea about the actual > practices of people who do off line SPF verification? Do they wait a > week? A month? A year? > > In DKIM (yes, I know this isn't DKIM) we made a concrete decision that > DKIM isn't for archival verification of messages, it's for checking > messages in transit, and in that way SPF is similar. I would also > remember that SPF records depend on MX, A, and other records that have > their own update schedules. > > My preference would be to point to 5321 for how long a message might > be in transit, and to note that while it's not forbidden to do offline > checks, the closer to the time of receipt you do the checks, the more > likely you are to get the answer that the domain owner intended. OK. Here's what I've committed locally for -11: When changing SPF records, care has to be taken to ensure that there is a transition period so that the old policy remains valid until all legitimate email can reasonably expect to have been checked. discusses how long a message might be in transit. While offline checks are possible, the closer to the original transmission time checks are performed, the more likely they are to get an SPF result that matches the sending ADMD intent at the time the message was sent. Scott K From spf2@kitterman.com Sat Feb 9 21:42:29 2013 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 A330B21F85B2 for ; Sat, 9 Feb 2013 21:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb8ZB3Q4o6-l for ; Sat, 9 Feb 2013 21:42:29 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EB4F421F857C for ; Sat, 9 Feb 2013 21:42:28 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7A5CB20E40EF; Sun, 10 Feb 2013 00:42:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360474948; bh=6E8ooS89sJ63xaLpV3bmbLBjTNHx3FxnFTDM5aHNZiM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Xb7YIRsz12cveaqAr89HmfMTZjiOJ8pA4xrL4guZtDuySraoISQsQefDllNwq/Sdx QuRBd+PHiDJsXEKEPrVxGKTUwrkVs9PnPAyZubcq2iwf88vWMskY3KelBCm+YHI84E s4QAKCRl0iZzj7Qs0C81IFqbopWLH1FVi05xD3po= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5E13B20E4085; Sun, 10 Feb 2013 00:42:28 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 10 Feb 2013 00:42:27 -0500 Message-ID: <4607748.1WhCtPRVne@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <3722169.rLGDakIFq2@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] Revisit: Issue #36: RFC 2119 key words 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, 10 Feb 2013 05:42:29 -0000 On Saturday, February 09, 2013 09:48:36 AM Barry Leiba wrote: > > Close. There is an overall limit for mechanisms that cause DNS lookups to > > 10 of which 'mx' is only one type. You can't have 10 'mx', 10 'a', and > > 10> > > 'include'. Perhaps: > >> When evaluating the "mx" mechanism, the number of "MX" resource > >> records queried is included in the overall limit of 10 mechanisms/ > >> modifiers the cause DNS look ups described above. The evaluation of > >> each > >> "MX" record MUST NOT result in querying more than 10 "A" resource > >> records. If this limit is exceeded, the "mx" mechanism MUST produce a > >> "permerror" result. > > > > How's that? The overall limit of 10 mechansims/modifiers is in the > > previous paragraph. > > I like that; thanks. Thanks. Done locally for -11. Made parallel changes for the PTR processing limit description too. Scott K From spf2@kitterman.com Sat Feb 9 21:52:19 2013 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 C60AF21F861F for ; Sat, 9 Feb 2013 21:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnOyPhwtmm4K for ; Sat, 9 Feb 2013 21:52:18 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 721F721F861B for ; Sat, 9 Feb 2013 21:52:18 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9A9C820E40EF; Sun, 10 Feb 2013 00:52:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360475537; bh=XTTFam8uywpmYPzSaSB0JOPjiSsH5XAEOMMR/fVJ7tI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XLpiURVe5oLJnVfC6NaoLCyYP/4ju/OQo2KcxWEgjmnPRn95lPb/6u2BWCMTA6pHU 5rJfQ7Ep0PdMnfkJFBMPDJXzE0P69yciIdM/5j+YxmmjXPg+YkKmly7N5I/JjU9GX5 9bFw989rrPfSfEPuELPbXyJlnDSJJwWWPahWuYAg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7FFF120E4085; Sun, 10 Feb 2013 00:52:17 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 10 Feb 2013 00:52:16 -0500 Message-ID: <2126524.xnJOuk4gC8@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <8836998.ABI8ExWKvx@scott-latitude-e6320> References: <20130209180439.28612.qmail@joyce.lan> <8836998.ABI8ExWKvx@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] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 10 Feb 2013 05:52:20 -0000 On Saturday, February 09, 2013 01:16:51 PM Scott Kitterman wrote: > On Saturday, February 09, 2013 06:04:39 PM John Levine wrote: > > >> "IPv4-mapped IPv6 address" as it is not easy to fix. > > > > > >I don't think not mentioning it is a good option. I'll figure something > > >out. > > > > Perhaps don't explain them, just mention them, e.g. > > > > SPF implementations on IPv6 servers need to handle both AAAA and A > > > > records, for clients on IPv4 mapped IPv6 addresses [RFC4291]. > > > > If a coder doesn't know enough about IPv6 to know what they are already, > > we're not going to solve that problem. > > For coders writing SPF libraries, I think that's sufficient. Thanks. > > I lot of people that try to write SPF records for their domains are much > less technical (imagine for a moment how much the average non-technical > domain owner knows about DNS and then realize half of them know less than > that). Most of them don't read RFCs, so maybe it's not important, but > perhaps > something like: > > SPF implementations on IPv6 servers need to handle both AAAA and A > > records, for clients on IPv4 mapped IPv6 addresses [RFC4291]. IPv4 IP > > addresses are listed an SPF record using the "ip4" mechanism as IPv4 > > addresses. Here's what I have committed locally for -11: When any mechanism fetches host addresses to compare with <ip>, when <ip> is an IPv4, A records are fetched; when <ip> is an IPv6 address, AAAA records are fetched. SPF implementations on IPv6 servers need to handle both AAAA and A secords, for clients on IPv4 mapped IPv6 addresses . IPv4 <ip> addresses are only listed in an SPF record using the "ip4" mechanism. Scott K From spf2@kitterman.com Sat Feb 9 22:01:10 2013 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 DD46121F8B3A for ; Sat, 9 Feb 2013 22:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAJNF8h0sVBG for ; Sat, 9 Feb 2013 22:01:09 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C94EA21F8995 for ; Sat, 9 Feb 2013 22:01:08 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 42B6620E40EF; Sun, 10 Feb 2013 01:01:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360476068; bh=prGjTpMsce+qlv7WPGNjwLb1p+xE0y6/yZ+PKflqjHo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=L5tF3VyGvneRV6TBJvQQjao7sjMpmCzT59Jfkrf+dVKUIyt0Uerjkem/pe0IxCpdl g3uCPUeVmKvoFVvLZXdm+BcNu4QGDppHNu+vUMacLz4CEDqfuP0vZXrsdotdIvM5zX QyXipQRC9tBWqaWUJu7qQEAqcxR2wW4X5Qk8we/0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2698320E4085; Sun, 10 Feb 2013 01:01:07 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 10 Feb 2013 01:01:07 -0500 Message-ID: <35829026.4Gq1nCp9CX@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <21604708.4WkHlj1qTs@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] Revisit: Issue #36: RFC 2119 key words 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, 10 Feb 2013 06:01:10 -0000 On Friday, February 08, 2013 04:57:05 PM Barry Leiba wrote: > >> -- Section 4.6 -- > >> I don't see what the second paragraph adds to the first, and suggest > >> eliminating it. > > > > That particular text is unchanged from RFC 4408. IIRC, the reason it is > > there was there was some question back in the day about how processing > > should work. As an example: > > > > You get a message from a domain what has this SPF record: > > > > v=spf1 a:relay.example.com foo:bar.example.com -all > > > > This is a syntactically invalid record because there is no mechanism foo. > > The question the second paragraph was meant to address is, "What is the > > correct result for a message from relay.example.com?" It's either pass > > (strict left to right processing) or permerror (all errors must be > > detected). The correct answer is it's a permerror and we want to make > > that clear. > > I think the first paragraph already says what you need. Maybe a small > tweak to it will make you happier: > > OLD > The check_host() function parses and interprets the SPF record to > find a result for the current test. If there are any syntax errors, > check_host() returns immediately with the result "permerror". > > NEW > The check_host() function parses and interprets the SPF record to > find a result for the current test. If there are any syntax errors > anywhere in the record, check_host() returns immediately with the > result "permerror", without further interpretation. > > ...and then remove the second paragraph. Works? Done for -11. > >> -- Section 4.6.4 -- > >> In the second paragraph, why are you mixing "MX resource records" in > >> the first sentence with "A resource records" in the second sentence? > >> Is this a typo, or intentional? If it's intentional, I would re-word > >> it, which will probably correct the odd "MUST". > > > > What I was trying to communicate there is something like the following > > > > sequence: > > - Do mx lookup for the domain. > > - One or more a records returned > > - If the number of a records is =< 10, then do a lookups to find the > > relevant> > > IP addresses > > > > - If the number of a records is > 10, don't do any lookups and return a > > > > permerror. > > > > When I look at it, I think it says that, but obviously it's not clear. > > Wording suggestions appreciated. > > Right, but you start by talking about how many MX lookups there are. > What you say in your explanation above is that there's one, and the > issue is how many A records that expands to. > > As written, it seems to say that you can do up to 10 MX lookups, and > each of those can result in up to 10 A lookups, for a total of 110 DNS > lookups. Is that what you mean? > > Are you trying to limit the total number of lookups in an SPF-record > evaluation? Or just the total number from any one clause? > > Maybe this is enough to help you with wording... or maybe when you > answer the questions above, I can take a stab. Done already, down thread. > >> -- Section 5 -- > >> > >> When any mechanism fetches host addresses to compare with , when > >> is an IPv4 address, A records are fetched; when is an IPv6 > >> address, AAAA records are fetched. Even if the SMTP connection uses > >> IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) > >> MUST still be considered an IPv4 address and MUST be evaluated using > >> IPv4 mechanisms (i.e. "ip4" and "a"). > >> > >> Again, the lack of "MUST" in the first sentence makes the use of it in > >> the second sentence odd. I'd make the "MUST ... be" constructions > >> into "is". > > > > The construction I'm going for here is: > > > > if $CONDITION then MUST $STUFF > > > > It didn't strike me as odd, but I guess it is. Using the IP4: mechanisms > > for IPv4 mapped IPv6 addresses is an interoperability requirement. How > > would you suggest going about it? > > Just as I said: make them "is", and it works. Remember that not all > normative text has to have 2119 key words, and this paragraph strikes > me as an example (and, BTW, I would put the record type names in > quotes; it's not bad for "MX" and "AAAA" to lack them, but "A" without > the quotes looks confusing): > > NEW-1 > When any mechanism fetches host addresses to compare with , when > is an IPv4 address, "A" records are fetched; when is an IPv6 > address, "AAAA" records are fetched. Even if the SMTP connection uses > IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) > is still considered an IPv4 address and is evaluated using IPv4 > mechanisms (i.e. "ip4" and "a"). > > Or better, I think: > > NEW-2 > When any mechanism fetches host addresses to compare with an IPv4 > address, it fetches "A" records; when comparing with an IPv6 address, > it fetches "AAAA" records. Even if the SMTP connection uses IPv6, an > IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) is still > treated as an IPv4 address and is evaluated using IPv4 mechanisms. > > (Modulo your discussion with SM, of course.) Added quotes to the results of the discussion down thread. Scott K From spf2@kitterman.com Sat Feb 9 22:20:15 2013 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 B23D421F85E6 for ; Sat, 9 Feb 2013 22:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgBjg-PYz0Tw for ; Sat, 9 Feb 2013 22:20:15 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C412C21F85C2 for ; Sat, 9 Feb 2013 22:20:14 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 42BAA20E40EF; Sun, 10 Feb 2013 01:20:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360477214; bh=cmXa8BlcLOBfJhWzqzkYeBpm+DyFkPLh5Xk2J8EhU6Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DueAAyPMP5vKK4xJ+hlpMPnstRb5WBRswA8Ezj5vtV53u1twhgKwo1C0C3RMk3IXI 9o7NpZlB50IVP4JcnSTyAcXPREMFVFerff32iuyjutIiLltb9FQYgvP1Dy1iDs6eQJ qJwvK//5OKHFogO7M1dAwCK8aJNilmB0Uu3I2aew= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2A68120E4085; Sun, 10 Feb 2013 01:20:13 -0500 (EST) From: Scott Kitterman To: "spfbis@ietf.org" Date: Sun, 10 Feb 2013 01:20:13 -0500 Message-ID: <6127819.iarSe6GupN@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <4485b963-5b95-4c78-afc5-6f13ec766a35@email.android.com> References: <1878869.epuRBHeDfC@scott-latitude-e6320> <4485b963-5b95-4c78-afc5-6f13ec766a35@email.android.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 10 Feb 2013 06:20:15 -0000 I think the mechanism=value construct is what we should go with as it provides the most information. We end up with: key = "client-ip" / "envelope-from" / "helo" / "problem" / "receiver" / identity / mechanism / name In the ABNF, if I'm reading it right. That is unchanged from RFC 4408, which is good. That some people read it wrong is not good, so I'll add an example. Scott K On Thursday, February 07, 2013 07:26:23 AM Scott Kitterman wrote: > There are non-human consumers of Received-SPF. None that I'm aware of care > about mechanism. > > Scott K > > "Murray S. Kucherawy" wrote: > >It's true that changing this doesn't affect interoperability of policy > >evaluation, but it does affect anything that parses this field one way > >if > >we change it to the other. Consumers of this field are mostly what I'm > >concerned with here. > > > >However, if nobody's heard of something other than humans that eats > >Received-SPF fields, or if those that do exist already agree on how > >it's > >done, then I guess we just come to consensus on which of the two > >syntaxes > >we want and run with it. > > > >-MSK > > > > > >On Tue, Feb 5, 2013 at 10:40 PM, Scott Kitterman > > > >wrote: > >> I think we can pick what we want. Mechanism is there for forensics, > > > >not > > > >> for > >> filtering, so changing it won't affect interoperability. Personally, > > > >I > > > >> think > >> mx=example.com is a lot more useful than mechanism=mx since there may > > > >be > > > >> more > >> than one of a mechanism type in a record, but I'm open to either > > > >approach. > > > >> I > >> > >> do think we should make it clear and then give an example. > >> > >> Scott K > >> > >> On Tuesday, February 05, 2013 10:35:03 PM Murray S. Kucherawy wrote: > >> > That makes it an open topic. Ugly. > >> > > >> > Do we have any indication of a consensus of what various > > > >implementations > > > >> > do? Do we need to undertake such a survey? > >> > > >> > -MSK > >> > > >> > On Tue, Feb 5, 2013 at 10:26 PM, Scott Kitterman > > > > > > > >> wrote: > >> > > I fear not. I looked in the internal pyspf tests and it has > > > >things > > > >> like > >> > >> > > mechanism=mx/24, so at best it's not clear. Mail::SPF seems to > > > >only > > > >> put > >> > >> > > the > >> > > mechanisms in comments and not use this bit of the ABNF. > >> > > > >> > > Unknown is the old name for temperror, so it used to be a valid > > > >result. > > > >> > > Perhaps a copy/paste from an old example. > >> > > > >> > > Scott K > >> > > > >> > > On Tuesday, February 05, 2013 09:57:09 PM Murray S. Kucherawy > > > >wrote: > >> > > > I think the ABNF is correct as-is, but there is no example that > >> > > > >> > > illustrates > >> > > > >> > > > the use of mechanisms within a Received-SPF, which would clear > > > >up the > > > >> > > > confusion. > >> > > > > >> > > > The current ABNF is mean to enable things like: > >> > > > > >> > > > Received-SPF: pass mx=something; a=something; ... > >> > > > > >> > > > So "mechanism" doesn't need to be quoted, because it expands > > > >into > > > >> all of > >> > >> > > > the available mechanism names. What Barry was doing is > > > >assuming one > > > >> > > wants > >> > > > >> > > > to produce: > >> > > > > >> > > > Received-SPF: pass mechanism=mx; ... > >> > > > > >> > > > ...which was not the intention. > >> > > > > >> > > > Does that sound right, Barry? Scott? > >> > > > > >> > > > There is an error in the example upthread though, because it's > >> > > > impossible > >> > > > to generate "Received-SPF: unknown ..." as "unknown" isn't a > > > >valid > > > >> > > > result > >> > > > string. > >> > > > > >> > > > -MSK > >> > > > > >> > > > On Tue, Feb 5, 2013 at 2:50 PM, Scott Kitterman > > > > > > > >> > > wrote: > >> > > > > Need some help with this one: > >> > > > > > >> > > > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/53 > >> > > > > > >> > > > > Message posted by Barry Leiba on 4 Sept 2012: > >> > > > > that was intended to support unknown mechanisms. So, if > > > >you > > > >> had an > >> > >> > > SPF > >> > > > >> > > > > record from draft-mengwong-spf-00: > >> > > > > v=spf1 a mx ptr domainkeys:_dk.%{d} -all > >> > > > > > >> > > > > The Received-SPF header would look like: > >> > > > > Received-SPF: unknown domainkeys=_dk.example.com > >> > > > > > >> > > > > If that's the case, the text needs work to make it clear, > > > >because > > > >> it's > >> > >> > > > > decidedly not. The text below the grammar lists key names and > > > >the > > > >> > > meanings > >> > > > >> > > > > of > >> > > > > the values. "mechanism" is listed as a key name in that text. > > > >So > > > >> > > there's a > >> > > > >> > > > > problem somewhere that needs to be cleared up. > > > >http://www.ietf.org/mail-archive/web/spfbis/current/msg02608.html > > > >> > > > > Downthread from the referenced message, there's a proposed > >> > > > >> > > simplification > >> > > > >> > > > > from > >> > > > > Arthur Thisell, but I think it's based on the (I believe > > > >incorrect) > > > >> > > > > assumption > >> > > > > that mechanism isn't used. > >> > > > > > >> > > > > Suggestions please. > >> > > > > > >> > > > > Scott K > https://www.ietf.org/mailman/listinfo/spfbis From superuser@gmail.com Sat Feb 9 22:29:57 2013 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 6B73121F8445 for ; Sat, 9 Feb 2013 22:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEr2ATPH0Xyw for ; Sat, 9 Feb 2013 22:29:56 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF8E21F8413 for ; Sat, 9 Feb 2013 22:29:48 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id fn15so4061366wgb.32 for ; Sat, 09 Feb 2013 22:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=T+TFveiVpscjOSP60N4kZZSdm42IrBHYxzzkaOU2Jdo=; b=xYB5a+M3I+uHnpSvlHbnR01lyYmRnwJKAqG99oIz/Xqa3gcb324OhfOyxxllvVIpge pv6glsuqHykldlEen68tIhXKbOl3QzFModxFt3gQLREJqVL4Eml8Qc/7FkUoaU67MuFZ drvQ3jsIzUPCwXRrEI2jSmHs0dP3GQvXLpapHpR8kklCADf8YqS6v2aOKx+06JE/eMWk SYoDrvrVQRzaPd+Zg3MpBbtTN6HTrmBGmaXblJiOYAzK6VYwZeiFO8Si9oqri9iAwdi3 HNOeHpE3aVGQALvgjDX9DIpf4cknHPICBpjHsLcs48KR42WlmPSnqnHlOP//DvEB0cHp rnmA== MIME-Version: 1.0 X-Received: by 10.180.101.99 with SMTP id ff3mr9970159wib.21.1360477787570; Sat, 09 Feb 2013 22:29:47 -0800 (PST) Received: by 10.180.164.43 with HTTP; Sat, 9 Feb 2013 22:29:47 -0800 (PST) In-Reply-To: <5300181.l3Opc6fWii@scott-latitude-e6320> References: <20130208061209.3588.qmail@joyce.lan> <5300181.l3Opc6fWii@scott-latitude-e6320> Date: Sat, 9 Feb 2013 22:29:47 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d044280e840c14304d558ebf5 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? 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, 10 Feb 2013 06:29:57 -0000 --f46d044280e840c14304d558ebf5 Content-Type: text/plain; charset=ISO-8859-1 WFM, especially if the reference could include a Section. -MSK On Sat, Feb 9, 2013 at 9:35 PM, Scott Kitterman wrote: > On Friday, February 08, 2013 06:12:09 AM John Levine wrote: > > >>If you were to characterize the 30 days as a "consensus estimate" or > > >>some such regarding a reasonable maximum time one might expect mail > > >>to take to be either delivered or returned as undeliverable, it > > >>would appear less arbitrary. > > > > The reality is that we're pulling it out of our rears. > > > > RFC 5321 says that SMTP deliveries can take five days, and my > > understanding has always been that you should be prepared for mail to > > trickle in for up to a week. But do we have any idea about the actual > > practices of people who do off line SPF verification? Do they wait a > > week? A month? A year? > > > > In DKIM (yes, I know this isn't DKIM) we made a concrete decision that > > DKIM isn't for archival verification of messages, it's for checking > > messages in transit, and in that way SPF is similar. I would also > > remember that SPF records depend on MX, A, and other records that have > > their own update schedules. > > > > My preference would be to point to 5321 for how long a message might > > be in transit, and to note that while it's not forbidden to do offline > > checks, the closer to the time of receipt you do the checks, the more > > likely you are to get the answer that the domain owner intended. > > OK. Here's what I've committed locally for -11: > > When changing SPF records, care has to be taken to ensure that > there > is a transition period so that the old policy remains valid until > all legitimate email can reasonably expect to have been checked. > discusses how long a message might be in > transit. While offline checks are possible, the closer to the > original transmission time checks are performed, the more likely > they > are to get an SPF result that matches the sending ADMD intent at > the > time the message was sent. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d044280e840c14304d558ebf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
WFM, especially if the reference could include a Sect= ion.

-MSK


On Sat, Feb 9, 2013 at 9:35 PM, Scott Kitterman <spf2@= kitterman.com> wrote:
On F= riday, February 08, 2013 06:12:09 AM John Levine wrote:
> >>If you were to characterize the 30 days as a "consensus e= stimate" or
> >>some such regarding a reasonable maximum time one might expect= mail
> >>to take to be either delivered or returned as undeliverable, i= t
> >>would appear less arbitrary.
>
> The reality is that we're pulling it out of our rears.
>
> RFC 5321 says that SMTP deliveries can take five days, and my
> understanding has always been that you should be prepared for mail to<= br> > trickle in for up to a week. =A0But do we have any idea about the actu= al
> practices of people who do off line SPF verification? =A0Do they wait = a
> week? A month? A year?
>
> In DKIM (yes, I know this isn't DKIM) we made a concrete decision = that
> DKIM isn't for archival verification of messages, it's for che= cking
> messages in transit, and in that way SPF is similar. =A0I would also > remember that SPF records depend on MX, A, and other records that have=
> their own update schedules.
>
> My preference would be to point to 5321 for how long a message might > be in transit, and to note that while it's not forbidden to do off= line
> checks, the closer to the time of receipt you do the checks, the more<= br> > likely you are to get the answer that the domain owner intended.

OK. =A0Here's what I've committed locally for -11:

=A0 =A0 =A0 =A0 =A0When changing SPF records, care has to be taken to ensur= e that there
=A0 =A0 =A0 =A0 =A0is a transition period so that the old policy remains va= lid until
=A0 =A0 =A0 =A0 =A0all legitimate email can reasonably expect to have been = checked.
=A0 =A0 =A0 =A0 =A0<xref target=3D"RFC5321"/> discuss= es how long a message might be in
=A0 =A0 =A0 =A0 =A0transit. =A0While offline checks are possible, the close= r to the
=A0 =A0 =A0 =A0 =A0original transmission time checks are performed, the mor= e likely they
=A0 =A0 =A0 =A0 =A0are to get an SPF result that matches the sending ADMD i= ntent at the
=A0 =A0 =A0 =A0 =A0time the message was sent.

Scott K
___________________________________= ____________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--f46d044280e840c14304d558ebf5-- From spf2@kitterman.com Sat Feb 9 22:34:17 2013 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 D179F21F8436 for ; Sat, 9 Feb 2013 22:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9yi7B0N0Rk7 for ; Sat, 9 Feb 2013 22:34:17 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 16B7621F841C for ; Sat, 9 Feb 2013 22:34:17 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9A98A20E40EF; Sun, 10 Feb 2013 01:34:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360478056; bh=datOj1ZhOWvVaSwc3opZ0XKnYb9xCgmhFS3Jnv0csA0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qL8NmSdeuhH+NYutbCclKgVI6yHxdHzllb8C8ZmVvHLi8MUTMd4wniPegmj7ig0rG 4UbFElDHu4CpH+qliau1AITRP+VGkyGgtp9o2HllEdPqfzye8OvrBk2WvLZeG+1Hul Ahq7tgQ1QBj61DQ/2Kj3kobDKsrWioYKuz8rWwc0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7BFAE20E4085; Sun, 10 Feb 2013 01:34:16 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 10 Feb 2013 01:34:15 -0500 Message-ID: <5865986.pjI1Z43sUd@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <2200169.zLyB0fbaOB@scott-latitude-e6320> References: <2200169.zLyB0fbaOB@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] Fwd: Re: Ticket #47 domain-spec 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, 10 Feb 2013 06:34:17 -0000 Here's what I decided to commit locally for -11: > The domain-spec is expanded as per . The > resulting domain name is used for a DNS A RR lookup (even when the > connection type is IPv6). If any A record is returned, this > mechanism matches. I believe that's sufficient. It preserves the normal processing for DNS error to generate a temperror. It's also shorter. Scott K > ---------- Forwarded Message ---------- > > Subject: Re: [spfbis] Ticket #47 domain-spec > Date: Wednesday, February 06, 2013, 12:56:03 AM > From: Stuart Gathman > To: spfbis@ietf.org > CC: spf2@kitterman.com > > Resent because ietf.org is ignoring my emails for some reason (no > confirmation requests sent). > > On 02/05/2013 11:16 PM, Stuart Gathman wrote: > > On 02/05/2013 04:34 PM, Murray S. Kucherawy wrote: > >> Feel free to point me at previous discussion, but why "(even when the > >> connection type is IPv6)"? > > > > Because that is what rfc4408 says. The A and MX mechanisms look for > > A or AAAA RRs depending on the > > connection type. EXISTS, on the other hand, always looks only for A > > records. That was perfectly clear. > > > > The ambiguity is what to do when there is a DNS error. For other > > mechanisms, a temperror would result, and > > lacking any further specification, you could assume the same for > > exists. However EXISTS is special, and given its intended usage, > > a temperror is not as helpful (and maybe you could argue that if the > > DNS service is unavailable, the RR doesn't "exist" - or maybe that the > > record is in a superposition of "exists" and "not exists" until it is > > able to be observed). > > I added a test to the test suite that allows either interpretation for > now. > > After mulling it over, I am on the side of sticking with temperror. > But I won't be alarmed if spfbis decides to go with nomatch. That > would just nudge applications away from advanced filtering (which > typically involve localpart which is problematic in itself), and more > toward logging. > > > ----------------------------------------- > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Sat Feb 9 22:37:47 2013 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 439ED21F84B2 for ; Sat, 9 Feb 2013 22:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAhWB3Vm4GcQ for ; Sat, 9 Feb 2013 22:37:46 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 73D2E21F8477 for ; Sat, 9 Feb 2013 22:37:46 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0433220E40EF; Sun, 10 Feb 2013 01:37:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360478266; bh=tHAmmUjKgqlx7pAn8QDNHu4ImBaP9piuqx7UOWumD8s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=omtMWh4i7WqN15zzYoJcEk5nKHd1K15NBPGFclfLyRXJh4nfmLlFxRT9VG2TgC0iI fbTLkqUxcrZVquQyvkg+V32g9reXUlgnGnhMiDDBZlY2QmvCCblGV67vEXffD98+8d bWzTvMcWsnSb3FX0QEDSZOeA16gT3sjg8GHfe0TQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DEB6420E4085; Sun, 10 Feb 2013 01:37:45 -0500 (EST) From: Scott Kitterman To: "spfbis@ietf.org" Date: Sun, 10 Feb 2013 01:37:45 -0500 Message-ID: <4920831.slHsb6Roqn@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: References: <20130208061209.3588.qmail@joyce.lan> <5300181.l3Opc6fWii@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] Section 2.3 - Genesis of 30 days delays? 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, 10 Feb 2013 06:37:47 -0000 I'm just heading to bed now, so if someone wants to look it up, I'll be glad to include it. Scott K On Saturday, February 09, 2013 10:29:47 PM Murray S. Kucherawy wrote: > WFM, especially if the reference could include a Section. > > -MSK > > On Sat, Feb 9, 2013 at 9:35 PM, Scott Kitterman wrote: > > On Friday, February 08, 2013 06:12:09 AM John Levine wrote: > > > >>If you were to characterize the 30 days as a "consensus estimate" or > > > >>some such regarding a reasonable maximum time one might expect mail > > > >>to take to be either delivered or returned as undeliverable, it > > > >>would appear less arbitrary. > > > > > > The reality is that we're pulling it out of our rears. > > > > > > RFC 5321 says that SMTP deliveries can take five days, and my > > > understanding has always been that you should be prepared for mail to > > > trickle in for up to a week. But do we have any idea about the actual > > > practices of people who do off line SPF verification? Do they wait a > > > week? A month? A year? > > > > > > In DKIM (yes, I know this isn't DKIM) we made a concrete decision that > > > DKIM isn't for archival verification of messages, it's for checking > > > messages in transit, and in that way SPF is similar. I would also > > > remember that SPF records depend on MX, A, and other records that have > > > their own update schedules. > > > > > > My preference would be to point to 5321 for how long a message might > > > be in transit, and to note that while it's not forbidden to do offline > > > checks, the closer to the time of receipt you do the checks, the more > > > likely you are to get the answer that the domain owner intended. > > > > OK. Here's what I've committed locally for -11: > > When changing SPF records, care has to be taken to ensure that > > > > there > > > > is a transition period so that the old policy remains valid until > > all legitimate email can reasonably expect to have been checked. > > discusses how long a message might be in > > transit. While offline checks are possible, the closer to the > > original transmission time checks are performed, the more likely > > > > they > > > > are to get an SPF result that matches the sending ADMD intent at > > > > the > > > > time the message was sent. > > > > Scott K > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From johnl@iecc.com Sat Feb 9 22:50:05 2013 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 8A4D921F848B for ; Sat, 9 Feb 2013 22:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.078 X-Spam-Level: X-Spam-Status: No, score=-111.078 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1f4y+2WqTHY for ; Sat, 9 Feb 2013 22:50:05 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C1CA421F8484 for ; Sat, 9 Feb 2013 22:50:03 -0800 (PST) Received: (qmail 63170 invoked from network); 10 Feb 2013 06:50:03 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Feb 2013 06:50:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5117431b.xn--30v786c.k1302; i=johnl@user.iecc.com; bh=QTw88IZhDpGCloGSG10EALczPvQuGmcznbE+spH2BPY=; b=VM1LYZE6IXHoSqWX73KRp5XAseNRKMPq7QazdzWTjiiLEKyGSPsLNOW7mRmZEvfJ5AUQUKODDDhAcWc5zTnSUha0F8FT2W7w+EUr4w32XmHEOg/Qkca+1Un4OUIJ1JR5QCxdJ4uYBNHp8lpmlevmIdaFJTBOnrcas9awZXetbuk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5117431b.xn--30v786c.k1302; olt=johnl@user.iecc.com; bh=QTw88IZhDpGCloGSG10EALczPvQuGmcznbE+spH2BPY=; b=JpdjD9HGoEUqCgzBnIcUyDUC+tPyJQyuVK5ncaT2sH5pxGF1ySnLKIhPjHrkvfw9HE04AJKWKV2oqCoWxKjUK61VO3uFyQ+6akC/JU0sWaPxMCEPuazg2FhS3D3WXkk4F+t7tEyhpSkoCc3BnYlDeJoXZh7ahV6hcFGsfpC6MlA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 10 Feb 2013 06:49:39 -0000 Message-ID: <20130210064939.32369.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4920831.slHsb6Roqn@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] Section 2.3 - Genesis of 30 days delays? 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, 10 Feb 2013 06:50:05 -0000 In article <4920831.slHsb6Roqn@scott-latitude-e6320> you write: >I'm just heading to bed now, so if someone wants to look it up, I'll be glad >to include it. RFC 5321 sec 4.5.4.1 >> > is a transition period so that the old policy remains valid until >> > all legitimate email can reasonably expect to have been checked. >> > discusses how long a message might be in >> > transit. While offline checks are possible, the closer to the >> > original transmission time checks are performed, the more likely they >> > are to get an SPF result that matches the sending ADMD intent at the >> > time the message was sent. From sm@resistor.net Sun Feb 10 16:11:50 2013 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 360D421F88AC for ; Sun, 10 Feb 2013 16:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8r3niSZUZDQt for ; Sun, 10 Feb 2013 16:11:49 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A1721F886C for ; Sun, 10 Feb 2013 16:11:49 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1B0BeOJ001732 for ; Sun, 10 Feb 2013 16:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360541504; bh=S25lh9XbVHHlYpHOAaztttsrvR++PdFXTvJcSOXwxSM=; h=Date:To:From:Subject:In-Reply-To:References; b=lV+GuUCNbCZQJmpWxDCS3i9oKBOg+dwm6JdWLtv4eE4ua8Y/9j0zO9ui2kTBbY3a0 1DQg4nIdotNzQdriQ09qcWb2uxVsE1Mtqmopegr60K9v4pz0X8q9EgYW7I76Bh7kbl cSLhuLCy10iZmcBo66t+AwSf3M8PSkDsIG1hZWTI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360541504; i=@resistor.net; bh=S25lh9XbVHHlYpHOAaztttsrvR++PdFXTvJcSOXwxSM=; h=Date:To:From:Subject:In-Reply-To:References; b=ZdjQ/L9vGn3l6bcncODR1kak5Fp295livCENGzyY5quCk+AVBcpzrsSP43fZ7T270 ndMB0qdMmBdmIXFnyT2k0ui18EzabiUQ8OHozlxME8/wZlQemhnvErSdyR+38jeIiU KzHdzdxqTM4UTCdOHm/SpU11e6BZVb/sWhG3z858= Message-Id: <6.2.5.6.2.20130210155939.09fba2c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 10 Feb 2013 16:10:59 -0800 To: spfbis@ietf.org From: SM In-Reply-To: <79175ced-f6cd-42a7-9dee-24a546eeef9a@email.android.com> References: <20130209180439.28612.qmail@joyce.lan> <6.2.5.6.2.20130209144846.0b0129e0@resistor.net> <79175ced-f6cd-42a7-9dee-24a546eeef9a@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 11 Feb 2013 00:11:50 -0000 Hi Scott, At 17:11 09-02-2013, Scott Kitterman wrote: >IPv6 support isn't optional, so I'm not sure what you mean? My reading of the text is that there are: (i) SPF implementations on IPv6 servers (ii) SPF implementations not on IPv6 servers Regards, -sm From spf2@kitterman.com Sun Feb 10 18:34:02 2013 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 2C25A21F8551 for ; Sun, 10 Feb 2013 18:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uixyHp52if76 for ; Sun, 10 Feb 2013 18:34:01 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6DE21F86C9 for ; Sun, 10 Feb 2013 18:34:01 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 234E2D04066; Sun, 10 Feb 2013 20:34:00 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360550040; bh=s7ENannJueAI2cntRiedfZLnnGdMVofkC1+0aIrBSkc=; h=In-Reply-To:References:Subject:From:Date:To:From; b=YsRqMOLsVPug8vcAR5dvbJ24vwCgrCoJ8zVQA6l0ktBON5fLFzKsfNVmT/yYbqnXS 7O51vh4VXqEt/wN0JDs2waRU3tg05s2MxSFZp7TXA+EuC7O6SdYmHwstloC1V1+Vtm bqNfh5tSHrUeyEmLDRNkHQ8Tj2hMLeEACj8WQ9F0= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 91ED3D04005; Sun, 10 Feb 2013 20:33:58 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130210155939.09fba2c8@resistor.net> References: <20130209180439.28612.qmail@joyce.lan> <6.2.5.6.2.20130209144846.0b0129e0@resistor.net> <79175ced-f6cd-42a7-9dee-24a546eeef9a@email.android.com> <6.2.5.6.2.20130210155939.09fba2c8@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 10 Feb 2013 21:33:57 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 11 Feb 2013 02:34:02 -0000 SM wrote: >Hi Scott, >At 17:11 09-02-2013, Scott Kitterman wrote: >>IPv6 support isn't optional, so I'm not sure what you mean? > >My reading of the text is that there are: > > (i) SPF implementations on IPv6 servers > (ii) SPF implementations not on IPv6 servers OK. Thanks for the clarification. I think the proposed text I have for -11 addresses both cases. Scott K From spf2@kitterman.com Sun Feb 10 19:04:18 2013 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 1C37B21F86FA for ; Sun, 10 Feb 2013 19:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcNbrbUAF74s for ; Sun, 10 Feb 2013 19:04:17 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC0721F86C9 for ; Sun, 10 Feb 2013 19:04:17 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 88FCE20E4171; Sun, 10 Feb 2013 22:04:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360551856; bh=umoprx/k1BVoSDPixba4K/ZXmgThGzB7eD4mHZXPBGo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IEjq3QaJobF+zG46W0nkMCa6XUoG65/vJG+/V+0TKmLVmccpdWvk1bEIEuaOPQITU u7oENZMjbC4DyZOuZ1EsGP/9uvYvqGqSAWD5JXkNXh7Cy9E0958FkzxiZOvOMxW0uh RV9MMQ/WwHrWDvKsRGHlKr3cQYAb5I4GFD5cHcVA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6C58B20E411E; Sun, 10 Feb 2013 22:04:16 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 10 Feb 2013 22:04:12 -0500 Message-ID: <7867282.UNreJr9TvP@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <20130210064939.32369.qmail@joyce.lan> References: <20130210064939.32369.qmail@joyce.lan> 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 2.3 - Genesis of 30 days delays? 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, 11 Feb 2013 03:04:18 -0000 On Sunday, February 10, 2013 06:49:39 AM John Levine wrote: > sec 4.5.4.1 Thanks. Applied locally for -11. Scott K From vesely@tana.it Mon Feb 11 02:14:09 2013 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 E4F0A21F872E for ; Mon, 11 Feb 2013 02:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fesm-Id27RVg for ; Mon, 11 Feb 2013 02:14:09 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C9B6021F8751 for ; Mon, 11 Feb 2013 02:14:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1360577643; bh=KVGjDZkFXXd8B2Oi8vESkIFqaqECB7RN2TQfdMWG8Kk=; l=760; h=Date:From:To:References:In-Reply-To; b=UEKHCMLXLHWrqK2evf2OgaP7ayDhgTdp/HMTYa1TLut9g/M3Q0WZsbURz++QmWoP7 UXatW1kU+w6c6+lEJJqgU9t0+pgYAswQt/2ijbKbL0fvrGBXIjbpgnIRyocDdO6/n1 EsWl1TsqpGRTIJu6Les6xpV7NV1pr2aWaN5bnemc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 11 Feb 2013 11:14:03 +0100 id 00000000005DC02B.000000005118C46B.00002AD3 Message-ID: <5118C469.90706@tana.it> Date: Mon, 11 Feb 2013 11:14:01 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <21604708.4WkHlj1qTs@scott-latitude-e6320> <35829026.4Gq1nCp9CX@scott-latitude-e6320> In-Reply-To: <35829026.4Gq1nCp9CX@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 11 Feb 2013 10:14:10 -0000 On Sun 10/Feb/2013 07:01:07 +0100 Scott Kitterman wrote: > On Friday, February 08, 2013 04:57:05 PM Barry Leiba wrote: >> [...] >> (and, BTW, I would put the record type names in quotes; it's not >> bad for "MX" and "AAAA" to lack them, but "A" without the quotes >> looks confusing): >> >> When any mechanism fetches a host address to compare with an IPv4 >> address, it fetches "A" record [... >> slightly changed to stress ambiguity] > > Added quotes to the results of the discussion down thread. I'd avoid quoting record types /systematically/: Having "MX" and "mx" for the record type and the mechanism is confusing too. I'd prefer "it fetches a type A record" for the case quoted. Most occurrences are not ambiguous and need no change. From vesely@tana.it Mon Feb 11 02:16:08 2013 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 D111B21F875C for ; Mon, 11 Feb 2013 02:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stpMozAVxf6t for ; Mon, 11 Feb 2013 02:16:08 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D50EB21F86F6 for ; Mon, 11 Feb 2013 02:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1360577766; bh=nc1kFlCK5eHRuhDJlqn15ftmgMkmkmUW67hOJa6+MoU=; l=676; h=Date:From:To:References:In-Reply-To; b=GA1RQrcuNVY1+clt++IO1tburvCmtq6JfXsNpvk1+b6KHQpKmF8omgwwSdbPftMxN xVLJMZkPjRWue5a0xH3+Uq4f8wj7RPDAmxcM389FCBfKlFcAkD7tD4BEpswZPbWvJk eiMW9Ny3wJIbEtyXbq6q86GyAshnHtWfhJkAhgo0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 11 Feb 2013 11:16:06 +0100 id 00000000005DC02B.000000005118C4E6.0000344A Message-ID: <5118C4E6.7010508@tana.it> Date: Mon, 11 Feb 2013 11:16:06 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130209180439.28612.qmail@joyce.lan> <8836998.ABI8ExWKvx@scott-latitude-e6320> <2126524.xnJOuk4gC8@scott-latitude-e6320> In-Reply-To: <2126524.xnJOuk4gC8@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 11 Feb 2013 10:16:08 -0000 On Sun 10/Feb/2013 06:52:16 +0100 Scott Kitterman wrote: > > Here's what I have committed locally for -11: > > When any mechanism fetches host addresses to compare with <ip>, > when <ip> is an IPv4, A records are fetched; when <ip> is an > IPv6 address, AAAA records are fetched. SPF implementations on IPv6 > servers need to handle both AAAA and A secords, for clients on IPv4 > mapped IPv6 addresses . IPv4 <ip> > addresses are only listed in an SPF record using the "ip4" mechanism. Does the last sentence mean that terms like ip6:::ffff:c0.0.2.1 are illegal? What should implementations do when they find one? From spf2@kitterman.com Mon Feb 11 03:23:25 2013 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 0579B21F8788 for ; Mon, 11 Feb 2013 03:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acT4uLeVCkmA for ; Mon, 11 Feb 2013 03:23:24 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 777B121F8786 for ; Mon, 11 Feb 2013 03:23:24 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 14A24D04066; Mon, 11 Feb 2013 05:23:23 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360581803; bh=J5sXGGwTByGC0HmtJ5Alpck/9yADQVVH0TcLRCKue3k=; h=In-Reply-To:References:Subject:From:Date:To:From; b=g/lX0JHOFk8GOn3e9IkRW2NPWqoYiVvXRf3tRLCbGqEA7fW8DkFiSXgLC7WXj9SCa dG+GES2Poi7b2AGfMb2XTx1mXTfoIwVAaplsN1p8PDDEsM1XFyRm06KpRDLJZ0br5h r5wB1f4sZpZnDET+7drYIqDgv2GxfX3NCV1AV/dM= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 96AB7D04005; Mon, 11 Feb 2013 05:23:22 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: <5118C4E6.7010508@tana.it> References: <20130209180439.28612.qmail@joyce.lan> <8836998.ABI8ExWKvx@scott-latitude-e6320> <2126524.xnJOuk4gC8@scott-latitude-e6320> <5118C4E6.7010508@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 11 Feb 2013 06:23:16 -0500 To: spfbis@ietf.org Message-ID: <113b8363-88bd-45a5-a805-64dbce58b0c0@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 11 Feb 2013 11:23:25 -0000 Alessandro Vesely wrote: >On Sun 10/Feb/2013 06:52:16 +0100 Scott Kitterman wrote: >> >> Here's what I have committed locally for -11: >> >> When any mechanism fetches host addresses to compare with ><ip>, >> when <ip> is an IPv4, A records are fetched; when ><ip> is an >> IPv6 address, AAAA records are fetched. SPF implementations on >IPv6 >> servers need to handle both AAAA and A secords, for clients on >IPv4 >> mapped IPv6 addresses . IPv4 ><ip> >> addresses are only listed in an SPF record using the "ip4" >mechanism. > >Does the last sentence mean that terms like ip6:::ffff:c0.0.2.1 are >illegal? What should implementations do when they find one? You can only get connections from valid addresses. If you're getting invalid addresses, it should be dealt with at a lower level. Scott K From superuser@gmail.com Mon Feb 11 07:31:23 2013 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 A2F7621F8922 for ; Mon, 11 Feb 2013 07:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScrbvFmy8Kv2 for ; Mon, 11 Feb 2013 07:31:23 -0800 (PST) Received: from mail-we0-x22f.google.com (we-in-x022f.1e100.net [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E2A2921F8920 for ; Mon, 11 Feb 2013 07:31:22 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id x8so4965658wey.6 for ; Mon, 11 Feb 2013 07:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Z0xDbN5PcRhZ6nPj8SPdqK9w9qFVnZUM/0EHE0jm5Ls=; b=VellzlAKKS73tCqcJE1FAraKu+OUNk6IWo8TJp8TKld5ReJVuTUKgiFsP0yfi34sS9 lXXvf5G5OYYfdWhK6ygl0mA3pAopH7m9PWAfZVhI++ZT7xkKwAHsl5QlJtvLsRKjGITp Jr1tSGTxSnJWW6xlytuu8VTEzwULB2zpCVbIzwhElxBdgYhXjxCVtwbUfXuSm5Ea0V9e L5CnPleTe/Y36sgykCq0T+JilKBIabLlF8JZ/JKkdkSfVtGe5c0X6OfVaiFUpkgt4Ddm 0O/TzP9lgGzGWzckzBny+ljnpiuDxQUCnIWTaA08Apm0o7gGDUJYspeaemDD4ctZ7iTW 7xPg== MIME-Version: 1.0 X-Received: by 10.180.108.3 with SMTP id hg3mr16711080wib.33.1360596682028; Mon, 11 Feb 2013 07:31:22 -0800 (PST) Received: by 10.180.164.43 with HTTP; Mon, 11 Feb 2013 07:31:21 -0800 (PST) In-Reply-To: <5118C469.90706@tana.it> References: <21604708.4WkHlj1qTs@scott-latitude-e6320> <35829026.4Gq1nCp9CX@scott-latitude-e6320> <5118C469.90706@tana.it> Date: Mon, 11 Feb 2013 07:31:21 -0800 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=e89a8f3ba6e3ea355404d57499b2 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Revisit: Issue #36: RFC 2119 key words 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, 11 Feb 2013 15:31:23 -0000 --e89a8f3ba6e3ea355404d57499b2 Content-Type: text/plain; charset=ISO-8859-1 I don't agree that there's any confusion between the record types and the mechanism names. I think the context of use in each case makes that clear. As for quoting, doesn't adding the article (a la: an A record) make that clear as well? -MSK On Mon, Feb 11, 2013 at 2:14 AM, Alessandro Vesely wrote: > On Sun 10/Feb/2013 07:01:07 +0100 Scott Kitterman wrote: > > On Friday, February 08, 2013 04:57:05 PM Barry Leiba wrote: > >> [...] > >> (and, BTW, I would put the record type names in quotes; it's not > >> bad for "MX" and "AAAA" to lack them, but "A" without the quotes > >> looks confusing): > >> > >> When any mechanism fetches a host address to compare with an IPv4 > >> address, it fetches "A" record [... > >> slightly changed to stress ambiguity] > > > > Added quotes to the results of the discussion down thread. > > I'd avoid quoting record types /systematically/: Having "MX" and "mx" > for the record type and the mechanism is confusing too. I'd prefer > "it fetches a type A record" for the case quoted. Most occurrences > are not ambiguous and need no change. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --e89a8f3ba6e3ea355404d57499b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't agree that there's any confusion= between the record types and the mechanism names.=A0 I think the context o= f use in each case makes that clear.

As for quoting, doesn'= ;t adding the article (a la: an A record) make that clear as well?

-MSK


On Mon, Feb 11, 2013 at 2:14 AM, Alessandro Vesely <vesely@tana.it= > wrote:
On Sun 10/Feb/2013 07:01:0= 7 +0100 Scott Kitterman wrote:
> On Friday, February 08, 2013 04:57:05 PM Barry Leiba wrote:
>> [...]
>> (and, BTW, I would put the record type names in = quotes; it's not
>> bad for "MX" and "AAAA" to lack them, but &quo= t;A" without the quotes
>> looks confusing):
>>
>> =A0 =A0When any mechanism fetches a host address to compare = with an IPv4
>> =A0 =A0address, it fetches "A" record [...
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sli= ghtly changed to stress ambiguity]
>
> Added quotes to the results of the discussion down thread.

I'd avoid quoting record types /systematically/: =A0Having "= MX" and "mx"
for the record type and the mechanism is confusing too. =A0I'd prefer "it fetches a type A record" for the case quoted. =A0Most occurre= nces
are not ambiguous and need no change.
___________________________________= ____________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--e89a8f3ba6e3ea355404d57499b2-- From superuser@gmail.com Mon Feb 11 07:33:55 2013 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 DB82121F8920 for ; Mon, 11 Feb 2013 07:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGjbaktPGsMd for ; Mon, 11 Feb 2013 07:33:55 -0800 (PST) Received: from mail-wi0-x229.google.com (wi-in-x0229.1e100.net [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFE921F8887 for ; Mon, 11 Feb 2013 07:33:54 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so3407744wie.4 for ; Mon, 11 Feb 2013 07:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/r2hzJpK861G9W4qkVrgad6b48Vc3HlYdmtHP0IC8gw=; b=O+aue3MdJSKmVqzOO3rTwIMTqBG7Y00MJZGO49DpTMgLplDFYkY/krqPV39HI24f4l /BVRIyuRw642plilouCxUxM8QQxbwhU/S644/itIFsDsqVXeaCQAV/KUbNJDL3bS8NPb qzLXXxjm7fqpKRIu+Tz3SUNNX7wsWbWk2WS1o9F0lYrHdfsl8/7PH0F3ECY7SbYPe2JD TnoifZN/t1PwzBDZm8M9d76egEQSbR8HDSkfZU8ikmyVM0+bKNVWOiTwVrAi+fWyKWQ7 YVSXEdE5ncdchsaEj1xiSRJCcgHYwT32vOVpsakxsieTZvDysVhFY94UxlpiWC11clSK k76Q== MIME-Version: 1.0 X-Received: by 10.180.83.10 with SMTP id m10mr16863073wiy.5.1360596834182; Mon, 11 Feb 2013 07:33:54 -0800 (PST) Received: by 10.180.164.43 with HTTP; Mon, 11 Feb 2013 07:33:54 -0800 (PST) In-Reply-To: <5118C4E6.7010508@tana.it> References: <20130209180439.28612.qmail@joyce.lan> <8836998.ABI8ExWKvx@scott-latitude-e6320> <2126524.xnJOuk4gC8@scott-latitude-e6320> <5118C4E6.7010508@tana.it> Date: Mon, 11 Feb 2013 07:33:54 -0800 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d04428eb6fbe64704d574a2b9 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 11 Feb 2013 15:33:56 -0000 --f46d04428eb6fbe64704d574a2b9 Content-Type: text/plain; charset=ISO-8859-1 I don't think this is a big concern for SPF implementations. That kind of thing is typically passed directly to inet_pton() or such, which implements standards (either published or de facto) for converting between internal integer forms and presentation forms. Relying on them to do the right thing seems fine to me. -MSK On Mon, Feb 11, 2013 at 2:16 AM, Alessandro Vesely wrote: > On Sun 10/Feb/2013 06:52:16 +0100 Scott Kitterman wrote: > > > > Here's what I have committed locally for -11: > > > > When any mechanism fetches host addresses to compare with > <ip>, > > when <ip> is an IPv4, A records are fetched; when <ip> > is an > > IPv6 address, AAAA records are fetched. SPF implementations on > IPv6 > > servers need to handle both AAAA and A secords, for clients on IPv4 > > mapped IPv6 addresses . IPv4 <ip> > > addresses are only listed in an SPF record using the "ip4" > mechanism. > > Does the last sentence mean that terms like ip6:::ffff:c0.0.2.1 are > illegal? What should implementations do when they find one? > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d04428eb6fbe64704d574a2b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't think this is a big concern for SPF imple= mentations.=A0 That kind of thing is typically passed directly to inet_pton= () or such, which implements standards (either published or de facto) for c= onverting between internal integer forms and presentation forms.=A0 Relying= on them to do the right thing seems fine to me.

-MSK


On Mon, Feb 11, 2013 at 2:16 AM, Alessandro Vesely <vesely@tana.it= > wrote:
On Sun 10/Feb/2013 06:52:1= 6 +0100 Scott Kitterman wrote:
>
> Here's what I have committed locally for -11:
>
> =A0 =A0 =A0 When any mechanism fetches host addresses to compare with = &lt;ip&gt;,
> =A0 =A0 =A0 when &lt;ip&gt; is an IPv4, A records are fetched;= when &lt;ip&gt; is an
> =A0 =A0 =A0 IPv6 address, AAAA records are fetched. =A0SPF implementat= ions on IPv6
> =A0 =A0 =A0 servers need to handle both AAAA and A secords, for client= s on IPv4
> =A0 =A0 =A0 mapped IPv6 addresses <xref target=3D"RFC4291"= ;/>. =A0IPv4 &lt;ip&gt;
> =A0 =A0 =A0 addresses are only listed in an SPF record using the "= ;ip4" mechanism.

Does the last sentence mean that terms like ip6:::ffff:c0.0.2.1 are illegal? =A0What should implementations do when they find one?
___________________________________= ____________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--f46d04428eb6fbe64704d574a2b9-- From vesely@tana.it Mon Feb 11 11:55:39 2013 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 E51D521F8835 for ; Mon, 11 Feb 2013 11:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.452 X-Spam-Level: X-Spam-Status: No, score=-4.452 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF50UdCjYfcO for ; Mon, 11 Feb 2013 11:55:38 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C17AE21F85E0 for ; Mon, 11 Feb 2013 11:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1360612536; bh=FVDxD3eOEb31jA2DJndth7J1qH14zKr+DIi5cOOU28k=; l=574; h=Date:From:To:References:In-Reply-To; b=xGmZc1zPVM7APvbI43c/7bZxVFlPK+VfSKFsV4Ump61IUhNvhasNZ6QZlSXRtPeXn oOAwEjZ8+47C7sgvtRmxoYC5/nLwSnAfNmtGyQ/Va5no6/zQ1Jh7Y4QUpHxaThk975 wc4fpoDNnl3UWHs8fsAHYfqECdk2afQ+t9uEIEG0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 11 Feb 2013 20:55:36 +0100 id 00000000005DC03F.0000000051194CB8.00002E55 Message-ID: <51194CB8.7090009@tana.it> Date: Mon, 11 Feb 2013 20:55:36 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130209180439.28612.qmail@joyce.lan> <8836998.ABI8ExWKvx@scott-latitude-e6320> <2126524.xnJOuk4gC8@scott-latitude-e6320> <5118C4E6.7010508@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 11 Feb 2013 19:55:39 -0000 On Mon 11/Feb/2013 16:33:54 +0100 Murray S. Kucherawy wrote: > I don't think this is a big concern for SPF implementations. That > kind of thing is typically passed directly to inet_pton() or such, > which implements standards (either published or de facto) for > converting between internal integer forms and presentation forms. > Relying on them to do the right thing seems fine to me. Probably yes. However, some examples, specially for IPv4-mapped cases, might clarify doubts such as the meaning of: IN TXT "v=spf1 ip4:192.0.2.1 ip6:::ffff:192.0.2.2 -all" From spf2@kitterman.com Mon Feb 11 12:08:26 2013 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 6750D21F8845 for ; Mon, 11 Feb 2013 12:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1vTydm5x6Dt for ; Mon, 11 Feb 2013 12:08:25 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A9D4B21F8844 for ; Mon, 11 Feb 2013 12:08:25 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3317D20E40F9; Mon, 11 Feb 2013 15:08:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360613305; bh=ik0dTspyQ1ax5b0BzgKVKe8h+b/P2uH4neVHL5qdGk4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=INxeD5rWaTz+wxxNqjYWLAyY39aon9/0P8iqMZdd6JZBeJor+eT2xINUvDPlGUgDA cNZ/cNxPraeMIWM3h2/WW6ktlN3O6WrqlLaYuDPN1W1hRPsHjh5TDwfq2PQWIjyZnm 7Vuy+913Ab5EbvblTLc63cconnvwD8enqBFlrEyk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 17A1620E40CD; Mon, 11 Feb 2013 15:08:24 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 11 Feb 2013 15:08:19 -0500 Message-ID: <23875419.a0CbcNxGlO@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <51194CB8.7090009@tana.it> References: <20130209180439.28612.qmail@joyce.lan> <51194CB8.7090009@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] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 11 Feb 2013 20:08:26 -0000 On Monday, February 11, 2013 08:55:36 PM Alessandro Vesely wrote: > On Mon 11/Feb/2013 16:33:54 +0100 Murray S. Kucherawy wrote: > > I don't think this is a big concern for SPF implementations. That > > kind of thing is typically passed directly to inet_pton() or such, > > which implements standards (either published or de facto) for > > converting between internal integer forms and presentation forms. > > Relying on them to do the right thing seems fine to me. > > Probably yes. However, some examples, specially for IPv4-mapped > cases, might clarify doubts such as the meaning of: > > IN TXT "v=spf1 ip4:192.0.2.1 ip6:::ffff:192.0.2.2 -all" I don't think there's any doubt about what those mean. The ip6: mechanism is redundant and shouldn't be in the record. OTOH, it's presence isn't a major problem. Since ip6: requires no DNS lookups, the only effect is a slightly larger record and a few more bits on the wire. Such redundancies should be discourages operationally, but I think the protocol can ignore them. Scott K From SRS0=Ph2PC=MD==stuart@gathman.org Mon Feb 11 13:38:26 2013 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 0A40F21F886C for ; Mon, 11 Feb 2013 13:38:26 -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_84=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vfz9DD87-yO for ; Mon, 11 Feb 2013 13:38:25 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:470:8:488::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE7121F8869 for ; Mon, 11 Feb 2013 13:38:25 -0800 (PST) Authentication-Results: mail.bmsi.com; auth=pass (PLAIN sslbits=256) smtp.auth=stuart 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 r1BLcLGj025804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Feb 2013 16:38:21 -0500 Message-ID: <511964CD.2090801@gathman.org> Date: Mon, 11 Feb 2013 16:38:21 -0500 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <1878869.epuRBHeDfC@scott-latitude-e6320> <4485b963-5b95-4c78-afc5-6f13ec766a35@email.android.com> <6127819.iarSe6GupN@scott-latitude-e6320> In-Reply-To: <6127819.iarSe6GupN@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 11 Feb 2013 21:38:46 -0000 On 02/10/2013 01:20 AM, Scott Kitterman expounded in part: > I think the mechanism=value construct is what we should go with as it provides > the most information. We end up with: > > key = "client-ip" / "envelope-from" / "helo" / > "problem" / "receiver" / identity / > mechanism / name > > In the ABNF, if I'm reading it right. That is unchanged from RFC 4408, which > is good. That some people read it wrong is not good, so I'll add an example. > Well, I am one of those people that read it wrong. Pyspf generates mechanism=mx:example.com, not mx=example.com . I suppose for syntax errors, problem=ip:1.2.3.4 is used rather than mechanism=ip:1.2.3.4 ? Also, pyspf generates identity=mfrom or identity=helo, not mfrom=foo@example.com (which would be redundant with envelope-from=foo@example.com) or helo=mail.example.com (which is also redundant). I assumed "identity" identified which identity was responsible for the result. But that is because "identity" is actually quoted in RFC4408, and the above is wrong/changed! Are we removing x-name for extended keys? From SRS0=Ph2PC=MD==stuart@gathman.org Mon Feb 11 13:50:10 2013 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 0BAC221F87FE for ; Mon, 11 Feb 2013 13:50:10 -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_84=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9FAbnoXcQxm for ; Mon, 11 Feb 2013 13:50:09 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:470:8:488::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3885921F87FD for ; Mon, 11 Feb 2013 13:50:09 -0800 (PST) Authentication-Results: mail.bmsi.com; auth=pass (PLAIN sslbits=256) smtp.auth=stuart 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 r1BLo7bh026249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Feb 2013 16:50:08 -0500 Message-ID: <5119678F.3050702@gathman.org> Date: Mon, 11 Feb 2013 16:50:07 -0500 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <1878869.epuRBHeDfC@scott-latitude-e6320> <4485b963-5b95-4c78-afc5-6f13ec766a35@email.android.com> <6127819.iarSe6GupN@scott-latitude-e6320> <511964CD.2090801@gathman.org> In-Reply-To: <511964CD.2090801@gathman.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 11 Feb 2013 21:50:10 -0000 On 02/11/2013 04:38 PM, Stuart D Gathman expounded in part: > On 02/10/2013 01:20 AM, Scott Kitterman expounded in part: >> I think the mechanism=value construct is what we should go with as it >> provides >> the most information. We end up with: >> >> key = "client-ip" / "envelope-from" / "helo" / >> "problem" / "receiver" / identity / >> mechanism / name >> >> In the ABNF, if I'm reading it right. That is unchanged from RFC >> 4408, which >> is good. That some people read it wrong is not good, so I'll add an >> example. >> > Well, I am one of those people that read it wrong. Pyspf generates > mechanism=mx:example.com, not mx=example.com . I suppose for syntax > errors, problem=ip:1.2.3.4 is used rather than mechanism=ip:1.2.3.4 ? > Also, pyspf generates identity=mfrom or identity=helo, not > mfrom=foo@example.com (which would be redundant with > envelope-from=foo@example.com) or helo=mail.example.com (which is also > redundant). I assumed "identity" identified which identity was > responsible for the result. But that is because "identity" is > actually quoted in RFC4408, and the above is wrong/changed! Are we > removing x-name for extended keys? (Sorry about typos in the above) Given that rfc4408 [7] says, "if no mechanisms matched, substitute the word "default", I think my interpretation is the more reasonable, and "mechanism" should in fact be quoted. Here is a production Received-SPF: Received-SPF: Neutral (mail.bmsi.com: 67.23.163.235 is neither permitted nor denied by domain of dotperfectionprinting.com) client-ip=67.23.163.235; envelope-from="bounce-2703-1431319507-gmeagher=schayer.com@dotperfectionprinting.com"; helo=smtp.dotperfectionprinting.com; receiver=mail.bmsi.com; mechanism=?all; x-helo-spf=neutral; identity=mailfrom If we do what I think people are saying, it would look like this: Received-SPF: Neutral (mail.bmsi.com: 67.23.163.235 is neither permitted nor denied by domain of dotperfectionprinting.com) client-ip=67.23.163.235; envelope-from="bounce-2703-1431319507-gmeagher=schayer.com@dotperfectionprinting.com"; helo=smtp.dotperfectionprinting.com; receiver=mail.bmsi.com; all; x-helo-spf=neutral; identity=mailfrom which is *not* an improvement. I vote that "mechanism" should be quoted in the key list. Is there any existing practice the other way? From spf2@kitterman.com Mon Feb 11 13:53:00 2013 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 2C3DC21F857B for ; Mon, 11 Feb 2013 13:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0c39j5nf93pe for ; Mon, 11 Feb 2013 13:52:57 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 839D721F86BC for ; Mon, 11 Feb 2013 13:52:49 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7C49820E40F9; Mon, 11 Feb 2013 16:52:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360619561; bh=7spcL1VvI0+bPYVr4io9y3zPI/VmzNwV8SYi4XLAY7g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MQZd/5xYPsTbZIu/okwMG/OdErnhfP8aN4pCivhL55I0veanYiumw6xqXpiqLQDbD qbkN9YpzyMW+OVZp05NOBbodoAVs2M6OE6Pvl+OlriCHl3EN/ricq+hWJN11gnQFGn 0dCrDwbQZ5HnxBhlGoGZd2UXgczSjbXQ+2VZmFf0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6120720E40CD; Mon, 11 Feb 2013 16:52:40 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 11 Feb 2013 16:52:40 -0500 Message-ID: <2704652.iOeHp4CxH9@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <511964CD.2090801@gathman.org> References: <1878869.epuRBHeDfC@scott-latitude-e6320> <6127819.iarSe6GupN@scott-latitude-e6320> <511964CD.2090801@gathman.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] Possible ABNF nit with Received-SPF - #53 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, 11 Feb 2013 21:53:00 -0000 On Monday, February 11, 2013 04:38:21 PM Stuart D Gathman wrote: > On 02/10/2013 01:20 AM, Scott Kitterman expounded in part: > > I think the mechanism=value construct is what we should go with as it > > provides the most information. We end up with: > > > > key = "client-ip" / "envelope-from" / "helo" / > > > > "problem" / "receiver" / identity / > > > > mechanism / name > > > > In the ABNF, if I'm reading it right. That is unchanged from RFC 4408, > > which is good. That some people read it wrong is not good, so I'll add > > an example. > Well, I am one of those people that read it wrong. Pyspf generates > mechanism=mx:example.com, not mx=example.com . I suppose for syntax > errors, problem=ip:1.2.3.4 is used rather than mechanism=ip:1.2.3.4 ? > Also, pyspf generates identity=mfrom or identity=helo, not > mfrom=foo@example.com (which would be redundant with > envelope-from=foo@example.com) or helo=mail.example.com (which is also > redundant). I assumed "identity" identified which identity was > responsible for the result. But that is because "identity" is actually > quoted in RFC4408, and the above is wrong/changed! Are we removing > x-name for extended keys? Identity tells you if it was mail from or helo: identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity / name ; other identities It being quoted in 4408 was a bug in the ABNF. It should actually be expanded as listed in the ABNF. We removed any references on X- due to RFC 6648. Scott K From spf2@kitterman.com Mon Feb 11 14:04:11 2013 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 5AB5421F8681 for ; Mon, 11 Feb 2013 14:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=-0.537, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcYy6Fy0lN7G for ; Mon, 11 Feb 2013 14:04:10 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 786CA21F85D0 for ; Mon, 11 Feb 2013 14:04:10 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0148720E40F9; Mon, 11 Feb 2013 17:04:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360620250; bh=mqSkEplvuiBGg1JW95v7Q/2Kvt92/6yZ1o4fN6/vh4Y=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oUYmNZlxWUmHgr8CvumwRleFarv2hxQIdnyMcJ7Rb6zGHdNfSIn971+kTtxixnP1P QpxkUPahEoJYCRXhqr7/NcfDsI91saHTJTVQW804Yc7PA2OBO3cdBlTyPUnQRYex45 wSlEryLk/QZ8Sfgg7bGip+5utQRAfgjAbLcoWxZ4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D6BDD20E40CD; Mon, 11 Feb 2013 17:04:09 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 11 Feb 2013 17:04:09 -0500 Message-ID: <1556459.sPo35TenQf@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <5119678F.3050702@gathman.org> References: <1878869.epuRBHeDfC@scott-latitude-e6320> <511964CD.2090801@gathman.org> <5119678F.3050702@gathman.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] Possible ABNF nit with Received-SPF - #53 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, 11 Feb 2013 22:04:11 -0000 On Monday, February 11, 2013 04:50:07 PM Stuart D Gathman wrote: > On 02/11/2013 04:38 PM, Stuart D Gathman expounded in part: > > On 02/10/2013 01:20 AM, Scott Kitterman expounded in part: > >> I think the mechanism=value construct is what we should go with as it > >> provides > >> the most information. We end up with: > >> > >> key = "client-ip" / "envelope-from" / "helo" / > >> > >> "problem" / "receiver" / identity / > >> > >> mechanism / name > >> > >> In the ABNF, if I'm reading it right. That is unchanged from RFC > >> 4408, which > >> is good. That some people read it wrong is not good, so I'll add an > >> example. > > > > Well, I am one of those people that read it wrong. Pyspf generates > > mechanism=mx:example.com, not mx=example.com . I suppose for syntax > > errors, problem=ip:1.2.3.4 is used rather than mechanism=ip:1.2.3.4 ? > > Also, pyspf generates identity=mfrom or identity=helo, not > > mfrom=foo@example.com (which would be redundant with > > envelope-from=foo@example.com) or helo=mail.example.com (which is also > > redundant). I assumed "identity" identified which identity was > > responsible for the result. But that is because "identity" is > > actually quoted in RFC4408, and the above is wrong/changed! Are we > > removing x-name for extended keys? > > (Sorry about typos in the above) > > Given that rfc4408 [7] says, "if no mechanisms matched, substitute the > word "default", I think my interpretation is the more reasonable, and > "mechanism" should in fact be quoted. > > Here is a production Received-SPF: > > Received-SPF: Neutral (mail.bmsi.com: 67.23.163.235 is neither permitted > nor denied by domain of dotperfectionprinting.com) > client-ip=67.23.163.235; > envelope-from="bounce-2703-1431319507-gmeagher=schayer.com@dotperfectionprin > ting.com"; helo=smtp.dotperfectionprinting.com; receiver=mail.bmsi.com; > mechanism=?all; x-helo-spf=neutral; identity=mailfrom > > If we do what I think people are saying, it would look like this: > > Received-SPF: Neutral (mail.bmsi.com: 67.23.163.235 is neither permitted > nor denied by domain of dotperfectionprinting.com) > client-ip=67.23.163.235; > envelope-from="bounce-2703-1431319507-gmeagher=schayer.com@dotperfectionprin > ting.com"; helo=smtp.dotperfectionprinting.com; receiver=mail.bmsi.com; all; > x-helo-spf=neutral; identity=mailfrom > > which is *not* an improvement. > > I vote that "mechanism" should be quoted in the key list. Is there any > existing practice the other way? I can see your point. The bar "all" isn't very understandable as is. I hadn't thought about the all case when I made my proposal. I had been thinking that in the case of matching a mechanism you'd be trading between something like mechanism=mx and mx=smtp.example.com. I think the latter is more interesting, particularly in the case where there's more than one mechanism of a type in a record (or maybe it matched something from an included record). Is there a better way to present the "all" case than what we have proposed now without losing the added information one gets with a literal interpretation of 4408? We have an ambiguity we have to resolve here and so I think we have some freedom to solve it the 'best' way. Scott K From SRS0=Ph2PC=MD==stuart@gathman.org Mon Feb 11 15:08:56 2013 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 A044021F8856 for ; Mon, 11 Feb 2013 15:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Zw4a3gx+9yz for ; Mon, 11 Feb 2013 15:08:55 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:470:8:488::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA5621F884C for ; Mon, 11 Feb 2013 15:08:55 -0800 (PST) Authentication-Results: mail.bmsi.com; auth=pass (PLAIN sslbits=256) smtp.auth=stuart 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 r1BN8oOY028324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Feb 2013 18:08:52 -0500 Message-ID: <51197A02.2090604@gathman.org> Date: Mon, 11 Feb 2013 18:08:50 -0500 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <1878869.epuRBHeDfC@scott-latitude-e6320> <511964CD.2090801@gathman.org> <5119678F.3050702@gathman.org> <1556459.sPo35TenQf@scott-latitude-e6320> In-Reply-To: <1556459.sPo35TenQf@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 11 Feb 2013 23:08:56 -0000 On 02/11/2013 05:04 PM, Scott Kitterman expounded in part: > On Monday, February 11, 2013 04:50:07 PM Stuart D Gathman wrote: >> On 02/11/2013 04:38 PM, Stuart D Gathman expounded in part: >>> On 02/10/2013 01:20 AM, Scott Kitterman expounded in part: >>>> I think the mechanism=value construct is what we should go with as it >>>> provides >>>> the most information. We end up with: >>>> >>>> key = "client-ip" / "envelope-from" / "helo" / >>>> >>>> "problem" / "receiver" / identity / >>>> >>>> mechanism / name >>>> >>>> In the ABNF, if I'm reading it right. That is unchanged from RFC >>>> 4408, which >>>> is good. That some people read it wrong is not good, so I'll add an >>>> example. >>> Well, I am one of those people that read it wrong. Pyspf generates >>> mechanism=mx:example.com, not mx=example.com . I suppose for syntax >>> errors, problem=ip:1.2.3.4 is used rather than mechanism=ip:1.2.3.4 ? >>> Also, pyspf generates identity=mfrom or identity=helo, not >>> mfrom=foo@example.com (which would be redundant with >>> envelope-from=foo@example.com) or helo=mail.example.com (which is also >>> redundant). I assumed "identity" identified which identity was >>> responsible for the result. But that is because "identity" is >>> actually quoted in RFC4408, and the above is wrong/changed! Are we >>> removing x-name for extended keys? >> (Sorry about typos in the above) >> >> Given that rfc4408 [7] says, "if no mechanisms matched, substitute the >> word "default", I think my interpretation is the more reasonable, and >> "mechanism" should in fact be quoted. >> >> Here is a production Received-SPF: >> >> Received-SPF: Neutral (mail.bmsi.com: 67.23.163.235 is neither permitted >> nor denied by domain of dotperfectionprinting.com) >> client-ip=67.23.163.235; >> envelope-from="bounce-2703-1431319507-gmeagher=schayer.com@dotperfectionprin >> ting.com"; helo=smtp.dotperfectionprinting.com; receiver=mail.bmsi.com; >> mechanism=?all; x-helo-spf=neutral; identity=mailfrom >> >> If we do what I think people are saying, it would look like this: >> >> Received-SPF: Neutral (mail.bmsi.com: 67.23.163.235 is neither permitted >> nor denied by domain of dotperfectionprinting.com) >> client-ip=67.23.163.235; >> envelope-from="bounce-2703-1431319507-gmeagher=schayer.com@dotperfectionprin >> ting.com"; helo=smtp.dotperfectionprinting.com; receiver=mail.bmsi.com; all; >> x-helo-spf=neutral; identity=mailfrom >> >> which is *not* an improvement. >> >> I vote that "mechanism" should be quoted in the key list. Is there any >> existing practice the other way? > I can see your point. The bar "all" isn't very understandable as is. I > hadn't thought about the all case when I made my proposal. I had been > thinking that in the case of matching a mechanism you'd be trading between > something like mechanism=mx and mx=smtp.example.com. I think the latter is > more interesting, particularly in the case where there's more than one > mechanism of a type in a record (or maybe it matched something from an > included record). > > Is there a better way to present the "all" case than what we have proposed now > without losing the added information one gets with a literal interpretation of > 4408? > > We have an ambiguity we have to resolve here and so I think we have some > freedom to solve it the 'best' way. Here is another production example: Received-SPF: Pass (mail.bmsi.com: domain of usexp.bmsi.com designates 50.56.123.192 as permitted sender) client-ip=50.56.123.192; envelope-from="SRS0=ivzp/=MD=usexp2.usexpressfreight.com=bmsadm@usexp.bmsi.com"; helo=fwd1.xif.com; receiver=mail.bmsi.com; mechanism="a:fwd1.xif.com"; identity=mailfrom The full mechanism is included for diagnostic purposes. "Mechanism" should be a literal. From SRS0=Ph2PC=MD==stuart@gathman.org Mon Feb 11 15:12:48 2013 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 63FC321F857C for ; Mon, 11 Feb 2013 15:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJeiDI3NnRSQ for ; Mon, 11 Feb 2013 15:12:47 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:470:8:488::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3F90921F8551 for ; Mon, 11 Feb 2013 15:12:43 -0800 (PST) Authentication-Results: mail.bmsi.com; auth=pass (PLAIN sslbits=256) smtp.auth=stuart 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 r1BNCgVB028363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Feb 2013 18:12:42 -0500 Message-ID: <51197AEA.4050005@gathman.org> Date: Mon, 11 Feb 2013 18:12:42 -0500 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <1878869.epuRBHeDfC@scott-latitude-e6320> <6127819.iarSe6GupN@scott-latitude-e6320> <511964CD.2090801@gathman.org> <2704652.iOeHp4CxH9@scott-latitude-e6320> In-Reply-To: <2704652.iOeHp4CxH9@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 11 Feb 2013 23:12:48 -0000 On 02/11/2013 04:52 PM, Scott Kitterman expounded in part: > > Identity tells you if it was mail from or helo: > > identity = "mailfrom" ; for the "MAIL FROM" identity > / "helo" ; for the "HELO" identity > / name ; other identities > > It being quoted in 4408 was a bug in the ABNF. It should actually be expanded > as listed in the ABNF. > Are you proposing that instead of "identity=mailfrom", R-S should say just "mailfrom" ? That works better than unquoting "mechanism", but I still like the clarity of identity=. From spf2@kitterman.com Mon Feb 11 15:22:13 2013 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 417FE21F8A9B for ; Mon, 11 Feb 2013 15:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgIiiKGOJ6Mi for ; Mon, 11 Feb 2013 15:22:10 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AB73F21F8837 for ; Mon, 11 Feb 2013 15:22:08 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2086020E40F9; Mon, 11 Feb 2013 18:22:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360624928; bh=FuweMI4N9TXztlsuqZ7gmAvpFmQ2zUEkPesBybVmbiM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CpAzK2LTyxeOvMFWIaNafiMCSOf6GtT1zFNUS35VSzbkQCPQ2cNnrZOkWUYjqilLE /2AVLyHzoUyFO8GIdyBDYQhoNTD9SdI/lD9/tfHg5zjWlWjkbYD7ARx3jLhPgD2Cha 0nkJbzYkpZNmSZ6d6/hJy32k97WwW3eFyDsc6Dw8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 031FD20E40CD; Mon, 11 Feb 2013 18:22:07 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 11 Feb 2013 18:22:07 -0500 Message-ID: <1720805.mVGLAte21e@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-23-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <51197A02.2090604@gathman.org> References: <1878869.epuRBHeDfC@scott-latitude-e6320> <1556459.sPo35TenQf@scott-latitude-e6320> <51197A02.2090604@gathman.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] Possible ABNF nit with Received-SPF - #53 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, 11 Feb 2013 23:22:13 -0000 On Monday, February 11, 2013 06:08:50 PM Stuart D Gathman wrote: > On 02/11/2013 05:04 PM, Scott Kitterman expounded in part: > > On Monday, February 11, 2013 04:50:07 PM Stuart D Gathman wrote: > >> On 02/11/2013 04:38 PM, Stuart D Gathman expounded in part: > >>> On 02/10/2013 01:20 AM, Scott Kitterman expounded in part: > >>>> I think the mechanism=value construct is what we should go with as it > >>>> provides > >>>> the most information. We end up with: > >>>> > >>>> key = "client-ip" / "envelope-from" / "helo" / > >>>> > >>>> "problem" / "receiver" / identity / > >>>> > >>>> mechanism / name > >>>> > >>>> In the ABNF, if I'm reading it right. That is unchanged from RFC > >>>> 4408, which > >>>> is good. That some people read it wrong is not good, so I'll add an > >>>> example. > >>> > >>> Well, I am one of those people that read it wrong. Pyspf generates > >>> mechanism=mx:example.com, not mx=example.com . I suppose for syntax > >>> errors, problem=ip:1.2.3.4 is used rather than mechanism=ip:1.2.3.4 ? > >>> Also, pyspf generates identity=mfrom or identity=helo, not > >>> mfrom=foo@example.com (which would be redundant with > >>> envelope-from=foo@example.com) or helo=mail.example.com (which is also > >>> redundant). I assumed "identity" identified which identity was > >>> responsible for the result. But that is because "identity" is > >>> actually quoted in RFC4408, and the above is wrong/changed! Are we > >>> removing x-name for extended keys? > >> > >> (Sorry about typos in the above) > >> > >> Given that rfc4408 [7] says, "if no mechanisms matched, substitute the > >> word "default", I think my interpretation is the more reasonable, and > >> "mechanism" should in fact be quoted. > >> > >> Here is a production Received-SPF: > >> > >> Received-SPF: Neutral (mail.bmsi.com: 67.23.163.235 is neither permitted > >> nor denied by domain of dotperfectionprinting.com) > >> client-ip=67.23.163.235; > >> envelope-from="bounce-2703-1431319507-gmeagher=schayer.com@dotperfectionp > >> rin ting.com"; helo=smtp.dotperfectionprinting.com; > >> receiver=mail.bmsi.com; mechanism=?all; x-helo-spf=neutral; > >> identity=mailfrom > >> > >> If we do what I think people are saying, it would look like this: > >> > >> Received-SPF: Neutral (mail.bmsi.com: 67.23.163.235 is neither permitted > >> nor denied by domain of dotperfectionprinting.com) > >> client-ip=67.23.163.235; > >> envelope-from="bounce-2703-1431319507-gmeagher=schayer.com@dotperfectionp > >> rin ting.com"; helo=smtp.dotperfectionprinting.com; > >> receiver=mail.bmsi.com; all; x-helo-spf=neutral; identity=mailfrom > >> > >> which is *not* an improvement. > >> > >> I vote that "mechanism" should be quoted in the key list. Is there any > >> existing practice the other way? > > > > I can see your point. The bar "all" isn't very understandable as is. I > > hadn't thought about the all case when I made my proposal. I had been > > thinking that in the case of matching a mechanism you'd be trading between > > something like mechanism=mx and mx=smtp.example.com. I think the latter > > is > > more interesting, particularly in the case where there's more than one > > mechanism of a type in a record (or maybe it matched something from an > > included record). > > > > Is there a better way to present the "all" case than what we have proposed > > now without losing the added information one gets with a literal > > interpretation of 4408? > > > > We have an ambiguity we have to resolve here and so I think we have some > > freedom to solve it the 'best' way. > > Here is another production example: > > Received-SPF: Pass (mail.bmsi.com: domain of usexp.bmsi.com designates > 50.56.123.192 as permitted sender) client-ip=50.56.123.192; > envelope-from="SRS0=ivzp/=MD=usexp2.usexpressfreight.com=bmsadm@usexp.bmsi.c > om"; helo=fwd1.xif.com; receiver=mail.bmsi.com; mechanism="a:fwd1.xif.com"; > identity=mailfrom > > The full mechanism is included for diagnostic purposes. > > "Mechanism" should be a literal. OK. I think that clearly either identity or mechanism is wrong in RFC 4408: key = "client-ip" / "envelope-from" / "helo" / "problem" / "receiver" / "identity" / mechanism / "x-" name / name It also seems to me like we ought to take a step back and reconsider which one that is. Scott K From spf2@kitterman.com Mon Feb 11 15:27:02 2013 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 552A221F8AA6 for ; Mon, 11 Feb 2013 15:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DW21GdEENrzj for ; Mon, 11 Feb 2013 15:26:56 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id B299B21F8856 for ; Mon, 11 Feb 2013 15:26:56 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 10BD1956002; Mon, 11 Feb 2013 17:26:56 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1360625216; bh=OOInx7Ktg4ul9a+9SmZEkwSlUO86E/lkZ7SrPbAlpdo=; h=In-Reply-To:References:Subject:From:Date:To:From; b=g/smoivxcHMTE+F1E4b1VN7w063cPn4N1O0laPn9vSM9OieIMJgrOidxUzmAOjhHF BZby4P2qRX4B18N2c+apie77PZ9kUIXIJh/56hwvIPg+Czn3kfqNipD2KT7XliXjmK gx1crAS7s8cI4aREC+7GFoSW4eW9tjTbvIOJpq+U= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C664E956001; Mon, 11 Feb 2013 17:26:55 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: <51197AEA.4050005@gathman.org> References: <1878869.epuRBHeDfC@scott-latitude-e6320> <6127819.iarSe6GupN@scott-latitude-e6320> <511964CD.2090801@gathman.org> <2704652.iOeHp4CxH9@scott-latitude-e6320> <51197AEA.4050005@gathman.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 11 Feb 2013 18:26:53 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 11 Feb 2013 23:27:03 -0000 Stuart D Gathman wrote: >On 02/11/2013 04:52 PM, Scott Kitterman expounded in part: >> >> Identity tells you if it was mail from or helo: >> >> identity = "mailfrom" ; for the "MAIL FROM" identity >> / "helo" ; for the "HELO" identity >> / name ; other identities >> >> It being quoted in 4408 was a bug in the ABNF. It should actually be >expanded >> as listed in the ABNF. >> >Are you proposing that instead of "identity=mailfrom", R-S should say >just "mailfrom" ? That works better than unquoting "mechanism", but I > >still like the clarity of identity=. I liked mailfrom="value", but now I'm not sure. Scott K From srs0=v87x7=me=gathman.org=stuart@fairfax.gathman.org Mon Feb 11 19:07:13 2013 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 5E12B21F8880 for ; Mon, 11 Feb 2013 19:07:13 -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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYqhJgiX1lnF for ; Mon, 11 Feb 2013 19:07:12 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:470:8:488::81]) by ietfa.amsl.com (Postfix) with ESMTP id B827B21F8878 for ; Mon, 11 Feb 2013 19:07:12 -0800 (PST) Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=192.168.10.1 (gathman); auth=pass (PLAIN sslbits=256) smtp.auth=stuart Received: from fairfax.gathman.org (gathman [192.168.10.1]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id r1C36wcQ000406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Feb 2013 22:07:00 -0500 Received: from silver.gathman.org ([192.168.10.211]) (authenticated bits=0) by fairfax.gathman.org (8.14.3/8.14.3) with ESMTP id r1C36pTA012630 for ; Mon, 11 Feb 2013 22:06:58 -0500 Message-ID: <5119B1CB.9040508@gathman.org> Date: Mon, 11 Feb 2013 22:06:51 -0500 From: Stuart Gathman Organization: BWI Corporation User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130209180439.28612.qmail@joyce.lan> <6.2.5.6.2.20130209144846.0b0129e0@resistor.net> <983049F5325A4B7A8830A7D8F926B60D@addom.santronics.com> <50414866.zTIuQ6drbJ@scott-latitude-e6320> In-Reply-To: <50414866.zTIuQ6drbJ@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] ipv6, was Revisit: Issue #36: RFC 2119 key words 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, 12 Feb 2013 03:12:19 -0000 On 02/09/2013 11:48 PM, Scott Kitterman wrote: > On Saturday, February 09, 2013 08:33:33 PM Hector Santos wrote: >> There are two versions of IP6 support at the receiver side. >> >> - SPF IP6 syntaxes, directive parsing support, and >> - A Full implementation with IP6 Stack/Layer support. >> >> At the publisher side, it needs to do IP4/IP6 mapping or provide the policy >> that will work for either IP4 or IP6 ready receivers. >> >> I believe our IP4 only SPF verifier code right now skips over IP6 rules. >> >> BIS needs to ready for the spectrum of possible IP4/IP6 interfaces, >> including that many still don't a sh-t about IP6. Don't wish people time >> enforcing something that is still impractical for many still today. > If you are on an IPv4 only host, you'll never need to match an ip6: mechanism, > so no need to worry about it. If you check SPF with a code base that doesn't > know about ip6: and AAAA on a host with IPv6 connectivity, you're doomed and > there's nothing a specification can do to help you. Actually, even on an IPv4 only host, you have to parse ip6 mechanisms and issue PermError for syntax errors to be compliant. Parsing is just a matter of a regex derived fairly directly from rfc 3986, so it shouldn't be a problem. So for instance, your Ipv4 only implementation is deficient if it fails to issue PermError for: v=spf1 ip6:1234:0 -all From srs0=v87x7=me=gathman.org=stuart@fairfax.gathman.org Mon Feb 11 19:11:02 2013 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 E80C521F88E2 for ; Mon, 11 Feb 2013 19:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPVqm-kP34Am for ; Mon, 11 Feb 2013 19:11:02 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:470:8:488::81]) by ietfa.amsl.com (Postfix) with ESMTP id E754321F88E1 for ; Mon, 11 Feb 2013 19:11:01 -0800 (PST) Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=192.168.10.1 (gathman); auth=pass (PLAIN sslbits=256) smtp.auth=stuart Received: from fairfax.gathman.org (gathman [192.168.10.1]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id r1C3B0nL000479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Feb 2013 22:11:01 -0500 Received: from silver.gathman.org ([192.168.10.211]) (authenticated bits=0) by fairfax.gathman.org (8.14.3/8.14.3) with ESMTP id r1C3B0WP012862 for ; Mon, 11 Feb 2013 22:11:00 -0500 Message-ID: <5119B2C4.7060904@gathman.org> Date: Mon, 11 Feb 2013 22:11:00 -0500 From: Stuart Gathman Organization: BWI Corporation User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <1878869.epuRBHeDfC@scott-latitude-e6320> <6127819.iarSe6GupN@scott-latitude-e6320> <511964CD.2090801@gathman.org> <2704652.iOeHp4CxH9@scott-latitude-e6320> <51197AEA.4050005@gathman.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 12 Feb 2013 03:12:37 -0000 On 02/11/2013 06:26 PM, Scott Kitterman wrote: > > Stuart D Gathman wrote: > >> On 02/11/2013 04:52 PM, Scott Kitterman expounded in part: >>> Identity tells you if it was mail from or helo: >>> >>> identity = "mailfrom" ; for the "MAIL FROM" identity >>> / "helo" ; for the "HELO" identity >>> / name ; other identities >>> >>> It being quoted in 4408 was a bug in the ABNF. It should actually be >> expanded >>> as listed in the ABNF. >>> >> Are you proposing that instead of "identity=mailfrom", R-S should say >> just "mailfrom" ? That works better than unquoting "mechanism", but I >> >> still like the clarity of identity=. > I liked mailfrom="value", but now I'm not sure. > That is already covered by envelope-from="value". Your choices are identity=mailfrom or just mailfrom (if identity should not have been quoted). From vesely@tana.it Tue Feb 12 03:40:04 2013 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 725B121F8CE3 for ; Tue, 12 Feb 2013 03:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.49 X-Spam-Level: X-Spam-Status: No, score=-4.49 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62p3ees5itIh for ; Tue, 12 Feb 2013 03:40:04 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C8A7721F8D0E for ; Tue, 12 Feb 2013 03:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1360669198; bh=JLLfwX9t4980/7+G7OAhvDvjoL62/lqofU3TJWTyMmY=; l=657; h=Date:From:To:References:In-Reply-To; b=sHjdFPv27mZZYCLBtLQ7qy9AlDUOnAA0N2C0+D+RnT+3njDbeNjDg/IJPXkFvX6va pSQIj1bOOsi3Kx4bknQHxGPaM0RmTHG1eK6sXlEAjMI8Fe7R+EIygwTqdapmrNXCNy ToqwJNWm/ZlRgAFjzPCnlgbJWio47iQbAHuMVIJs= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Tue, 12 Feb 2013 12:39:58 +0100 id 00000000005DC035.00000000511A2A0E.00003965 Message-ID: <511A2A0E.6010306@tana.it> Date: Tue, 12 Feb 2013 12:39:58 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <1878869.epuRBHeDfC@scott-latitude-e6320> <511964CD.2090801@gathman.org> <5119678F.3050702@gathman.org> <1556459.sPo35TenQf@scott-latitude-e6320> In-Reply-To: <1556459.sPo35TenQf@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 12 Feb 2013 11:40:04 -0000 On Mon 11/Feb/2013 23:04:09 +0100 Scott Kitterman wrote: > On Monday, February 11, 2013 04:50:07 PM Stuart D Gathman wrote: >> Here is a production Received-SPF: >> >> Received-SPF: [...]; mechanism=?all; [...] >> >> If we do what I think people are saying, it would look like this: >> >> Received-SPF: [...]; all; [...] >> >> which is *not* an improvement. > > Is there a better way to present the "all" case than what we have proposed now > without losing the added information one gets with a literal interpretation of > 4408? How about: "mechanism" / mechanism ? At least, that can stimulate some readers to think about it :-) From vesely@tana.it Tue Feb 12 06:48:34 2013 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 88FCA21F8DAE for ; Tue, 12 Feb 2013 06:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7aYxEHOgcDG for ; Tue, 12 Feb 2013 06:48:34 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0F921F8CEA for ; Tue, 12 Feb 2013 06:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1360680511; bh=CvLnvn8QsTbVlhJaSt8J2nIEUI8GtVhRsbdwi0wzL/s=; l=579; h=Date:From:To:References:In-Reply-To; b=iQ4ZLVNbqEvoIpDxHHnoQ+WR7YBIdpzlef+ag5jM5gk1VczZ8SqBYI1vsNE/3jOMi 7cp62wEblqGJzOLHWtslBetGHROyYKCG/8BZnH/oNd0up4xbQmZMFMSmTSTCWDlXae gNz7xeYczV/PfOTQkbyTKhhIiXBH7Wm0mtHlHgf0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Tue, 12 Feb 2013 15:48:31 +0100 id 00000000005DC039.00000000511A563F.00002401 Message-ID: <511A563F.5050900@tana.it> Date: Tue, 12 Feb 2013 15:48:31 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130209180439.28612.qmail@joyce.lan> <6.2.5.6.2.20130209144846.0b0129e0@resistor.net> <983049F5325A4B7A8830A7D8F926B60D@addom.santronics.com> <50414866.zTIuQ6drbJ@scott-latitude-e6320> <5119B1CB.9040508@gathman.org> In-Reply-To: <5119B1CB.9040508@gathman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] Production rules, was ipv6 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, 12 Feb 2013 14:48:34 -0000 On Tue 12/Feb/2013 04:06:51 +0100 Stuart Gathman wrote: > Actually, even on an IPv4 only host, you have to parse ip6 mechanisms > and issue PermError for syntax errors to be compliant. Parsing is just > a matter of a regex derived fairly directly from rfc 3986, so it > shouldn't be a problem. Hey, in Section 3.2.2 of RFC 3986 are the production rules "we didn't find [it] in 2005", as Scott replied to Murray in July (find qnum in: http://www.ietf.org/mail-archive/web/spfbis/current/msg01842.html ) We can import IPv6address and IPv4address from there, can't we? From SRS0=v87x7=ME==stuart@gathman.org Tue Feb 12 09:38:20 2013 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 D65AC21F8EB7 for ; Tue, 12 Feb 2013 09:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tAQpPTeQz+2 for ; Tue, 12 Feb 2013 09:38:20 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:470:8:488::81]) by ietfa.amsl.com (Postfix) with ESMTP id 409AF21F8EB5 for ; Tue, 12 Feb 2013 09:38:20 -0800 (PST) Authentication-Results: mail.bmsi.com; auth=pass (PLAIN sslbits=256) smtp.auth=stuart 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 r1CHcIIK016979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Feb 2013 12:38:19 -0500 Message-ID: <511A7E0A.5060002@gathman.org> Date: Tue, 12 Feb 2013 12:38:18 -0500 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <1878869.epuRBHeDfC@scott-latitude-e6320> <511964CD.2090801@gathman.org> <5119678F.3050702@gathman.org> <1556459.sPo35TenQf@scott-latitude-e6320> <511A2A0E.6010306@tana.it> In-Reply-To: <511A2A0E.6010306@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 12 Feb 2013 17:57:03 -0000 On 02/12/2013 06:39 AM, Alessandro Vesely expounded in part: > On Mon 11/Feb/2013 23:04:09 +0100 Scott Kitterman wrote: >> On Monday, February 11, 2013 04:50:07 PM Stuart D Gathman wrote: >>> Here is a production Received-SPF: >>> >>> Received-SPF: [...]; mechanism=?all; [...] >>> >>> If we do what I think people are saying, it would look like this: >>> >>> Received-SPF: [...]; all; [...] >>> >>> which is *not* an improvement. >> Is there a better way to present the "all" case than what we have proposed now >> without losing the added information one gets with a literal interpretation of >> 4408? > How about: > > "mechanism" / mechanism > ? > > At least, that can stimulate some readers to think about it :-) Then what do you do with -mx/24 ? (emails are *not* sent from the MXes or their subnet for this domain) Received-SPF: [...]; mx="-/24'; [...] or Received-SPF: [...]; "-mx/24"; [...] Look, "mechanism" is quoted, it is *supposed* to a keyword. This mx= idea is half baked, not in rfc4408, and just doesn't work. Can we please drop it? The correct answer is: Received-SPF: [...]; mechanism="-mx/24"; [...] End of story. From sm@elandsys.com Thu Feb 14 11:26:51 2013 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 BE16B21F86AD for ; Thu, 14 Feb 2013 11:26:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn3d482yoEp5 for ; Thu, 14 Feb 2013 11:26:50 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CD221F8B18 for ; Thu, 14 Feb 2013 11:26:45 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.226.233.29]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1EJQT77012333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Feb 2013 11:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360870001; bh=oYr37pka/ugcWfKM5Q1xY2dMJeT3PchjbwVKUc7x3VY=; h=Date:To:From:Subject:In-Reply-To:References; b=gtSGcd1UmG7idArD0i3JDfpKEF0PgGxPcc0WdNySHVUl7tiVDtr5wbQ5JTVseI1Vz yKd++FK77Wsy99KGc+FhGsL8qs4sMfIxA0pagSIelBJnkZq0Bk0CoRrnpkiypMQLAc UHukDuONERe0/1bUmOqhet9fJC0GZMjbWgqa+peM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1360870001; i=@elandsys.com; bh=oYr37pka/ugcWfKM5Q1xY2dMJeT3PchjbwVKUc7x3VY=; h=Date:To:From:Subject:In-Reply-To:References; b=cRpQED2BJP5zk5S/m0xmwNjCAjZ0T/nHkWVrSqFzVmk/StZzVgMeONtlSIewnP9xg x7z6KfNmgxGuowSGVhWm7NNINGrSVA5Vmeot2lS4B6WhdPa3Mvf9olHstjES7i7813 yNGJ/sCD8qlR3YJ2uJ6vvnXYt1yTukcyJfsFan14= Message-Id: <6.2.5.6.2.20130214111127.0adc2e10@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 14 Feb 2013 11:26:12 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20130207215846.14165.3433.idtracker@ietfa.amsl.com> References: <20130207215846.14165.3433.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Cancelling scheduled IETF 86 session 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, 14 Feb 2013 19:26:51 -0000 Hello, Below is the scheduled session information which was requested [1]: spfbis Session 1 (1:00:00) Friday, Afternoon Session I 1120-1220 Room Name: Caribbean 1 The working group has made some progress on draft-ietf-spfbis-4408bis-10. I didn't see any issue which requires face-to-face discussion. I'll talk to Andrew about cancelling the slot as another working group might make better use of it. Please post a message to the mailing list if you think that it is worthwhile to have a SPFBIS session at IETF 86. Regards, S. Moonesamy SPFBIS WG co-chair 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03079.html From sm@elandsys.com Sat Feb 16 08:06:09 2013 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 17F0D21F8972 for ; Sat, 16 Feb 2013 08:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3aZezAt5OZv for ; Sat, 16 Feb 2013 08:06:08 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0384921F8970 for ; Sat, 16 Feb 2013 08:06:07 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.130.11]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1GG5s2F000597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 16 Feb 2013 08:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361030766; bh=+5q5fPtX8r3AK679LBhYK/bk6guMisR/jtJjjnt8gLw=; h=Date:To:From:Subject:In-Reply-To:References; b=kMbXBxScw3a2qjN3InsH8GsdnxGbmOiGhBlCgxbchZfP4tSmHHzum3fuOa71dzh2K m66KjJrzJMTdvOipWfMfeqHi/irEoH8nmp5MTj9slkyIz0LihTQAQHbGybh5vfGBwK ORMUolPgomGn/SaC2iXWPT7VevgfnbkVlDQpcQy4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1361030766; i=@elandsys.com; bh=+5q5fPtX8r3AK679LBhYK/bk6guMisR/jtJjjnt8gLw=; h=Date:To:From:Subject:In-Reply-To:References; b=jeV9QtK3aW281BcTT+MT+qyG6EfSSVZbGo9sjRpmfuh6D6bvex07xbyKiA7fV55AB DUnJ+c78C9ym28UBcfUjmM7fPKT0Dr+6CRnFhDM8EfbVN5m1hOu1E2HiYIBIYmKxLS OLhdriQnqPJb+l4YfucAebp+Y4eqO2RNU5E5L3ak= Message-Id: <6.2.5.6.2.20130216074812.0a068d48@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 16 Feb 2013 08:05:05 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases 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, 16 Feb 2013 16:06:09 -0000 Hello, At 00:09 06-09-2012, spfbis issue tracker wrote: >#56: Section 9.2.2 Forwarding Services and Aliases > > Message posted by Dave Crocker on 5 Sept 2012: > > 3. Section 9.2.2 Forwarding Services and Aliases > > The introductory paragraph summarizes the concept and cites RFC1123 and > RFC5321. > > With respect to mailing lists and aliases, RFC 5321 updates RFC 1123. The > reference to RFC 1123 should therefore be dropped. > > However the general RFC5321 Section 3.9, Mailing Lists and Aliases, is > also rather problematic, with normative requirements that do not match > industry practice and some terminology that also differs from common > usage. So reference to RFC5321 concerning mailing lists and aliases > unfortunately invites confusion. > > Since the draft's discussion is non-normative and since the draft is > already liberally drawing from RFC 5598, I suggest that all reference and > background to Mailing Lists and Aliases be based on RFC 5598 (which is > also considerably more detailed on these topics than RFC 5321...) > > In contrast, the draft's discussion of SPF issues in the presence of > mediators: > > "[RFC1123] and [RFC5321] describe this action as an "alias" rather > than a "mail list"." > > appears useful, although it appears to cover both mailing list and > aliasing issues, not just aliasing, as constrained by the section > containing the discussion. Note that I only took a quick look at the mailing list archive before writing this message. The text is currently in Section 10.3 of draft-ietf-spfbis-4408bis-10. I didn't see any discussion about Issue #56. There was quite a lot of discussion about "Forwarding". I have to look at the issue in terms of how to resolve it. Dave Crocker suggested an alternative. The discussion could start from there. Regards, S. Moonesamy From spf2@kitterman.com Sat Feb 16 08:43:43 2013 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 6CE0721F84DA for ; Sat, 16 Feb 2013 08:43: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74RHPSPxjVWP for ; Sat, 16 Feb 2013 08:43:42 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5329521F84D9 for ; Sat, 16 Feb 2013 08:43:42 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 958EBD04066; Sat, 16 Feb 2013 10:43:41 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1361033021; bh=P+48hTUlubwvlF99H2Q0Q49wTNZ5jvej98z3Vqq99xs=; h=In-Reply-To:References:Subject:From:Date:To:From; b=M47IF3H+EeFzMQDMfnVjL6zAFAbfa3/q6hFPe8fhKBgtYKjj4ms49tN6KSUBQsKZz +BDD76XMvGU+45Of3hecYJqOxX+d50EuPzvVDfIq55xtqc5XethBj2JCCU2Kr+z9+K ZtnShV6UXMCyrn5EA8mvreH7llL9D3jV5zvsu9YI= Received: from [IPV6:2600:1003:b00e:d977:88db:ae78:5498:c4f8] (unknown [IPv6:2600:1003:b00e:d977:88db:ae78:5498:c4f8]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 317F3D0405E; Sat, 16 Feb 2013 10:43:40 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130216074812.0a068d48@elandnews.com> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <6.2.5.6.2.20130216074812.0a068d48@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 16 Feb 2013 11:43:38 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases 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, 16 Feb 2013 16:43:43 -0000 S Moonesamy wrote: >Hello, >At 00:09 06-09-2012, spfbis issue tracker wrote: >>#56: Section 9.2.2 Forwarding Services and Aliases >> >> Message posted by Dave Crocker on 5 Sept 2012: >> >> 3. Section 9.2.2 Forwarding Services and Aliases >> >> The introductory paragraph summarizes the concept and cites RFC1123 >and >> RFC5321. >> >> With respect to mailing lists and aliases, RFC 5321 updates RFC >1123. The >> reference to RFC 1123 should therefore be dropped. >> >> However the general RFC5321 Section 3.9, Mailing Lists and Aliases, >is >> also rather problematic, with normative requirements that do not >match >> industry practice and some terminology that also differs from common >> usage. So reference to RFC5321 concerning mailing lists and aliases >> unfortunately invites confusion. >> >> Since the draft's discussion is non-normative and since the draft is >> already liberally drawing from RFC 5598, I suggest that all >reference and >> background to Mailing Lists and Aliases be based on RFC 5598 (which >is >> also considerably more detailed on these topics than RFC 5321...) >> >> In contrast, the draft's discussion of SPF issues in the presence of >> mediators: >> >> "[RFC1123] and [RFC5321] describe this action as an "alias" >rather >> than a "mail list"." >> >> appears useful, although it appears to cover both mailing list and >> aliasing issues, not just aliasing, as constrained by the section >> containing the discussion. > >Note that I only took a quick look at the mailing list archive before >writing this message. The text is currently in Section 10.3 of >draft-ietf-spfbis-4408bis-10. > >I didn't see any discussion about Issue #56. There was quite a lot >of discussion about "Forwarding". I have to look at the issue in >terms of how to resolve it. Dave Crocker suggested an >alternative. The discussion could start from there. #55 and #56 are closely related. http://www.ietf.org/mail-archive/web/spfbis/current/msg03172.html got no response that I saw. Perhaps we could start from there? Scott K From sm@elandsys.com Sat Feb 16 08:55:05 2013 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 A910921F8CDF for ; Sat, 16 Feb 2013 08:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wpmjc2qkR37c for ; Sat, 16 Feb 2013 08:55:05 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0392921F8C59 for ; Sat, 16 Feb 2013 08:55:04 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.130.11]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1GGsq5t009411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 16 Feb 2013 08:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361033703; bh=OAcvmbUKXzZBU4oFI51q5k2K9zsnzSr2zdlDQ4fI4C0=; h=Date:To:From:Subject:In-Reply-To:References; b=aejy6m83A4YpFApms9+FsFSiEEjMfz0A4O7Lv0uATJGEf+LQG/eoXwgi1/cB8W2NM A+bWlIquSe/C+MeNV+zdhG6AK/RK+LK9MzrB26G3ok748RCtupuOeyp8inhoFtCQow +YX7Wbax9BMxKy0x0zIulVyGI/C1rQn3wZ0LNTa0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1361033703; i=@elandsys.com; bh=OAcvmbUKXzZBU4oFI51q5k2K9zsnzSr2zdlDQ4fI4C0=; h=Date:To:From:Subject:In-Reply-To:References; b=EIIev2LT8gCXOIWH5R0ptpkOXQUG9aLbDKOBAVTodJruiKumOgy62d4yGofe9Qgxw RDw0nbgHXeH0PAANX6f07IrdHnPVmWyv6EQkOb3pOEUdwZGjpzS2tQr0Ik9CeVl7mk 8Ku7jJxzZq98ZCFIN7V964gvQ0sO+wVglEmMZK08= Message-Id: <6.2.5.6.2.20130216085008.0aa1e990@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 16 Feb 2013 08:53:59 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <6.2.5.6.2.20130216074812.0a068d48@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases 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, 16 Feb 2013 16:55:05 -0000 Hi Scott, At 08:43 16-02-2013, Scott Kitterman wrote: >#55 and #56 are closely related. >http://www.ietf.org/mail-archive/web/spfbis/current/msg03172.html >got no response that I saw. Perhaps we could start from there? Thanks for the link. It sounds like a good starting point to me. Regards, S. Moonesamy From dhc@dcrocker.net Sun Feb 17 08:39:50 2013 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 0333F21F8B1D for ; Sun, 17 Feb 2013 08:39:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YbEjG0ELXwl for ; Sun, 17 Feb 2013 08:39:47 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B129B21F8B1C for ; Sun, 17 Feb 2013 08:39:47 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r1HGdhPO027186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 Feb 2013 08:39:43 -0800 Message-ID: <512107C8.407@dcrocker.net> Date: Sun, 17 Feb 2013 08:39:36 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Scott Kitterman References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <6.2.5.6.2.20130216074812.0a068d48@elandnews.com> In-Reply-To: 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]); Sun, 17 Feb 2013 08:39:44 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases 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: Sun, 17 Feb 2013 16:39:50 -0000 On 2/16/2013 8:43 AM, Scott Kitterman wrote: > #55 and #56 are closely related. http://www.ietf.org/mail-archive/web/spfbis/current/msg03172.html got no response that I saw. Perhaps we could start from there? OK. Alas, the result is no better than the previous draft. As we all know, Mediators impose an inherent and fundamental problem for path-based mechanisms like SPF. As such, I believe any discussion about them needs to be especially careful and thorough. Starting with that text in the latest draft: > > 10.3. Mediators > > > Broadly speaking, there are two types of mediating ADMDs that can > affect SPF deployment of other ADMDs: mailing lists (see [RFC5598] > Section 5.3) and ReSenders ([RFC5598] Section 5.2). RFC5598 characterizes ADMDs as "administrative" actors. Mediators are a sub-class of "user" actors. The distinction between the User and MHS actors, versus Administrative, is that the first two cover classic email component functionality, while ADMD covers matters of authority, responsibility and control. Note, for example, that the document's discussion of Administrative Actors (Section 2.3) does not have sub-sections describing functional components, but does have a bullet list discussing some ADMD roles. I'm being pedagogical about this because the development of that discussion in RFC 5598 wasn't straightforward and it's worth a bit of effort, to see what might make the section's distinctions more clear. Anyhow, Mediators are a type of User actor. That is, a mediator takes 'delivery' and post 'submissions'. As such, they are legitimately free (authorized) to make the newly-posted message be as similar or as different from the message they received as they wish. In contrast, MHS-level components are highly constrained in the modifications that are permitted. So much for pedagogy. As for the actual text: mediating ADMDs-> mediating actors "SPF deployment of other ADMDs." I don't know what that text means. > 10.3.1. Mailing Lists > > > Mailing lists have to be aware of how they re-inject mail that is We've developed a fondness in IETF specs to offer anthropomorphic reference about software, often in place of actually specifying substance. Mailing lists aren't aware; but much worse is that the sentence does not provide any clear implementation or operation directive. In operational terms, what would such 'awareness' mean? I don't know. To the extent that the purpose of the sentence is to highlight implications or dangers, then state them concretely. Such a notice to potential developers and operators can be useful. > sent to the list. Mailing lists MUST comply with the requirements in > [RFC5321], Section 3.10, and [RFC1123], Section 5.3.6, that say that My previous note made specific recommendations about these references and suggested an alternative. My reasoning was/is very simple: these existing references do not represent current operational realities. (Actually they never did, I believe.) > the reverse-path MUST be changed to be the mailbox of a person or Avoid re-stating normative text from a spec. It's an opportunity to introduce deviation. In addition. this particular mandate is a good example of the problem(s) with RFC5321/1123; they don't reflect operational realities. Worse, it's an attempt to impose very specific normative behavior on a community that has shown a very strong resistance to such efforts. Hence it's a futile exercise that will lull the reader into thinking that something useful has been specified. Whatever is written, it needs to attend to likely outcomes. Getting conformance on this particular point has long been demonstrated to not be one of them. > other entity who administers the list. Whereas the reasons for > changing the reverse-path are many and long-standing, SPF adds > enforcement to this requirement. Best I can suggest is to cast this segment of text as a non-normative comment about SPF's adding to the list of benefits in changing the return address. > > In practice, almost all mailing list software in use already complies Does it? What is the basis for this claim? I'm pressing the question because this is a statistic with potentially enormous operational import for SPF... > with this requirement. Mailing lists that do not comply might > encounter problems depending on how access to the list is restricted. > Such lists that are entirely internal to a domain (only people in the > domain can send to or receive from the list) are not affected. > > 10.3.2. Forwarding Services and Aliases > RFC 5598 uses the words 'forward' and 'forwarding' but not the term or definition of 'forwarding service'. (FWIW, on review I suspect the text in RFC 5598 could be significantly improved, concerning the terms 'forward' and forwarding... ) RFC 5598 refrained from using them as a labels -- it only uses them as part of sentences, rather than as distinctive terms -- because the word 'forward' has a variety of common uses in email discussion and, therefore, is too generic to be precise. Broadly, I think the label "Mediator" is meant here, but Alias is a sub-case. Intro paragraph to Section 5 of RFC5598: "A Mediator forwards a message through are-posting process." It is likely to be counter-productive for the current draft to invent a new term and proceed to offer it's own definition. This probably is not -- and I believe should not be -- the intent, but I think it's the reality of the current text. Probably the simplest change is to make the text be something like: 10.3.2 Mediators Per RFC 5598 [Section 5), a Mediator takes formal delivery of a message and then forwards it to some new address. Mailing lists and Aliasing are examples. > direct it to some external mailbox. At the time of this writing, the > near-universal practice of such services is to use the original "MAIL At the time of this writing, many instances of such services use the original "MAIL From" address when... > FROM" of a message when re-injecting it for delivery to the external > mailbox. [RFC1123] and [RFC5321] describe this action as an "alias" > rather than a "mail list". This means the external mailbox's MTA external mailbox's -> new address's > sees all such mail in a connection from a host of the forwarding > service, and so the "MAIL FROM" identity will not, in general, pass > authorization. > > Appendix D provides some operational suggestions to adapt these > services to an SPF-aware environment. -- Dave Crocker Brandenburg InternetWorking bbiw.net From vesely@tana.it Tue Feb 19 10:06:06 2013 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 157AC21F8E4B for ; Tue, 19 Feb 2013 10:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.508 X-Spam-Level: X-Spam-Status: No, score=-4.508 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEcO4E8HTZal for ; Tue, 19 Feb 2013 10:06:01 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1ED21F8DEB for ; Tue, 19 Feb 2013 10:06:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1361297159; bh=3HzGzqbNqZKTpOFzrQrv7RvQet/I4iPca4vDjUbDpkg=; l=3085; h=Date:From:To:References:In-Reply-To; b=xmOdDnPvD+kn2swqg+Sa9RA/zYES1l86oZLE8KXf0Wev1ZqMzbT0jOSHrsjWVkcVV lGM7gnsQyAiSuAsbMNmme6nV3VP8K0NGOwiPeYLFJ4U9LYfvV7hUNvO93R4XUCZGAR UJng1FyRNHh8NJg2vFKnoXpn+D3M+cJlNUHuiL2s= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Tue, 19 Feb 2013 19:05:59 +0100 id 00000000005DC039.000000005123BF07.00007FCA Message-ID: <5123BF07.7070805@tana.it> Date: Tue, 19 Feb 2013 19:05:59 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <6.2.5.6.2.20130216074812.0a068d48@elandnews.com> <512107C8.407@dcrocker.net> In-Reply-To: <512107C8.407@dcrocker.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases 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, 19 Feb 2013 18:06:06 -0000 Just mumbling on the term "Mediator"... apologies for being lengthy On Sun 17/Feb/2013 17:39:36 +0100 Dave Crocker wrote: >> >> 10.3.2. Forwarding Services and Aliases >> > > RFC 5598 uses the words 'forward' and 'forwarding' but not the term or > definition of 'forwarding service'. (FWIW, on review I suspect the > text in RFC 5598 could be significantly improved, concerning the terms > 'forward' and forwarding... ) RFC 5598 refrained from using them as a > labels -- it only uses them as part of sentences, rather than as > distinctive terms -- because the word 'forward' has a variety of > common uses in email discussion and, therefore, is too generic to be > precise. Yes, forwarding is also used to refer to the "Fwd:" client's action. For a server, the same verb can signify store-and-forward with no changes at all, as well as "Alias" or "List" processing. Ambiguity is further exasperated by the sentence: Note that the key difference between handling aliases (Section 3.9.1) and forwarding (this subsection) is the change to the backward- pointing address in this case. That text appears verbatim in Section 3.9.2 as well as in Section 4.4 of RFC 5321. Notwithstanding all that ambiguity, the term is widely used. > Broadly, I think the label "Mediator" is meant here, but Alias is a > sub-case. Intro paragraph to Section 5 of RFC5598: "A Mediator > forwards a message through are-posting process." > > > It is likely to be counter-productive for the current draft to invent > a new term and proceed to offer it's own definition. This probably is > not -- and I believe should not be -- the intent, but I think it's the > reality of the current text. > > Probably the simplest change is to make the text be something like: > > 10.3.2 Mediators That's already the title of Section 10.3. BTW, the term "Mediator" is not less ambiguous. Googling for "Mediator" and "SMTP", a good deal of the pages I found seem to use the term referring to a software pattern, whereby a mediator is a sort of behavioral wrapper around another piece of software. A few software products are actually baptized with that name. Maybe it's me, since I didn't speak this language in the cradle, but it seems that text talking about Mediators in the sense of email-arch needs to explicitly refer to RFC 5598 to be unambiguous. IMHO, Section 5 of RFC 5598 describes an interesting concept and makes an architectural point well, but it fails to supply a useful, general purpose term. The term "forwarding" seems to be well defined in the I-D. It is neither an "Alias", since it targets an external address, nor a "ReSender", since it may keep the envelope sender intact. It is not exactly a new term, e.g. Patrik Fältström used it in his presentation http://csrc.nist.gov/spam/paf.pdf in 2004, and it was written exactly as "forwarding services" in the mailflows diagram that has been standing out at openspf.org for years. Lacking a better term, I'd stick to it: "SPF breaks mediators" would never mean the same thing. From SRS0=kws0l=MN==stuart@gathman.org Thu Feb 21 15:03:33 2013 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 DC69721E8039 for ; Thu, 21 Feb 2013 15:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVXEW+6lv+ZR for ; Thu, 21 Feb 2013 15:03:33 -0800 (PST) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:470:8:488::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE5821F8703 for ; Thu, 21 Feb 2013 15:03:23 -0800 (PST) Authentication-Results: mail.bmsi.com; auth=pass (PLAIN sslbits=256) smtp.auth=stuart 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 r1LN3F1Z014256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Feb 2013 18:03:16 -0500 Message-ID: <5126A7B3.4000505@gathman.org> Date: Thu, 21 Feb 2013 18:03:15 -0500 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <1878869.epuRBHeDfC@scott-latitude-e6320> <1560860.2sJEDpXUvL@scott-latitude-e6320> <1937618.TQ5hFNaY6t@scott-latitude-e6320> In-Reply-To: <1937618.TQ5hFNaY6t@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 21 Feb 2013 23:07:30 -0000 On 02/06/2013 01:40 AM, Scott Kitterman expounded in part: > I think we can pick what we want. Mechanism is there for forensics, not for > filtering, so changing it won't affect interoperability. Personally, I think > mx=example.com is a lot more useful than mechanism=mx since there may be more > than one of a mechanism type in a record, but I'm open to either approach. I > do think we should make it clear and then give an example. I disagree. What rfc4408 calls for is mechanism="mx:example.com" (if mx:example.com was indeed the mechanism that matched). It don't know where the ideas of "mechanism=mx" (unless there truly was a bare mx) or "mx=example.com" come from. All the keys listed are keys. Including "identity". I believe the missing quotes on mechanism were a typo. From spf2@kitterman.com Thu Feb 21 15:11:01 2013 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 7FE5721E8054 for ; Thu, 21 Feb 2013 15:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wFLU3fqTgch for ; Thu, 21 Feb 2013 15:11:00 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BDCDB21E8043 for ; Thu, 21 Feb 2013 15:11:00 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2EB8520E40A4; Thu, 21 Feb 2013 18:10:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1361488260; bh=dvxlwFW4FF+YvDfKUpTVrhHuvWDSzgfhIqG7lqWaVAI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BTDYBYMJ/csFnKAtU6QHGliFBbnzbzoWtIJc6/a1Yb7egHm5N369aojpis4qXktK4 tuExD7chESuGi5Wxy6ZNoYj2KfezaCvqYrceSY/DdjuO9v9IgBe0g+wY5e7Qrtuitx Pj7F7ejfO43uGYPmkoVgEbyJ9NzKQ+ZHnVD5bpf4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0FA8F20E4062; Thu, 21 Feb 2013 18:10:50 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 21 Feb 2013 18:10:50 -0500 Message-ID: <2998982.e5aEJjZUBa@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-24-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <5126A7B3.4000505@gathman.org> References: <1878869.epuRBHeDfC@scott-latitude-e6320> <1937618.TQ5hFNaY6t@scott-latitude-e6320> <5126A7B3.4000505@gathman.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] Possible ABNF nit with Received-SPF - #53 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, 21 Feb 2013 23:11:01 -0000 On Thursday, February 21, 2013 06:03:15 PM Stuart D Gathman wrote: > On 02/06/2013 01:40 AM, Scott Kitterman expounded in part: > > I think we can pick what we want. Mechanism is there for forensics, not > > for filtering, so changing it won't affect interoperability. Personally, > > I think mx=example.com is a lot more useful than mechanism=mx since there > > may be more than one of a mechanism type in a record, but I'm open to > > either approach. I do think we should make it clear and then give an > > example. > > I disagree. What rfc4408 calls for is mechanism="mx:example.com" (if > mx:example.com was indeed the mechanism that matched). It don't know > where the ideas of "mechanism=mx" (unless there truly was a bare mx) or > "mx=example.com" come from. All the keys listed are keys. Including > "identity". I believe the missing quotes on mechanism were a typo. I'm somewhat inclined to agree with you after the last discussion on this. I think the ABNF does need to (additionally) be clarified to make it clear that: mechanism="mx:example.com" is preferred over: mechanism="mx" I think the ABNF would lead one towards the latter now (since mechanism="mx:example.com" is mechanism:domain-spec, not mechanism. Scott K From superuser@gmail.com Fri Feb 22 12:57:28 2013 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 EEE1D21E8087 for ; Fri, 22 Feb 2013 12:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arXLYV4CliPJ for ; Fri, 22 Feb 2013 12:57:28 -0800 (PST) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0B421E8089 for ; Fri, 22 Feb 2013 12:57:28 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id fb1so670275pad.25 for ; Fri, 22 Feb 2013 12:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IZZjxK7tXreLL3xlAHSJkAJHPBVLhVs7SMqFJlpiCrc=; b=JlPXP1qpgZT9yoRxG9loNz1CK21Nn0Vj1lH6xj2xZAAtNgnjHuugakMT/8fGIaxxU3 ++6ouzcDRZD8zPfRDIZBn6jnKYJ8jg8RmIcsqvsVtMQz/0mYtDdBs/XPJB6lyBi1VC7K Wl/rSPqbKnTStAdc2m2cMb9bHxCqeH+Bmo1A3Y6+BsZF8502RyfcdIyQ4V8f1RuyDosy Oeaa2GEM3I1N/lSxkM077ZkIR0WIyX78f7EJ5JVZ4MvqUFwiECr33K4vKjDXNwuYpMAX AeYv71198M+O5iFq2TTUYWYApiDcWTBxQR0qYJWBMJLqAp/YHTbW1N1FBPmCp3YXHzER 0Bpg== MIME-Version: 1.0 X-Received: by 10.68.11.135 with SMTP id q7mr5260863pbb.5.1361566647983; Fri, 22 Feb 2013 12:57:27 -0800 (PST) Received: by 10.66.165.4 with HTTP; Fri, 22 Feb 2013 12:57:27 -0800 (PST) In-Reply-To: <2998982.e5aEJjZUBa@scott-latitude-e6320> References: <1878869.epuRBHeDfC@scott-latitude-e6320> <1937618.TQ5hFNaY6t@scott-latitude-e6320> <5126A7B3.4000505@gathman.org> <2998982.e5aEJjZUBa@scott-latitude-e6320> Date: Fri, 22 Feb 2013 12:57:27 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=bcaec531479965fe0204d6567090 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 22 Feb 2013 20:57:29 -0000 --bcaec531479965fe0204d6567090 Content-Type: text/plain; charset=ISO-8859-1 I don't think I'm partial to either form but we need to ensure that, as much as possible, any change we make now doesn't render existing implementations invalid. -MSK On Thu, Feb 21, 2013 at 3:10 PM, Scott Kitterman wrote: > On Thursday, February 21, 2013 06:03:15 PM Stuart D Gathman wrote: > > On 02/06/2013 01:40 AM, Scott Kitterman expounded in part: > > > I think we can pick what we want. Mechanism is there for forensics, > not > > > for filtering, so changing it won't affect interoperability. > Personally, > > > I think mx=example.com is a lot more useful than mechanism=mx since > there > > > may be more than one of a mechanism type in a record, but I'm open to > > > either approach. I do think we should make it clear and then give an > > > example. > > > > I disagree. What rfc4408 calls for is mechanism="mx:example.com" (if > > mx:example.com was indeed the mechanism that matched). It don't know > > where the ideas of "mechanism=mx" (unless there truly was a bare mx) or > > "mx=example.com" come from. All the keys listed are keys. Including > > "identity". I believe the missing quotes on mechanism were a typo. > > I'm somewhat inclined to agree with you after the last discussion on this. > > I think the ABNF does need to (additionally) be clarified to make it clear > that: > > mechanism="mx:example.com" > > is preferred over: > > mechanism="mx" > > I think the ABNF would lead one towards the latter now (since > mechanism="mx:example.com" is mechanism:domain-spec, not mechanism. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --bcaec531479965fe0204d6567090 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't think I'm partial to either form but = we need to ensure that, as much as possible, any change we make now doesn&#= 39;t render existing implementations invalid.

-MSK


On Thu, Feb 21, 2013 at 3:10 PM, Scott K= itterman <spf2@kitterman.com> wrote:
On Thursday, February 21, 2013 06:03:15 PM Stuart D Gathm= an wrote:
> On 02/06/2013 01:40 AM, Scott Kitterman expounded in part:
> > I think we can pick what we want. =A0Mechanism is there for foren= sics, not
> > for filtering, so changing it won't affect interoperability. = =A0Personally,
> > I think mx=3Dexa= mple.com is a lot more useful than mechanism=3Dmx since there
> > may be more than one of a mechanism type in a record, but I'm= open to
> > either approach. =A0I do think we should make it clear and then g= ive an
> > example.
>
> I disagree. =A0What rfc4408 calls for is mechanism=3D"mx:example.com" (if
> mx:example.com wa= s indeed the mechanism that matched). =A0It don't know
> where the ideas of "mechanism=3Dmx" (unless there truly was = a bare mx) or
> "mx=3Dexample.co= m" come from. =A0All the keys listed are keys. =A0Including
> "identity". =A0I believe the missing quotes on mechanism wer= e a typo.

I'm somewhat inclined to agree with you after the last discussion= on this.

I think the ABNF does need to (additionally) be clarified to make it clear<= br> that:

mechanism=3D"mx:examp= le.com"

is preferred over:

mechanism=3D"mx"

I think the ABNF would lead one towards the latter now (since
mechanism=3D"mx:examp= le.com" is mechanism:domain-spec, not mechanism.

Scott K
___________________________________= ____________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--bcaec531479965fe0204d6567090-- From spf2@kitterman.com Sat Feb 23 15:26:51 2013 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 21B2F21F8C16 for ; Sat, 23 Feb 2013 15:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9g7Yq4NmJuT for ; Sat, 23 Feb 2013 15:26:50 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3E47D21F874A for ; Sat, 23 Feb 2013 15:26:50 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2BAF720E40C7; Sat, 23 Feb 2013 18:26:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1361662009; bh=LMW08b8xtAFtnZAe2r4JGCx/bOfYGSVE4+bFPbdnt54=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EE+O/lPa/xGBcdQwV25sc+hSYBfu4PhYtyDmSa96Wb9S9h/2J4EBM7DKfpfQYNQqv Nh/iL9wAXMQqeshpr+bEa/DCd8+Aa47jfLNUDMiiqt0LR5YS6T9BnpcBCCDkC1crAG jcciu3rOR5wW4cxJaD7U66nwIs49ORbeaW/Stk00= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 10F0720E40C2; Sat, 23 Feb 2013 18:26:48 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 23 Feb 2013 18:26:44 -0500 Message-ID: <1377402.2qONZRfT2E@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-25-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <2998982.e5aEJjZUBa@scott-latitude-e6320> References: <1878869.epuRBHeDfC@scott-latitude-e6320> <5126A7B3.4000505@gathman.org> <2998982.e5aEJjZUBa@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] Possible ABNF nit with Received-SPF - #53 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, 23 Feb 2013 23:26:51 -0000 On Thursday, February 21, 2013 06:10:50 PM Scott Kitterman wrote: > On Thursday, February 21, 2013 06:03:15 PM Stuart D Gathman wrote: > > On 02/06/2013 01:40 AM, Scott Kitterman expounded in part: > > > I think we can pick what we want. Mechanism is there for forensics, not > > > for filtering, so changing it won't affect interoperability. > > > Personally, > > > I think mx=example.com is a lot more useful than mechanism=mx since > > > there > > > may be more than one of a mechanism type in a record, but I'm open to > > > either approach. I do think we should make it clear and then give an > > > example. > > > > I disagree. What rfc4408 calls for is mechanism="mx:example.com" (if > > mx:example.com was indeed the mechanism that matched). It don't know > > where the ideas of "mechanism=mx" (unless there truly was a bare mx) or > > "mx=example.com" come from. All the keys listed are keys. Including > > "identity". I believe the missing quotes on mechanism were a typo. > > I'm somewhat inclined to agree with you after the last discussion on this. > > I think the ABNF does need to (additionally) be clarified to make it clear > that: > > mechanism="mx:example.com" > > is preferred over: > > mechanism="mx" > > I think the ABNF would lead one towards the latter now (since > mechanism="mx:example.com" is mechanism:domain-spec, not mechanism. Now that I've had time to read the ABNF and think it through, I believe it already does this. The ABNF definition of each mechanism includes the domain- spec, so no further change is needed. I believe all that's needed, now that I understand the issue better, is: === modified file 'trunk/ScottK/draft-ietf-spfbis-4408bis-11.xml' --- trunk/ScottK/draft-ietf-spfbis-4408bis-11.xml revid:scott@kitterman.com-20130211030342-g0o11gmfo4su31my +++ trunk/ScottK/draft-ietf-spfbis-4408bis-11.xml 2013-02-23 23:23:42 +0000 @@ -1897,8 +1897,8 @@ key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key = "client-ip" / "envelope-from" / "helo" / - "problem" / "receiver" / identity / - mechanism / name + "problem" / "receiver" / "identity" / + "mechanism" / name identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity @@ -2708,8 +2708,8 @@ key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key = "client-ip" / "envelope-from" / "helo" / - "problem" / "receiver" / identity / - mechanism / name + "problem" / "receiver" / "identity" / + "mechanism" / name identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity I think Stuart's analysis of where the error lay is correct. Scott K From spf2@kitterman.com Sat Feb 23 15:37:59 2013 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 31C2621F8491 for ; Sat, 23 Feb 2013 15:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLiki7+jQ-DF for ; Sat, 23 Feb 2013 15:37:58 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7922321F848A for ; Sat, 23 Feb 2013 15:37:58 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 098A620E40C7; Sat, 23 Feb 2013 18:37:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1361662678; bh=eT8GUTIK2b5qQKn/ISWh7G1gL59bQ+/V+4CeBWf7zak=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ax30O4FDfodjd69tW0hxxlF/uWWG2TntCSq6uoi0slrdsFHTdT3D+6TvKzlXO1xTf 3UwRrgi+Iu4eYRUp2cwwSspSZQCwn1WBnOB7LBbRWuJaDfHKSs3kEvQei468mcyVGw p42qgjsnmKhGGlp/68NOmwwrtZ7uCtL/KdMwt8qg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E46AC20E40C2; Sat, 23 Feb 2013 18:37:57 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 23 Feb 2013 18:37:57 -0500 Message-ID: <9664703.HH00DzRRtU@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-25-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <512107C8.407@dcrocker.net> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <512107C8.407@dcrocker.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] #56: Section 9.2.2 Forwarding Services and Aliases 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, 23 Feb 2013 23:37:59 -0000 On Sunday, February 17, 2013 08:39:36 AM Dave Crocker wrote: Thanks for the feedback. I agree that we need to get this right. I'm pulling out one bit of commentary for further discussion. The rest need discussion too, but focusing one bit first ... > > 10.3.1. Mailing Lists > > > > Mailing lists have to be aware of how they re-inject mail that is > > sent to the list. Mailing lists MUST comply with the requirements in > > [RFC5321], Section 3.10, and [RFC1123], Section 5.3.6, that say that > > the reverse-path MUST be changed to be the mailbox of a person or > > other entity who administers the list. Whereas the reasons for > > changing the reverse-path are many and long-standing, SPF adds > > enforcement to this requirement. > > Best I can suggest is to cast this segment of text as a non-normative > comment about SPF's adding to the list of benefits in changing the > return address. > > > In practice, almost all mailing list software in use already complies > > Does it? What is the basis for this claim? > > I'm pressing the question because this is a statistic with potentially > enormous operational import for SPF... The basis for the claim is a combination of personal experience and recollections of previous discussions of the topic. I'm currently subscribed to dozens of mailing lists and have been using mailing lists for almost two decades. I do not recall the last time I saw a mailing list that did not retransmit using it's own Mail From/Return Path. I'm surprised this question is even controversial. In a nearly a decade of work on SPF I don't recall an issue with this ever coming up. Does anyone have experience with mailing lists that don't use their own Mail From/Return Path? How would they possibly do subscriber management if they don't get the bounces? Perhaps I misunderstand your point here? Scott K From hsantos@isdg.net Sat Feb 23 19:41:32 2013 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 AFA6A21F8C16 for ; Sat, 23 Feb 2013 19:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.293 X-Spam-Level: X-Spam-Status: No, score=-103.293 tagged_above=-999 required=5 tests=[AWL=1.306, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOZf6F7foBvS for ; Sat, 23 Feb 2013 19:41:31 -0800 (PST) Received: from secure.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 88DEC21F8934 for ; Sat, 23 Feb 2013 19:41:31 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3874; t=1361677289; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=lgO/VES jxDlCOIsXsb7eDAQVO3s=; b=IIBH8dzwCd2oYCEWygSY+52GCmEuTw15OyCYCZF e/r9GdnwyRNhBvXdVPETu0jKZBOOErU8PRSlFsN3EuDhYQaKIq9KCDxbbI95ZYs6 bzsJ5bWfbWkUd0qL0kzFWzumHHfR47bONW/zZHegB7+JctI+78PYZzFHOkXxauDf 5x2g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 23 Feb 2013 22:41:29 -0500 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 471038747.3.3608; Sat, 23 Feb 2013 22:41:29 -0500 Message-ID: <51298B79.2070005@isdg.net> Date: Sat, 23 Feb 2013 22:39:37 -0500 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Scott Kitterman References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <512107C8.407@dcrocker.net> <9664703.HH00DzRRtU@scott-latitude-e6320> In-Reply-To: <9664703.HH00DzRRtU@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases 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, 24 Feb 2013 03:41:32 -0000 On 2/23/2013 6:37 PM, Scott Kitterman wrote: > On Sunday, February 17, 2013 08:39:36 AM Dave Crocker wrote: > > Thanks for the feedback. I agree that we need to get this right. I'm pulling > out one bit of commentary for further discussion. The rest need discussion > too, but focusing one bit first ... > >>> 10.3.1. Mailing Lists >>> >>> Mailing lists have to be aware of how they re-inject mail that is >>> sent to the list. Mailing lists MUST comply with the requirements in >>> [RFC5321], Section 3.10, and [RFC1123], Section 5.3.6, that say that >>> the reverse-path MUST be changed to be the mailbox of a person or >>> other entity who administers the list. Whereas the reasons for >>> changing the reverse-path are many and long-standing, SPF adds >>> enforcement to this requirement. >> Best I can suggest is to cast this segment of text as a non-normative >> comment about SPF's adding to the list of benefits in changing the >> return address. >> >>> In practice, almost all mailing list software in use already complies >> Does it? What is the basis for this claim? >> >> I'm pressing the question because this is a statistic with potentially >> enormous operational import for SPF... > The basis for the claim is a combination of personal experience and > recollections of previous discussions of the topic. I'm currently subscribed > to dozens of mailing lists and have been using mailing lists for almost two > decades. I do not recall the last time I saw a mailing list that did not > retransmit using it's own Mail From/Return Path. I'm surprised this question > is even controversial. In a nearly a decade of work on SPF I don't recall an > issue with this ever coming up. > > Does anyone have experience with mailing lists that don't use their own Mail > From/Return Path? How would they possibly do subscriber management if they > don't get the bounces? > > Perhaps I misunderstand your point here? > > Not to dwell much on it, overall, there are several kinds of "mailing list." One that is a basic expansion and can be done at the SMTP level, the payloads is not altered (just standard trace lines added); One where there is a List Management Software/Server (MLS) with special list agent addresses; and then you have like this one news letter customer we have who uses EUDORA and they manage their addresses book A.K.A. "MAILING LIST" from there. Supposedly its because of an old school expensive newsletter publishing package they have that hooks up with EUDORA. Believe me, I've tried to get them to use a real mailing list package. Anyway, in this case, their 5321.MailFrom and 5322.From is a real person, not some automated list admin/error/ return/bounce MAILER DAEMON address mixed in with a real from person. I think SPF described the List Management Software/Servers types and I think in this case, it is "more" correctly stated and well understood too. It may wish to describe the "other" forms because its quite possible to have simple expansions at the SMTP level where it internally turns around and just blast outbound mail. No headers or body is altered. No hard rule here what the return path should be. RFC6377 touches base with types but more from a point of view of DKIM and body changes that affect signatures, but not so much about return paths are used (unless it is considering Sender: changes). SPF is about the return path (envelope level domains) - no mas, so in my view, keep the focus with this and possibly just talk about any redistribution mail bot or logic needs to take into account the return path domain and IP SPF relationship when redistributing mail. A MLS (Mailing List Server) does in general have a special List Agent for bounces and returns, but it doesn't have to be for all the different kinds of "mailing list" methods. -- HLS From vesely@tana.it Mon Feb 25 01:15:41 2013 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 B65FC21F910F for ; Mon, 25 Feb 2013 01:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.546 X-Spam-Level: X-Spam-Status: No, score=-4.546 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYjDAP68YxaX for ; Mon, 25 Feb 2013 01:15:33 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5D021F8EC3 for ; Mon, 25 Feb 2013 01:15:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1361783723; bh=0eoLV8GfOysVvYSxULEc4VEfoQHM1GvpBnpaF8ow80Q=; l=1429; h=Date:From:To:References:In-Reply-To; b=UXLYj88vMl756uXsKtNxD710IjXOtmxu/BitMVTaqJ2lqKgSx9aMy1Ne/I4bOKO4M pVt0VYqksPAVEOaJa6icZpy1bZMqdjQjjOqEP+GipDctUi034zLdYNErg5TYA6/Pe8 Cb7tDUPwDQ1PxWd9W8L04nAK8IfomEygW/a7+VAU= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 25 Feb 2013 10:15:23 +0100 id 00000000005DC039.00000000512B2BAB.00000C52 Message-ID: <512B2BAA.70100@tana.it> Date: Mon, 25 Feb 2013 10:15:22 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: spfbis@ietf.org References: <1878869.epuRBHeDfC@scott-latitude-e6320> <5126A7B3.4000505@gathman.org> <2998982.e5aEJjZUBa@scott-latitude-e6320> <1377402.2qONZRfT2E@scott-latitude-e6320> In-Reply-To: <1377402.2qONZRfT2E@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 25 Feb 2013 09:15:41 -0000 On Sun 24/Feb/2013 00:26:44 +0100 Scott Kitterman wrote: >> >> mechanism="mx:example.com" Fine. I guess you are going to add something like: OLD mechanism the mechanism that matched (if no mechanisms matched, substitute the word "default") NEW mechanism the mechanism that matched (if no mechanisms matched, substitute the word "default"; otherwise if the match involved a and a dual-cidr-length, they can be reported, e.g. mechanism="mx:example.com/24" > key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) > > key = "client-ip" / "envelope-from" / "helo" / > - "problem" / "receiver" / identity / > - mechanism / name > + "problem" / "receiver" / "identity" / > + "mechanism" / name > > identity = "mailfrom" ; for the "MAIL FROM" identity > / "helo" ; for the "HELO" identity The latter looks a dangling rule to me. Actually, it is a standalone rule, recalled later down in Section 9.1. How about moving it there? OLD identity the identity that was checked; see the ABNF rule NEW identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity / name ; other identities Such move does not change the fact that identity has a formal definition while the other values are described informally: It just makes it visible, thereby improving readability. Collected ABNF in the appendix remain unaltered. jm2c From spf2@kitterman.com Mon Feb 25 05:53:17 2013 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 D466A21F92D3 for ; Mon, 25 Feb 2013 05:53:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfJWATC6lHMD for ; Mon, 25 Feb 2013 05:53:17 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id A1DC721F92D0 for ; Mon, 25 Feb 2013 05:53:17 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 368D7D04087; Mon, 25 Feb 2013 07:53:17 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1361800397; bh=R5ihqxh1Sm71pryxoaU2MW1yOrF+8HIUzDNfyqFRJjA=; h=In-Reply-To:References:Subject:From:Date:To:From; b=V+QX35SNGBoQ4Ehe86ELo9fsdUtdhlXaVT6T4Djcvl0T5pVzJ2dipJlXAitxJQn4l 18KDjpW24I2fTh4swDeruM7TpQH1t8Xrswmby+1bRSUbeifkoRR+JW4n1DKT+G1oNE LklnKy9po5S0ktqXor17AoARfs0FwWb8mg/CuM/c= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 06A44D0405B; Mon, 25 Feb 2013 07:53:16 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: <512B2BAA.70100@tana.it> References: <1878869.epuRBHeDfC@scott-latitude-e6320> <5126A7B3.4000505@gathman.org> <2998982.e5aEJjZUBa@scott-latitude-e6320> <1377402.2qONZRfT2E@scott-latitude-e6320> <512B2BAA.70100@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 25 Feb 2013 08:53:16 -0500 To: spfbis@ietf.org Message-ID: <4177a2b7-8963-403a-ae59-ee36dbdccb09@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Possible ABNF nit with Received-SPF - #53 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, 25 Feb 2013 13:53:18 -0000 Alessandro Vesely wrote: >On Sun 24/Feb/2013 00:26:44 +0100 Scott Kitterman wrote: >>> >>> mechanism="mx:example.com" > >Fine. I guess you are going to add something like: > >OLD > mechanism the mechanism that matched (if no mechanisms matched, > substitute the word "default") > >NEW > mechanism the mechanism that matched (if no mechanisms matched, > substitute the word "default"; otherwise if the match > involved a and a dual-cidr-length, they > can be reported, e.g. mechanism="mx:example.com/24" > >> key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) >> >> key = "client-ip" / "envelope-from" / "helo" / >> - "problem" / "receiver" / identity / >> - mechanism / name >> + "problem" / "receiver" / "identity" / >> + "mechanism" / name >> >> identity = "mailfrom" ; for the "MAIL FROM" identity >> / "helo" ; for the "HELO" identity > >The latter looks a dangling rule to me. Actually, it is a standalone >rule, recalled later down in Section 9.1. How about moving it there? > >OLD > identity the identity that was checked; see the ABNF > rule > >NEW > identity = "mailfrom" ; for the "MAIL FROM" identity > / "helo" ; for the "HELO" identity > / name ; other identities > >Such move does not change the fact that identity has a formal >definition while the other values are described informally: It just >makes it visible, thereby improving readability. Collected ABNF in >the appendix remain unaltered. I hadn't thought such additional changes were needed. Anyone else? Scott K From internet-drafts@ietf.org Mon Feb 25 12:53:48 2013 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 B57F521F9211; Mon, 25 Feb 2013 12:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnU3isEV6qYB; Mon, 25 Feb 2013 12:53:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C134121E80A3; Mon, 25 Feb 2013 12:53:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225205347.10856.53932.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 12:53:47 -0800 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-11.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: Mon, 25 Feb 2013 20:53:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Dom= ains in Email, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-11.txt Pages : 73 Date : 2013-02-25 Abstract: Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby an ADMD can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Mon Feb 25 12:56:05 2013 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 CB3E721F928E for ; Mon, 25 Feb 2013 12:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwlFKBDU4-m8 for ; Mon, 25 Feb 2013 12:56:04 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 604D521F91ED for ; Mon, 25 Feb 2013 12:56:04 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9FE7A20E4172; Mon, 25 Feb 2013 15:56:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1361825763; bh=BBwat7SMsnhKC86rMLBO+RoqXdda1l0O48UzFPOoED0=; h=From:To:Subject:Date:From; b=SqaXyUJ2Fgzdska7lraSLwS1jWLJkEtXDOYYMNwjEPTbmto+31BQo9k93qJ5aoKQj O01QuVnqybxQeXtS8LmYqpD0PJ+VWWmu3HVoGElD3cPVtYc6RFSEvhD1bDK1XLYAYO JsUN+cHJllqW557kduxND+t4qdaQqInhZHJ8YCIY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8372F20E40C9; Mon, 25 Feb 2013 15:56:03 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Feb 2013 15:56:02 -0500 Message-ID: <1408174.1Yykq0d4iz@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-25-generic; KDE/4.9.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] New Version Notification for draft-ietf-spfbis-4408bis-11.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: Mon, 25 Feb 2013 20:56:06 -0000 Subject: New Version Notification for draft-ietf-spfbis-4408bis-11.txt Date: Monday, February 25, 2013, 12:53:48 PM From: internet-drafts@ietf.org A new version of I-D, draft-ietf-spfbis-4408bis-11.txt has been successfully submitted by Scott Kitterman and posted to the IETF repository. Filename: draft-ietf-spfbis-4408bis Revision: 11 Title: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Creation date: 2013-02-25 Group: spfbis Number of pages: 73 URL: http://www.ietf.org/internet-drafts/draft-ietf- spfbis-4408bis-11.txt Status: http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis Htmlized: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-11 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-11 This update includes post -10 changes we've discussed on the list. If there are issues with any of it, please discuss. I posted today to capture the current state before the draft submission cutoff. Scott K From sm@elandsys.com Mon Feb 25 13:13:49 2013 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 25A4021E80C5 for ; Mon, 25 Feb 2013 13:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YT71Ha1GprTK for ; Mon, 25 Feb 2013 13:13:48 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C54721E80BA for ; Mon, 25 Feb 2013 13:13:48 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.141.196]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1PLDaC0018479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Feb 2013 13:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361826827; bh=Oo58VsEDg1Xx3sDO02cyRBv5/V3uq9oZuR2M+ur2WJs=; h=Date:To:From:Subject:In-Reply-To:References; b=a/P3yKx5QW3dgZGrn5gWtEUFxVUrTyt0+bFk0bLHprq+o7mx3GveTBTHMVPPupnli e2IlcVpkVBllsIcESCTmDkYzvPVTowKw8hMqESTZK7Xzn1i2nPmV/mLZwmnqfCstEV OufAccR2E3tZgthijEw+QyJ4xto6ooDHsYpaAZ8M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1361826827; i=@elandsys.com; bh=Oo58VsEDg1Xx3sDO02cyRBv5/V3uq9oZuR2M+ur2WJs=; h=Date:To:From:Subject:In-Reply-To:References; b=2v/zVIgqogBSZEx7D48i3qDfFVdjkmSijsIwj2pTUYXh6rpk5t6bEDCQpY4au4cf5 F2/PS8IYQibo56sNFOnAyn5K7Y1oPQeOQ42hM0gT9JpU/IyHoJhUVBkIwlAQZsa02v 3DGlvgYGSpHjtqm70n1JGMZI9aDsoMXE3yIi8OmA= Message-Id: <6.2.5.6.2.20130225130830.0a878168@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Feb 2013 13:12:58 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <51298B79.2070005@isdg.net> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <512107C8.407@dcrocker.net> <9664703.HH00DzRRtU@scott-latitude-e6320> <51298B79.2070005@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases 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, 25 Feb 2013 21:13:49 -0000 Hello, This is an individual comment. From Section 10.3.1 of draft-ietf-spfbis-4408bis-11: "Mailing lists have to be aware of how they re-inject mail that is sent to the list." What is the meaning of "mailing lists" in the above? The reason I am asking that question is to clarify what the working group is talking about. It may then be easier to resolve Issue #56. Regards, S. Moonesamy From spf2@kitterman.com Mon Feb 25 13:35:22 2013 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 B872721E80EA for ; Mon, 25 Feb 2013 13:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lBF3XNr+4ZB for ; Mon, 25 Feb 2013 13:35:22 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E581D21E80E9 for ; Mon, 25 Feb 2013 13:35:21 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 683E020E4172; Mon, 25 Feb 2013 16:35:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1361828121; bh=HaRg+ZkSNWqBrqmGOLgG4n1lZgeBIxEoyZ7b/Kuz6JY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GPSInOMrF3Wj1UjFRixKuy3ZJwY1/ZtN8fwwl0TP4YnK0MEXd2qMMIFtntCm7KpRk +kpS94L4aiAs9WRRpvxLMm/es9k6f16Y/F+i+Mi01LfT7ncyLhScfSq7+RxiP7Q9hy 6Ygxi6E2lpXWovR2PXzzPbmmvlsPOSjte9QtGq54= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 51C4A20E40C9; Mon, 25 Feb 2013 16:35:20 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Feb 2013 16:35:20 -0500 Message-ID: <1951033.rrYnrvGjn7@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-25-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20130225130830.0a878168@resistor.net> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <51298B79.2070005@isdg.net> <6.2.5.6.2.20130225130830.0a878168@resistor.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] #56: Section 9.2.2 Forwarding Services and Aliases 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, 25 Feb 2013 21:35:22 -0000 On Monday, February 25, 2013 01:12:58 PM S Moonesamy wrote: > Hello, > > This is an individual comment. From Section 10.3.1 of > draft-ietf-spfbis-4408bis-11: > > "Mailing lists have to be aware of how they re-inject mail that is > sent to the list." > > What is the meaning of "mailing lists" in the above? > > The reason I am asking that question is to clarify what the working > group is talking about. It may then be easier to resolve Issue #56. Dave also commented on this. We are currently communicating via a mailing list. This area of text still needs work. Scott K From dhc@dcrocker.net Mon Feb 25 13:41:18 2013 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 9311421E80BA for ; Mon, 25 Feb 2013 13:41:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAr4vmDOe7Xg for ; Mon, 25 Feb 2013 13:41:18 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFD021E80E0 for ; Mon, 25 Feb 2013 13:41:18 -0800 (PST) Received: from [172.19.126.234] (64.125.189.90.t00817-23.above.net [64.125.189.90] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r1PLfH6E029468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 13:41:17 -0800 Message-ID: <512BDA7A.8060005@dcrocker.net> Date: Mon, 25 Feb 2013 13:41:14 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Scott Kitterman References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <512107C8.407@dcrocker.net> <9664703.HH00DzRRtU@scott-latitude-e6320> In-Reply-To: <9664703.HH00DzRRtU@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]); Mon, 25 Feb 2013 13:41:17 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases 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: Mon, 25 Feb 2013 21:41:18 -0000 On 2/23/2013 3:37 PM, Scott Kitterman wrote: > On Sunday, February 17, 2013 08:39:36 AM Dave Crocker wrote: >>> In practice, almost all mailing list software in use already complies >> >> Does it? What is the basis for this claim? >> >> I'm pressing the question because this is a statistic with potentially >> enormous operational import for SPF... > > The basis for the claim is a combination of personal experience and > recollections of previous discussions of the topic. I'm currently subscribed > to dozens of mailing lists and have been using mailing lists for almost two > decades. I do not recall the last time I saw a mailing list that did not > retransmit using it's own Mail From/Return Path. I'm surprised this question > is even controversial. In a nearly a decade of work on SPF I don't recall an > issue with this ever coming up. On reflection, I withdraw the question, because it takes the concern about the document in the wrong direction: This is a protocol spec, not an opererations guideline that might permit citing heuristics. The current text asserts a useful heuristic, but "violations" of the heuristic are not violations of protocol. > Perhaps I misunderstand your point here? My core point is that mailing lists are not required to create a new rfc5321.mailfrom address, but it they don't, SPF breaks (absent registration of the mediator in the SPF record. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Mon Feb 25 13:54:02 2013 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 354AE21E80FA for ; Mon, 25 Feb 2013 13:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9I8TGBW1TTy for ; Mon, 25 Feb 2013 13:54:00 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id ADB7121F9011 for ; Mon, 25 Feb 2013 13:53:53 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 589F420E4172; Mon, 25 Feb 2013 16:53:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1361829225; bh=ntYXIyO2N3H14sMWcFHxFTrOWJtJ3gEWg1pJlmeTopk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C88YvWXQ2nd5ZHCoysHrLmqPNGLtcnbhW6T9hrOxiojjA3iftBzm2PgOcN7NocV4u YAY4L9dSkLajGdfccNj1Z+l9dwHHY7vOENCwz96c+yHAOLAjAQDVrpNCBG7S2XcIoU Tvt/sNeWnAaNEcEmAH8slmbUcvVm18xb8+Mb4+f0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3FC4A20E40C9; Mon, 25 Feb 2013 16:53:44 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Feb 2013 16:53:44 -0500 Message-ID: <1813725.CSqLJFfySO@scott-latitude-e6320> User-Agent: KMail/4.9.4 (Linux/3.5.0-25-generic; KDE/4.9.4; i686; ; ) In-Reply-To: <512BDA7A.8060005@dcrocker.net> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <9664703.HH00DzRRtU@scott-latitude-e6320> <512BDA7A.8060005@dcrocker.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] #56: Section 9.2.2 Forwarding Services and Aliases 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, 25 Feb 2013 21:54:02 -0000 On Monday, February 25, 2013 01:41:14 PM Dave Crocker wrote: > On 2/23/2013 3:37 PM, Scott Kitterman wrote: > > On Sunday, February 17, 2013 08:39:36 AM Dave Crocker wrote: > >>> In practice, almost all mailing list software in use already > >>> complies > >> > >> Does it? What is the basis for this claim? > >> > >> I'm pressing the question because this is a statistic with potentially > >> enormous operational import for SPF... > > > > The basis for the claim is a combination of personal experience and > > recollections of previous discussions of the topic. I'm currently > > subscribed to dozens of mailing lists and have been using mailing lists > > for almost two decades. I do not recall the last time I saw a mailing > > list that did not retransmit using it's own Mail From/Return Path. I'm > > surprised this question is even controversial. In a nearly a decade of > > work on SPF I don't recall an issue with this ever coming up. > > On reflection, I withdraw the question, because it takes the concern > about the document in the wrong direction: This is a protocol spec, not > an opererations guideline that might permit citing heuristics. > > The current text asserts a useful heuristic, but "violations" of the > heuristic are not violations of protocol. > > > Perhaps I misunderstand your point here? > > My core point is that mailing lists are not required to create a new > rfc5321.mailfrom address, but it they don't, SPF breaks (absent > registration of the mediator in the SPF record. What if we redo this section in terms of mediators that change mail from to something local to the mediator and mediators that leave it unchanged? I think that is the key point and while one can make generalizations about which types of mediators do what, it may work better to write about this topic primarily in terms of how mediators behave relative to mail from than what type of mediator they are. Scott K From sm@elandsys.com Mon Feb 25 14:16:13 2013 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 75E9C21E8114 for ; Mon, 25 Feb 2013 14:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPdioh8aBZ1m for ; Mon, 25 Feb 2013 14:16:12 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9BE21E80FA for ; Mon, 25 Feb 2013 14:16:12 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.141.196]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1PMG01Q017888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Feb 2013 14:16:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361830571; bh=dUqHatTR9z2XqgJtZWvp6Gxa6x50uhg++oKKbusCvZw=; h=Date:To:From:Subject:In-Reply-To:References; b=ZbEU5bFUD9ss4rPii0JsW7IKxujg+ZW5Zx/tpxIPTOJzMtUy9Y4+CFHSCGO/PR4OK PwWCbAbrzfnX6xqQFzMkGz3Ik3mw9RbhK2FkLZTKOQufZDds28nUbmdHutzskmYqQ8 HKToSdLHURmjULsvRJJZn+Vn0fMzJNq8pcVSRmkc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1361830571; i=@elandsys.com; bh=dUqHatTR9z2XqgJtZWvp6Gxa6x50uhg++oKKbusCvZw=; h=Date:To:From:Subject:In-Reply-To:References; b=uBoOCHB8Gmc0zjg8Oks926H0FpS3fb38L+I+BeFRI3dj7DOjSmEVaUvWqtxbHJl8O 9PMDpfgSidtZz51TJT2M+aKn8p85L6/BpxXtOSCSDZvgqtimWLFh2hziEQiwLM2gVL bYh/tQ6O7tT/Uq94uGNoBi11yoHGhkExqkF1hkc8= Message-Id: <6.2.5.6.2.20130225135844.0a951628@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Feb 2013 14:15:26 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <512BDA7A.8060005@dcrocker.net> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <512107C8.407@dcrocker.net> <9664703.HH00DzRRtU@scott-latitude-e6320> <512BDA7A.8060005@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases 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, 25 Feb 2013 22:16:13 -0000 At 13:41 25-02-2013, Dave Crocker wrote: >On reflection, I withdraw the question, because it takes the concern >about the document in the wrong direction: This is a protocol spec, >not an opererations guideline that might permit citing heuristics. There are issues which can be non-issues, depending on the path taken, e.g. protocol specs. Scott Kitterman posted a suggestion at http://www.ietf.org/mail-archive/web/spfbis/current/msg03287.html There won't be any progress if there aren't any comments from working group participants. Regards, S. Moonesamy From sm@elandsys.com Thu Feb 28 23:04:40 2013 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 BDBE321F89B2 for ; Thu, 28 Feb 2013 23:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCOuURuG4dfO for ; Thu, 28 Feb 2013 23:04:40 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3797321F85B3 for ; Thu, 28 Feb 2013 23:04:37 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.134.77]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r2174Oax000288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 23:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1362121476; bh=RWj6W4i8CfC2dP4QD2MOCRfffr7ZCCt32DoryD6u5+0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mqTqTGoVr5m3vC9rsMPpZoCYFCraHvg4N6pwDKKNjaPDiOuCjiQn71JJ+u5/imr6U PZL575BLND4v0EvxfCuQanymhx+JR1yCyb6a64zK5JigV8hV/ae9UsLUonS+99et2I 5OSNmkJw9dPdevup3YHPlBDM3wR9p2qfiaiAYhsE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1362121476; i=@elandsys.com; bh=RWj6W4i8CfC2dP4QD2MOCRfffr7ZCCt32DoryD6u5+0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=anYZwFdh6FUXtihGkeNCt3iAAadsa5M/zXJOlc5C0ShbANwcpbDuU7ZE0QpTIaRNb IfGr/8R22ceT8uIFHDqGhnXCiFugC9Lj4V0Z1R4ehIqlu950T5zQudM18KcFroqCcT FwCNSyctf98ZoNbKLUSJaBH+GX9lNn/aPLxN3xxQ= Message-Id: <6.2.5.6.2.20130228225826.0a799db8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Feb 2013 23:00:21 -0800 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <1813725.CSqLJFfySO@scott-latitude-e6320> References: <064.0a1e9362627917bfff72b6084fbe44e5@tools.ietf.org> <9664703.HH00DzRRtU@scott-latitude-e6320> <512BDA7A.8060005@dcrocker.net> <1813725.CSqLJFfySO@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases 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, 01 Mar 2013 07:04:40 -0000 Hi Alessandro, At 13:53 25-02-2013, Scott Kitterman wrote: >What if we redo this section in terms of mediators that change mail from to >something local to the mediator and mediators that leave it unchanged? I >think that is the key point and while one can make generalizations >about which >types of mediators do what, it may work better to write about this topic >primarily in terms of how mediators behave relative to mail from than what >type of mediator they are. Are you ok with the above-mentioned approach? Regards, S. Moonesamy