From spf2@kitterman.com Mon Apr 1 21:31: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 9C38D21F94CC for ; Mon, 1 Apr 2013 21:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xsx6c-EN3doP for ; Mon, 1 Apr 2013 21:31:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B611D21F94A6 for ; Mon, 1 Apr 2013 21:31:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A5B0A20E40D5; Tue, 2 Apr 2013 00:31:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364877092; bh=BgpGHSs/kdOz0IYi2Lrt+NEr+nRCsdnarfKKcVuWe4k=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aQBcoQFEMJYJfT8Fz5T++6UoGGWfOwAqf/kzR06wtpn6vtJT6/ivK2CmefBhU/4vm jLAp4I6FJWbGxgb1I2ibI8o7SG02XXGQ+ixk1TUuGV6tVjdYJL3Mibpj3fNUdNmxv1 gtMqvwJnj7oqh1rKN5IoGtD3RjYrD6Yiins3NR/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 8CF9020E4090; Tue, 2 Apr 2013 00:31:22 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 02 Apr 2013 00:31:21 -0400 Message-ID: <1590403.BSNi78tk4l@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <2171755.unhtkAshy1@scott-latitude-e6320> <2312084.dQrlQ2JCVg@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 for upgrades from RFC 4408 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, 02 Apr 2013 04:31:33 -0000 On Sunday, March 31, 2013 03:40:07 PM Murray S. Kucherawy wrote: > On Sun, Mar 31, 2013 at 2:30 PM, Scott Kitterman wrote: > > > Appendix C. Changes in implementation requirements from RFC 4408 > > I would add a note at the top of the section that indicates the changes are > all either (a) corrections to errors in 4408, or (b) additional > documentation based on consensus of operational experience acquired since > publication of 4408. Otherwise, a reviewer might wonder what the basis of > some or all of these might be. > > > - Use of DNS RR type SPF (99) has been removed from the protocol [RFC > > > > > 6686]. > > > > > > - A new DNS related processing limit based on "void lookups" has been > > > > added > > > > > [section 4.6.4]. > > > > > > - A new option for converting repeated DNS SERVFAIL responses from > > > > > > temperror to permerror as been added [section 2.6.6]. > > > > > > - Use of the ptr mechanism and the %p macro have been strongly > > > > discouraged > > > > > [section 5.5] and [section 7.2]. They remain part of the protocol, but > > > records ought to be updated to avoid them. > > "...because they were found to still be in use..." > > > > - Use of the Authentication Results header field [RFC 5451] as a > > > > possible > > > > > alternative to use of the Received-SPF header field is discussed > > > [section > > > 9.2] > > "Authentication-Results" > > > > - There have been a number of minor corrections to the ABNF to make it > > > > more > > > > > clear and correct [Appendix A]. SPF library implementers should give > > > the > > > revised ABNF a careful review to determine if implementation changes are > > > needed. > > > > > > - Use of X- fields in the ABNF has been removed [RFC 6648]. > > > > > > - Ambiguity about how to deal invalid domain-spec after macro expansion > > > > has > > > > > been documented. Depending on one specific behavior has to be avoided > > > [section 4.8]. > > "...deal with..." Thanks for reviewing. All incorporated locally. Scott K From internet-drafts@ietf.org Mon Apr 1 21:48: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 3AD4921F97FD; Mon, 1 Apr 2013 21:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8-2cozksyV5; Mon, 1 Apr 2013 21:48:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 009F321F9805; Mon, 1 Apr 2013 21:48:05 -0700 (PDT) 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.43 Message-ID: <20130402044804.10745.90162.idtracker@ietfa.amsl.com> Date: Mon, 01 Apr 2013 21:48:04 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-14.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, 02 Apr 2013 04:48:13 -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-14.txt Pages : 74 Date : 2013-04-01 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Mon Apr 1 21:52: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 4B2EA21F9818 for ; Mon, 1 Apr 2013 21:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLfAupOgOs+S for ; Mon, 1 Apr 2013 21:52:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AE7D321F9817 for ; Mon, 1 Apr 2013 21:52:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B736020E40D5; Tue, 2 Apr 2013 00:52:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364878352; bh=WI3dKQG69If0TP7zmqmPz2fZPbbRabDkQMVaM14cDvE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KfULC9WPU1RBs+XJI+Az2A+IxdVdqx94Lshyrb/72431Tkkr54m53PNUb/tiNxz2C p9/hufe922+fwT7YAsuF2s16QloRtzBCf5SNomN3IbFk90JQFU388eImrRDh+S7xMO 8OOe5Kb+att6J2VynUP43SZKcIvBFntuPCQVz4Ws= 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 98A9520E4090; Tue, 2 Apr 2013 00:52:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Date: Tue, 02 Apr 2013 00:52:31 -0400 Message-ID: <1901637.zXFm7cGYLx@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <20130402044804.10745.90162.idtracker@ietfa.amsl.com> References: <20130402044804.10745.90162.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-14.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, 02 Apr 2013 04:52:43 -0000 On Monday, April 01, 2013 09:48:04 PM 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-14.txt > Pages : 74 > Date : 2013-04-01 This draft adds the new appendix on requirements changes since RFC 4408 and reflects all the changes from feedback to date. I think we're ready for WGLC. Scott K From sm@elandsys.com Wed Apr 3 14:28: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 43A0021F8E69 for ; Wed, 3 Apr 2013 14:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQlgQTkDNmXr for ; Wed, 3 Apr 2013 14:28:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A832721F8D94 for ; Wed, 3 Apr 2013 14:28:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.207]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r33LSbHe013038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Apr 2013 14:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365024531; bh=Jm/QzthbDC+8fgG8qtTD7uFnDUd58Ac79h8VHHD9GCQ=; h=Date:To:From:Subject:Cc; b=AjU5xpAmWyAnriQyfpj90hfJMkTGgoV8bgWgVXz/nRUEs9k2pcfvkL5JPvTXmeuKE rj+4GYLUy//r0kxFA2UDTOVhKQkd4LCiuCA44grSL817Or6rWTwzvD2QFbHVUi5VD7 0uBLEDwHLEk/oOiZs13EczKfkgxBONv6kEZLS0BY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1365024531; i=@elandsys.com; bh=Jm/QzthbDC+8fgG8qtTD7uFnDUd58Ac79h8VHHD9GCQ=; h=Date:To:From:Subject:Cc; b=0QL8Oe2YprFcE5Z8droxiyJ1kNHeIRYPKU66lB5zmYwG8Edx4g8uLkbLXJ3B0ujie Ml/Qa00Ejcg+U9PwlrWtM9G/CEZOAc0EdZXEd4ipOejJyOIU0qCEWetpR2BVqtyvh5 cDzokp/FMhjGei0YAQJ6dBqdVnxSdVoFpH0KcL2Y= Message-Id: <6.2.5.6.2.20130403142413.0b221b18@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 Apr 2013 14:28:25 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org Subject: [spfbis] IPR relating to 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, 03 Apr 2013 21:28:54 -0000 Dear colleagues, We would like to check whether there are any claims of Intellectual Property Rights (IPR) on draft-ietf-spfbis-4408bis that have not yet been disclosed. Please note that an IPR disclosure was filed for RFC 4408 (see https://datatracker.ietf.org/ipr/1698/ ). Are you personally aware of any IPR that applies to draft-ietf-spfbis-4408bis. If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Andrew Sullivan & S. Moonesamy SPFBIS WG co-chairs From superuser@gmail.com Wed Apr 3 14:37: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 95B4921F9025 for ; Wed, 3 Apr 2013 14:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFPbnG8J7Vo3 for ; Wed, 3 Apr 2013 14:37:38 -0700 (PDT) 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 AD30B21F9023 for ; Wed, 3 Apr 2013 14:37:37 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id k13so65251wgh.3 for ; Wed, 03 Apr 2013 14:37:36 -0700 (PDT) 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=yBh71Tz0qucewnsR+Fa7iWYIbG+f+sViFj+6vZ2GWDE=; b=drhEJxrHfawBMmVxE81cMDIIUj6g56vM0+JRuWCVUo4erp0gSkBWbarslJknqgAmgo 905fg80915geso23Ly4V247C/07LvPazesBvVu5q0fsAEf/GYCB67xYFuOlU5DekH8+m Dye9Dv6pgOLHH0U2SAHdVgCoAm+jNNrerYoURs8LmYJ9ZHP82skE/Nd8xgG7Zz4cNOvS zyA56J9//5fZBC37zvFHbP0AclvAmknw54AmfaccD++m8fFkE3AJX6c3/JPTewsEswB1 N+QPjEtHn9ZIchlmn3s5CKMpGn2PdbVwNB4FiglXyvWZy7E9rYzz4kWJEUokSGTfYmDo plGg== MIME-Version: 1.0 X-Received: by 10.180.90.116 with SMTP id bv20mr5133251wib.32.1365025056877; Wed, 03 Apr 2013 14:37:36 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 3 Apr 2013 14:37:36 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130403142413.0b221b18@elandnews.com> References: <6.2.5.6.2.20130403142413.0b221b18@elandnews.com> Date: Wed, 3 Apr 2013 14:37:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d043c7f4e9ff2db04d97ba953 Cc: "spfbis@ietf.org" , spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] IPR relating to 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, 03 Apr 2013 21:37:38 -0000 --f46d043c7f4e9ff2db04d97ba953 Content-Type: text/plain; charset=ISO-8859-1 The one that's in the tracker is the only one I know of. On Wed, Apr 3, 2013 at 2:28 PM, S Moonesamy wrote: > Dear colleagues, > > We would like to check whether there are any claims of Intellectual > Property Rights (IPR) on draft-ietf-spfbis-4408bis that have not yet been > disclosed. > > Please note that an IPR disclosure was filed for RFC 4408 (see > https://datatracker.ietf.org/**ipr/1698/). > > Are you personally aware of any IPR that applies to > draft-ietf-spfbis-4408bis. If so, has this IPR been disclosed in > compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for > more details.) > > Andrew Sullivan & S. Moonesamy > SPFBIS WG co-chairs > > ______________________________**_________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/**listinfo/spfbis > --f46d043c7f4e9ff2db04d97ba953 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The one that's in the tracker is the only one I know o= f.


O= n Wed, Apr 3, 2013 at 2:28 PM, S Moonesamy <sm+ietf@elandsys.com>= ; wrote:
Dear colleagues,

We would like to check whether there are any claims of Intellectual Propert= y Rights (IPR) on draft-ietf-spfbis-4408bis that have not yet been disclose= d.

Please note that an IPR disclosure was filed for RFC 4408 (see https://datatracke= r.ietf.org/ipr/1698/ ).

Are you personally aware of any IPR that applies to draft-ietf-spfbis-4408b= is. =A0If so, has this IPR been disclosed in compliance with IETF IPR rules= ? (See RFCs 3979, 4879, 3669, and 5378 for more details.)

Andrew Sullivan & S. Moonesamy
SPFBIS WG co-chairs

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

--f46d043c7f4e9ff2db04d97ba953-- From ajs@anvilwalrusden.com Mon Apr 8 23:24: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 A3FB321F8F21 for ; Mon, 8 Apr 2013 23:24:35 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRMBXhrDAlOw for ; Mon, 8 Apr 2013 23:24:35 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3386221F8F27 for ; Mon, 8 Apr 2013 23:24:35 -0700 (PDT) Received: from mx1.yitter.info (li440-116.members.linode.com [50.116.54.116]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id BEEFF8A031 for ; Tue, 9 Apr 2013 06:24:34 +0000 (UTC) Date: Tue, 9 Apr 2013 02:24:32 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130409062431.GK24624@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 09 Apr 2013 06:24:35 -0000 Dear colleagues, This message initiates a two-week working group last call on draft-ietf-spfbis-4408bis-14, our only work item. The draft has been through 14 revisions, and all open issues in the tracker are closed. Please review the document and indicate any comments you have by sending a note to the mailing list. If you have no comments, it is valuable nevertheless to learn that you have read the document and support its publication. WGLC will close at 2014-04-24 00:00 UTC. SM will be the shepherd for this document. Best regards, Andrew (for the chairs) -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Thu Apr 11 03:28: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 5FD9421F8EBC for ; Thu, 11 Apr 2013 03:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r88CKiDSwQOD for ; Thu, 11 Apr 2013 03:28:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0C221F8EA7 for ; Thu, 11 Apr 2013 03:28:40 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.160]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3BASQrm010594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Apr 2013 03:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365676118; bh=x/8zWuo9h328NZqU5X6uJRGZqqNopcE7ob+n8PjCcJk=; h=Date:To:From:Subject; b=wtH8WqIg/j2xl4an8bO9owqZgzXbB7+KGjnQdg6X9XCIrR0D1IWEoRwLXEwtcfITv yHEUq31C/4qo3Mx1spml/NnY55sosnWiqkebWqixeUwQzGjhSfkWIR+UsOytujZSW5 +52r99KQVKu7dZLESvG2MrRpPe2dliEU/9lNf/Pc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1365676118; i=@elandsys.com; bh=x/8zWuo9h328NZqU5X6uJRGZqqNopcE7ob+n8PjCcJk=; h=Date:To:From:Subject; b=T7fOHFAV3D08NmV210JN5ngr9DRb0vvyfvEjN5kcr+/zUTp52kes1fZ3dhwiJqnFJ MGphZXlO2XrIO7TkgiyfBe8WfaYTU/rbAyetLz7pkPgtfWbH+RdqSvPbP+NwG8y7Dn +8FzQUzuah4lWtCnKOzNUmW7kT2/Jzsh1KlJC7pA= Message-Id: <6.2.5.6.2.20130411030449.0ce5be80@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 11 Apr 2013 03:17:47 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Implementation status of 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: Thu, 11 Apr 2013 10:28:41 -0000 Hello, I would like to have some information about the implementation of draft-ietf-spfbis-4408bis [1]. If you have implemented the draft, could you please send me the following information: (a) Implementation name (b) Description of implementation (please include a link to a web page if it contains information about the implementation) (c) The versions of the draft which were implemented (c) The parts of draft-ietf-spfbis-4408bis which were implemented Regards, S. Moonesamy 1. http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-14 From superuser@gmail.com Thu Apr 11 06:29: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 587DB21F8648 for ; Thu, 11 Apr 2013 06:29:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwxlxMh5txvc for ; Thu, 11 Apr 2013 06:29:19 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E4EC321F862A for ; Thu, 11 Apr 2013 06:29:17 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hj8so554002wib.13 for ; Thu, 11 Apr 2013 06:29:17 -0700 (PDT) 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:content-type; bh=QTfQ6E+yT4S/ZFvDRVoz/UUvoFIN5Gwf2gP+XY0fe1w=; b=jNusjO2bpXbFV336u/HNdTzQbFiw2S47IF0V1J62fxfPIrO/YPMzStvfFDRqw9+lZR Xry0BVT43svr6QwDSPfMHkLEbnjlh12c3v50j8Q7Qdjif0ENOQ1HW3nCSRRu5fQFFLoV E215MNs0tIpC2ONL9x6kgmz1qYPOkMruQUPog2smOELWLVhMDHyGf4zPq5JDgNksaWix B1D7Ou6bx55bNxvpFRDfKzY68kGg/bi3KytH9ES3XJIUETB4URg+EoYqisXyyzRtlYKF Yo2gQNbukYJRnCbWK32rOjQ8I+sroaK6o6L/FD7ISfO3orlP6Bktbyj0TeoAHJDQrHlR Izbw== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr10840080wjb.15.1365686955352; Thu, 11 Apr 2013 06:29:15 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 11 Apr 2013 06:29:15 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130411031751.0ce5baa8@elandnews.com> References: <6.2.5.6.2.20130411031751.0ce5baa8@elandnews.com> Date: Thu, 11 Apr 2013 06:29:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=089e010d8574d9293d04da15c5df Subject: Re: [spfbis] [dmarc-ietf] Implementation status of 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: Thu, 11 Apr 2013 13:29:20 -0000 --089e010d8574d9293d04da15c5df Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 11, 2013 at 3:21 AM, S Moonesamy wrote: > (a) Implementation name > sid-milter > (b) Description of implementation (please include a link to a > web page if it contains information about the implementation) > http://sourceforge.net/projects/sid-milter > (c) The versions of the draft which were implemented > RFC4408 only > (c) The parts of draft-ietf-spfbis-4408bis which were implemented > All of it except for: - the part where the HELO/EHLO domain is evaluated - testing of type 99 records -MSK --089e010d8574d9293d04da15c5df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 11, 2013 at 3:21 AM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
=A0 (a) Implementation na= me

sid-milter
=A0
=A0 (b) Description of implementation (please include a link to a
=A0 =A0 =A0 web page if it contains information about the implementation)
=A0 (c) The versions of the draft which were implemented

RFC4408 only
=A0
=A0 (c) The parts of draft-ietf-spfbis-4408bis which were implemented

All of it except for:

- the par= t where the HELO/EHLO domain is evaluated
- testing of type 9= 9 records

-MSK

--089e010d8574d9293d04da15c5df-- From hsantos@isdg.net Thu Apr 11 10:54: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 D292121F8617 for ; Thu, 11 Apr 2013 10:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2l77eujb05qe for ; Thu, 11 Apr 2013 10:54:31 -0700 (PDT) Received: from dkim.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AFCD821F85D9 for ; Thu, 11 Apr 2013 10:54:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6636; t=1365702829; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=ABdSt8w 4RrWqJ2kuqpmoXRT753A=; b=Ew+JXu8ki8E5Ts7sUM6cVRc0rLIVna9tDYr6MJi vAm9VKZ0yN4XO/DXNfcaqskjPD6gxzReENXufe1xrKHDpxhem/rFfOmOpeshiOJG TpL/XkwBcwZOK3gj0aYJdlz5I14LdJCHyeW8uT83oD11AzTl/tX11uoHvP8efjJS Rh54= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 11 Apr 2013 13:53:49 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 201564915.6801.5500; Thu, 11 Apr 2013 13:53:48 -0400 Message-ID: <5166F870.30700@isdg.net> Date: Thu, 11 Apr 2013 13:52:48 -0400 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: S Moonesamy References: <6.2.5.6.2.20130411030449.0ce5be80@elandnews.com> In-Reply-To: <6.2.5.6.2.20130411030449.0ce5be80@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Implementation status of 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: Thu, 11 Apr 2013 17:54:49 -0000 Hi, SM as you made aware, I had a heart attack this pass June 2012 and I have been on a 1 year sabbatical to regained my health and healthier living. As part of my stress management, I have also minimized my IETF participation. For SPF, I do wish for it to be properly completed some day, but I do wish to get all my concerns all out now and not dwell much time with it. I won't be getting into debates. I will use your questionnaire as an entry point for my WGLC comments and all I wish to say about SPF, our implementation and the concerns with 4408BIS. See inline comments. Thanks On 4/11/2013 6:17 AM, S Moonesamy wrote: > > (a) Implementation name wcSPF as part wcSAP - Wildcat! Sender Authentication Protocol > (b) Description of implementation (please include a link to a > web page if it contains information about the implementation) wcSPF is part of a suite of testing tools lump together under WCSAP. For a technical interest, the default order of where SPF calls in the testing is: SAPFLT - Rules written by the sysop. SAPRBL - DNS RBL sites, default is spamcop SAPSPF - SPF check, rejects (550) on a -ALL failed policies SAPCBV - Call-Back Verifier (CBV), based on a SMTP Return path MUST be VALID design premise. http://www.winserver.com/public/Security http://www.winserver.com/public/aup/topic-wcsap.htm#SAPSPF (not all newer options are show here, thanks for the reminder, jotted down). A wcSAP testing Site was implemented since 2003: http://www.winserver.com/public/wcsap.wcx Ten years of SPF-based reject statistics has been collected daily: http://www.winserver.com/public/antispam For comparison, I would like to know of any other implementation with the steady accumulated data over MARID 2003. Statistics for SMTP rejections show the growth over the years of hard fail SPF policies from negligible 0.00% in 2003 to as high as 20% today 2013! Default installation for all customers enabled wcSPF and honors a SMTP reject policy for SPF hard fails domain policies. Deployments CAN NOT currently change the reject but they can change/set the SMTP reply code. > (c) The versions of the draft which were implemented > (c) The parts of draft-ietf-spfbis-4408bis which were implemented SPF was implemented circa 2003 starting with the MARID era SPF draft specifications and later the full RFC 4408 when completed but not much was changed other than setting recursion limits (total count limit). This was needed because there were clear immediate support issues due to reaching software stack limitations with a very few amount of SPF policies. But catches of errors and using 45x (using "fail-safe" approaches early on during the exploration) caused redundant sender retries. I believe it was finally updated and set to a permerror and a 55x to at least stop the redundant retries. There is only one thing about this 4408bis draft that encouraged me to explore and it is source of major engineering dilemma I have with this SPF BIS effort. That is adding the option to FAIL-ACCEPT a transaction as opposed to what is currently implemented - FAIL-REJECT. I strongly believed a FAIL-REJECT was the intent and only intent for a SPF hard failure. What a receiver actually does, well that depends on the implementation and also the administrator. Sure, it can do what it wants, but in my strong opinion the protocol intent was for rejection. I am concern that this 4408BIS doc will lower the high 20% rejection we are realizing over the past 10 years or at least keep it at this level assuming that this document will not encourage SPF -ALL domains to relax to a SOFTFAIL (~ALL) which in my opinion is a wasteful policy which causes more wasted DNS traffic unless it is coupled with something else. What is that "Something Else?" Its not common, I would suggest. Why would domains change it? Well, it would be, IMV, due to better support AUTH-RES because I would suggest most (by packages, not by volume) are using Received-SPF headers and nothing (N/A) for FAIL-REJECT approaches. That is what I wanted to do. We added AUTH-REF for DKIM and ADSP so why not for SPF as well. It make sense. Unfortunately, we will need to drastically change our backend in order to secure (by separation) a FAIL-ACCEPT transaction. The document did address/touch based with this security issue, but not enough emphasis on the separation part. I believe it would be part of the SPF Protocol for a FAIL-ACCEPT design option. It is important for others to be aware of this who fall in the same current design predicament (they always rejected the -ALL). We can't use say that based on PARETO, most SPF implementers already do a FAIL-ACCEPT, but what I haven't heard that they ALL also separate the mail. It must be done others for a POP3 pick up, you would be passsing the failed message to the end-user and unless he has a super smart MUA offline reader that is not only SPF ready, but also "Received-SPF: fail" and/or "Auth-Res; spf=Fail" ready as well. Nonetheless, this issue regarding FAIL-ACCEPT plus a few others I have outlined here are the basic issues I have with this BIS: 1) SPF "payoff" value will be lower, less need to use it. Too much DNS overhead will be realized. 2) Higher Development cost in adding a FAIL-ACCEPT PLUS A MAIL SEPARATION design I feel is required to support this FAIL-ACCEPT logic. 3) AUTH-RES is incomplete. I don't think we should need to kludge the reporting using comments parts of this particular trace line. 4) Lack of SUBMITTER support. The Check-Function is too limited. Doesn't match reality or at a minimum, fails to acknowledge it and how it COULD BE implemented and used. 5) Minor: I do think the BIS is very verbose. I don't need to support this for the two extra new (more emphasis) things about this BIS (FAIL-ACCEPT, AUTH-RES). I am not sure yet if I should endorse, encourage, recognize it for usage. Not if its going to alter how domains set their policies. Worst case is domains who currently follow -ALL and they relax it to ~ALL because of 4408BIS, not because they have to for technical reasons. Perhaps they because that MOST systems already have some other exploration thing related to DMARC or some other MFA (Mail Filtering Agent) thing going on. If they did, we are not currently ready to support that, DMARC or anything else. In that way, its more of a possible concern in seeing a lower payoff until we do a FAIL-ACCEPT-SEPARATION SPF design. -- Hector Santos, CTO/CEO Santronics Software, Inc. From hsantos@isdg.net Thu Apr 11 11:14: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 CE4AF21F898A for ; Thu, 11 Apr 2013 11:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP5osImulr+F for ; Thu, 11 Apr 2013 11:14:07 -0700 (PDT) Received: from dkim.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 89C0421F8976 for ; Thu, 11 Apr 2013 11:14:07 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7695; t=1365704041; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=QeOm6dx cfV/J5maZKhC0iuVaA+Y=; b=u0y8ZsPvYQKeblIPCmwfzbBkI75c314TptqpcRu /WdFITl3HGpqoFm1Zg0eh5sbo00xWtAkliRyvTtQ1ZuviwPnrlpC+czpJcPbJC4b 8ydPugq/GSGup4T2Cy5WJOli5qOQELMh2StfxKSj4oaDq6JeyOSX6TGIUTNVpYf8 Ydv8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 11 Apr 2013 14:14:01 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 202776777.6801.3284; Thu, 11 Apr 2013 14:14:00 -0400 Message-ID: <5166FD2C.8050406@isdg.net> Date: Thu, 11 Apr 2013 14:13:00 -0400 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: S Moonesamy References: <6.2.5.6.2.20130411030449.0ce5be80@elandnews.com> <5166F870.30700@isdg.net> In-Reply-To: <5166F870.30700@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Implementation status of 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: Thu, 11 Apr 2013 18:14:08 -0000 I forgot to outline this additional concern: 6) SPF records with PTR As described in our documentation section titled SPF Records for Wildcat! Sysops http://www.winserver.com/public/aup/topic-wcsap.htm#SAPSPF We encourage the usage the PTR for simplicity and generality. Less DNS management requirement, means less support cost for our customers and us as well. 4408BIS will cause this to change. Questions will be for us: Do we want to change our recommendations? Is there a harm by not following it? There was a higher harm in the past, but believe it is lesser today. Do we need to do this? On 4/11/2013 1:52 PM, Hector Santos wrote: > > Hi, SM as you made aware, I had a heart attack this pass June 2012 and I > have been on a 1 year sabbatical to regained my health and healthier > living. As part of my stress management, I have also minimized my IETF > participation. > > For SPF, I do wish for it to be properly completed some day, but I do > wish to get all my concerns all out now and not dwell much time with it. > I won't be getting into debates. I will use your questionnaire as an > entry point for my WGLC comments and all I wish to say about SPF, our > implementation and the concerns with 4408BIS. > > See inline comments. > > Thanks > > > On 4/11/2013 6:17 AM, S Moonesamy wrote: >> >> (a) Implementation name > > wcSPF as part wcSAP - Wildcat! Sender Authentication Protocol > > >> (b) Description of implementation (please include a link to a >> web page if it contains information about the implementation) > > wcSPF is part of a suite of testing tools lump together under WCSAP. For > a technical interest, the default order of where SPF calls in the > testing is: > > SAPFLT - Rules written by the sysop. > > SAPRBL - DNS RBL sites, default is spamcop > > SAPSPF - SPF check, rejects (550) on a -ALL failed policies > > SAPCBV - Call-Back Verifier (CBV), based on a SMTP > Return path MUST be VALID design premise. > > http://www.winserver.com/public/Security > http://www.winserver.com/public/aup/topic-wcsap.htm#SAPSPF > (not all newer options are show here, thanks for the reminder, jotted > down). > > A wcSAP testing Site was implemented since 2003: > > http://www.winserver.com/public/wcsap.wcx > > Ten years of SPF-based reject statistics has been collected daily: > > http://www.winserver.com/public/antispam > > For comparison, I would like to know of any other implementation with > the steady accumulated data over MARID 2003. Statistics for SMTP > rejections show the growth over the years of hard fail SPF policies from > negligible 0.00% in 2003 to as high as 20% today 2013! > > Default installation for all customers enabled wcSPF and honors a SMTP > reject policy for SPF hard fails domain policies. Deployments CAN NOT > currently change the reject but they can change/set the SMTP reply code. > >> (c) The versions of the draft which were implemented >> (c) The parts of draft-ietf-spfbis-4408bis which were implemented > > SPF was implemented circa 2003 starting with the MARID era SPF draft > specifications and later the full RFC 4408 when completed but not much > was changed other than setting recursion limits (total count limit). > > This was needed because there were clear immediate support issues due to > reaching software stack limitations with a very few amount of SPF > policies. But catches of errors and using 45x (using "fail-safe" > approaches early on during the exploration) caused redundant sender > retries. I believe it was finally updated and set to a permerror and a > 55x to at least stop the redundant retries. > > There is only one thing about this 4408bis draft that encouraged me to > explore and it is source of major engineering dilemma I have with this > SPF BIS effort. That is adding the option to FAIL-ACCEPT a transaction > as opposed to what is currently implemented - FAIL-REJECT. I strongly > believed a FAIL-REJECT was the intent and only intent for a SPF hard > failure. What a receiver actually does, well that depends on the > implementation and also the administrator. Sure, it can do what it > wants, but in my strong opinion the protocol intent was for rejection. > > I am concern that this 4408BIS doc will lower the high 20% rejection we > are realizing over the past 10 years or at least keep it at this level > assuming that this document will not encourage SPF -ALL domains to relax > to a SOFTFAIL (~ALL) which in my opinion is a wasteful policy which > causes more wasted DNS traffic unless it is coupled with something else. > What is that "Something Else?" Its not common, I would suggest. > > Why would domains change it? Well, it would be, IMV, due to better > support AUTH-RES because I would suggest most (by packages, not by > volume) are using Received-SPF headers and nothing (N/A) for FAIL-REJECT > approaches. That is what I wanted to do. We added AUTH-REF for DKIM > and ADSP so why not for SPF as well. It make sense. > > Unfortunately, we will need to drastically change our backend in order > to secure (by separation) a FAIL-ACCEPT transaction. The document did > address/touch based with this security issue, but not enough emphasis on > the separation part. I believe it would be part of the SPF Protocol for > a FAIL-ACCEPT design option. It is important for others to be aware of > this who fall in the same current design predicament (they always > rejected the -ALL). We can't use say that based on PARETO, most SPF > implementers already do a FAIL-ACCEPT, but what I haven't heard that > they ALL also separate the mail. It must be done others for a POP3 pick > up, you would be passsing the failed message to the end-user and unless > he has a super smart MUA offline reader that is not only SPF ready, but > also "Received-SPF: fail" and/or "Auth-Res; spf=Fail" ready as well. > > Nonetheless, this issue regarding FAIL-ACCEPT plus a few others I have > outlined here are the basic issues I have with this BIS: > > 1) SPF "payoff" value will be lower, less need to use it. Too much DNS > overhead will be realized. > > 2) Higher Development cost in adding a FAIL-ACCEPT PLUS A MAIL > SEPARATION design I feel is required to support this FAIL-ACCEPT logic. > > 3) AUTH-RES is incomplete. I don't think we should need to kludge the > reporting using comments parts of this particular trace line. > > 4) Lack of SUBMITTER support. The Check-Function is too limited. > Doesn't match reality or at a minimum, fails to acknowledge it and how > it COULD BE implemented and used. > > 5) Minor: I do think the BIS is very verbose. > > I don't need to support this for the two extra new (more emphasis) > things about this BIS (FAIL-ACCEPT, AUTH-RES). I am not sure yet if I > should endorse, encourage, recognize it for usage. Not if its going to > alter how domains set their policies. Worst case is domains who > currently follow -ALL and they relax it to ~ALL because of 4408BIS, not > because they have to for technical reasons. Perhaps they because that > MOST systems already have some other exploration thing related to DMARC > or some other MFA (Mail Filtering Agent) thing going on. If they did, > we are not currently ready to support that, DMARC or anything else. In > that way, its more of a possible concern in seeing a lower payoff until > we do a FAIL-ACCEPT-SEPARATION SPF design. > > -- > Hector Santos, CTO/CEO > Santronics Software, Inc. > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From spf2@kitterman.com Thu Apr 11 13:33: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 CAD3021F896C for ; Thu, 11 Apr 2013 13:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjk1+uuDPOve for ; Thu, 11 Apr 2013 13:33:34 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2581D21F8940 for ; Thu, 11 Apr 2013 13:33:34 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A798B20E40CF; Thu, 11 Apr 2013 16:33:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365712413; bh=1pdwpLDNHmA8ms4JC9wpo4kjPjdgL28hSBsb7/14Kjk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fpaQCC0Kh1zbf5+qNmJr59zzjJO0JzmSYgqHkB4xrqkGoDvv80Cq/GeC8o73sVj3M 8euXUR4jBU9Z0X0bTGztQOvRYuNYvalErYIzYl1h50nJ38Ol8APdK5fvwrjictZuns jzs8qz2nOgDdyQNGpnY0pqoUDwN92ICVeg3P6IGc= 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 89DA720E409E; Thu, 11 Apr 2013 16:33:33 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 11 Apr 2013 16:33:32 -0400 Message-ID: <1582356.eAhFEajm5r@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130411030449.0ce5be80@elandnews.com> References: <6.2.5.6.2.20130411030449.0ce5be80@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] Implementation status of 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: Thu, 11 Apr 2013 20:33:34 -0000 On Thursday, April 11, 2013 03:17:47 AM S Moonesamy wrote: > Hello, > > I would like to have some information about the implementation of > draft-ietf-spfbis-4408bis [1]. If you have implemented the draft, > could you please send me the following information: > > (a) Implementation name > > (b) Description of implementation (please include a link to a > web page if it contains information about the implementation) > > (c) The versions of the draft which were implemented > > (c) The parts of draft-ietf-spfbis-4408bis which were implemented > > Regards, > S. Moonesamy > > 1. http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-14 Here's a list of known SPF implementations, mostly based on RFC 4408: http://www.openspf.org/Implementations Given the minimal changes in functional requirements in 4408bis, I think they should still count in the mix some how. Scott K From hsantos@isdg.net Thu Apr 11 13:51: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 7740A21F9005 for ; Thu, 11 Apr 2013 13:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxXq2Z2Dl0Dw for ; Thu, 11 Apr 2013 13:51:20 -0700 (PDT) Received: from dkim.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6239D21F902D for ; Thu, 11 Apr 2013 13:51:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1921; t=1365713472; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=VyGfDEh bU7JbOBR5+GTXynLmrzQ=; b=TH52x0754zLWqCgcn2SZtNAg/AM17qyjO1e1KPu 32uZ3OmtAN7QQc61VjcRsIzDT490Z04S39Ew/YNHQ8F/DqDwJVuStc/Ko9veytEH adhNrV1OE4xxEZmJJL94vxdXcnY5+JS4Qk2O42g9PP9I3Qod3+vOW8g63eZ3LxmX Yr90= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 11 Apr 2013 16:51:12 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 212208177.6801.3792; Thu, 11 Apr 2013 16:51:11 -0400 Message-ID: <51672203.8050904@isdg.net> Date: Thu, 11 Apr 2013 16:50:11 -0400 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: <6.2.5.6.2.20130411030449.0ce5be80@elandnews.com> <1582356.eAhFEajm5r@scott-latitude-e6320> In-Reply-To: <1582356.eAhFEajm5r@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Implementation status of 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: Thu, 11 Apr 2013 20:51:23 -0000 I believe it would be very productive for most people who are just scanning/perusing this stuff if you can summarize what are the key considerations and changes per software change needs, if any. - New Fail Accept Considerations - No more Type 99 considerations - Recommendation to not publish PTR directives in policies. - New consideration for AUTH-RES to use with and/or replace Received-SPF - Not 100% direct replacement What else? In other words, are there any surprises? is it PnP (Plug and Play) ready? Do people need to change software? Change setups? in order to declare they are (still) "compatible" with 4408BIS? What happens if no one supports 4408BIS? If there any harm if no one follows it, like doesn't change PTR to direct IPx directives? -- HLS On 4/11/2013 4:33 PM, Scott Kitterman wrote: > On Thursday, April 11, 2013 03:17:47 AM S Moonesamy wrote: >> Hello, >> >> I would like to have some information about the implementation of >> draft-ietf-spfbis-4408bis [1]. If you have implemented the draft, >> could you please send me the following information: >> >> (a) Implementation name >> >> (b) Description of implementation (please include a link to a >> web page if it contains information about the implementation) >> >> (c) The versions of the draft which were implemented >> >> (c) The parts of draft-ietf-spfbis-4408bis which were implemented >> >> Regards, >> S. Moonesamy >> >> 1. http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-14 > > Here's a list of known SPF implementations, mostly based on RFC 4408: > > http://www.openspf.org/Implementations > > Given the minimal changes in functional requirements in 4408bis, I think they > should still count in the mix some how. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From superuser@gmail.com Thu Apr 11 16:41: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 E90B121F86B7 for ; Thu, 11 Apr 2013 16:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdLfNuuF+x2U for ; Thu, 11 Apr 2013 16:41:21 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 336D421F8574 for ; Thu, 11 Apr 2013 16:41:21 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hm14so1098182wib.4 for ; Thu, 11 Apr 2013 16:41:20 -0700 (PDT) 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:content-type; bh=2e6Wr11hFZvl9Y040Xj28H7NDJ+GU8HfzFFDF7xgOMU=; b=r9oNhBygBrahJy7CrpO+DKAbEb5OuDNyZyv1dlSu6Wqy5LaUmhznIx0Xp2BOYw8qvG zeR/wZJg6hHEvD0Qkg1Ga4PiN2tMCsdbKLpIdTSnT0oC7obkhH1H6kww1wpFAAvA0E/R 4/PlX8es7Zb8mVqKNR3zU5TaZ4ajvTHrZ4tGJIHzT4gddoy+WqRk1h/omIlicGv9nFza RyH4pcTOh1KrQRUFlw8hbKBYzvZ+m72ZHVKyQxUGuGDY3312jBzYgyZD8tN+z7bWXXQA +5LaVpJykOFirPOXB/xS+JYqsAPIaBZEkt5azfE7XwaupkTjKk0YXJNgg0X5E9EP64gj m8Kg== MIME-Version: 1.0 X-Received: by 10.180.84.162 with SMTP id a2mr566518wiz.14.1365723680352; Thu, 11 Apr 2013 16:41:20 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 11 Apr 2013 16:41:20 -0700 (PDT) In-Reply-To: <51672203.8050904@isdg.net> References: <6.2.5.6.2.20130411030449.0ce5be80@elandnews.com> <1582356.eAhFEajm5r@scott-latitude-e6320> <51672203.8050904@isdg.net> Date: Thu, 11 Apr 2013 16:41:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=f46d04427194d4311c04da1e52f5 Subject: Re: [spfbis] Implementation status of 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: Thu, 11 Apr 2013 23:41:22 -0000 --f46d04427194d4311c04da1e52f5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 11, 2013 at 1:50 PM, Hector Santos wrote: > I believe it would be very productive for most people who are just > scanning/perusing this stuff if you can summarize what are the key > considerations and changes per software change needs, if any. > Answering as if I still maintained sid-milter: > > - New Fail Accept Considerations > None; we always put the action-on-fail in the hands of the user, and defaulted it to add an A-R header field and pass the message. > - No more Type 99 considerations > None; we never queried type 99. > - Recommendation to not publish PTR directives in policies. > None; 4408bis didn't remove support for PTR, only discouraged it. I wouldn't change anything here. > - New consideration for AUTH-RES to use with and/or replace Received-SPF > - Not 100% direct replacement > None; we never implemented Received-SPF. -MSK --f46d04427194d4311c04da1e52f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 11, 2013 at 1:50 PM, Hector Santos <hsantos@= isdg.net> wrote:
I believe it would be very productive for mo= st people who are just scanning/perusing this stuff if you can summarize wh= at are the key considerations and changes per software change needs, if any= .

Answering as if I still maintained sid-mil= ter:
=A0

- New Fail Accept Considerations

None; = we always put the action-on-fail in the hands of the user, and defaulted it= to add an A-R header field and pass the message.
=A0
- No more Type 99 considerations

None; = we never queried type 99.
=A0
- Recommendation to not publish PTR directives in policies.

None; 4408bis didn't remove support for PTR, only = discouraged it.=A0 I wouldn't change anything here.
=A0
- New consideration for AUTH-RES to use with and/or replace Received-SPF =A0 =A0- Not 100% direct replacement

No= ne; we never implemented Received-SPF.

-MSK
--f46d04427194d4311c04da1e52f5-- From sm@elandsys.com Fri Apr 12 02:32: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 9A32121F88B9 for ; Fri, 12 Apr 2013 02:32:38 -0700 (PDT) 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.015, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfbOZuVNdU+Z for ; Fri, 12 Apr 2013 02:32:38 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0AA21F878F for ; Fri, 12 Apr 2013 02:32:37 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.150.183]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3C9WOGU008918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Apr 2013 02:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365759156; bh=Vs7kd5BEcjszfDYJJa5apTGUJs4TcedmYAu3sZoh4aI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=e4Pp+pKvSgURQ36XIi8/ir5nc2mnTRfpizjKPLz1vowU8KuTQgL6+n68NsgObMKFP qPEvtOKoz7op42R14vIigHlGFs5bem7H62Uj1Rx1gCzcW6GNvLBy6nj14ymEoAVo0T LJkyKKGf/iFI67SaA3qkLYmNShLxB1cPuMn14TpE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1365759156; i=@elandsys.com; bh=Vs7kd5BEcjszfDYJJa5apTGUJs4TcedmYAu3sZoh4aI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=L9WHNlLL2BJ1aM1sepjMS+dn1xgRdDEdjhzm5kpunEfy4oB5M9yi5WWFQXLWCrrMc oMthvoq4BQ8/9p03+m15+v7v2SrCEmpDtSaW9rTqCtulj56rtAWrsulBnJJFSLW5re lcNMDDHH09Ed4nBTNDnSgHkgXc7Q4j6cwHlSLQ2M= Message-Id: <6.2.5.6.2.20130411230835.0c352db8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 11 Apr 2013 23:22:32 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <5166F870.30700@isdg.net> References: <6.2.5.6.2.20130411030449.0ce5be80@elandnews.com> <5166F870.30700@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Implementation status of 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, 12 Apr 2013 09:32:38 -0000 Hi Hector, At 10:52 11-04-2013, Hector Santos wrote: >Hi, SM as you made aware, I had a heart attack this pass June 2012 >and I have been on a 1 year sabbatical to regained my health and >healthier living. As part of my stress management, I have also >minimized my IETF participation. I hope that you are getting better. >For SPF, I do wish for it to be properly completed some day, but I >do wish to get all my concerns all out now and not dwell much time >with it. I won't be getting into debates. I will use your >questionnaire as an entry point for my WGLC comments and all I wish >to say about SPF, our implementation and the concerns with 4408BIS. I'll comment as document shepherd for draft-ietf-spfbis-4408bis. If there are any concerns that you consider as not addressed after the end of the WGLC please send me an message about them. I will include them in my write-up or bring them to the attention of the Responsible Area Director. Regards, S. Moonesamy From sm@elandsys.com Mon Apr 15 03:16: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 7494E21F9377 for ; Mon, 15 Apr 2013 03:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orK6rKF-2m9H for ; Mon, 15 Apr 2013 03:15:59 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C911321F9354 for ; Mon, 15 Apr 2013 03:15:52 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.42]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3FACbws017488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Apr 2013 03:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366020782; bh=AlpA4Iagk6o4lqvEXCq9jOjNsz0HdZenImW1sJ2oO+g=; h=Date:To:From:Subject:In-Reply-To:References; b=2/MI9+91NKE3CPMovYE8a2pkUctCUGu+szWMy28UyYc0NwOgcv8njQ9q3c9CcTVkg wSonsE0KMTyPSezDB97EJHmWgxMXx+ozXtxLSbWNeyU4SzVR17I5GAuZ4jMv3DU17S iB6htrT1c5BXEATe8yCUs5u7bFj5iyQUTAJqLkOQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366020782; i=@elandsys.com; bh=AlpA4Iagk6o4lqvEXCq9jOjNsz0HdZenImW1sJ2oO+g=; h=Date:To:From:Subject:In-Reply-To:References; b=4rWG07kDBhL8t7SH7i6flU99jXdjRCdkNvtWog3cE8wnD2SWN+DQA4TbpOtB+VL9z 2pnlGfrWG6iJPP/5lUcQ6pWLQmgCHs+nFJSAzhoZFGU+TKpWJW9OnhBnTffhJSAZVJ HncHJHVQNLVzRd3NIuOqt0AXKPxvOfXkFSMy/xZE= Message-Id: <6.2.5.6.2.20130415005153.0b0f96c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 15 Apr 2013 03:12:36 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1582356.eAhFEajm5r@scott-latitude-e6320> References: <6.2.5.6.2.20130411030449.0ce5be80@elandnews.com> <1582356.eAhFEajm5r@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Implementation status of 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: Mon, 15 Apr 2013 10:16:00 -0000 At 13:33 11-04-2013, Scott Kitterman wrote: >Here's a list of known SPF implementations, mostly based on RFC 4408: > >http://www.openspf.org/Implementations > >Given the minimal changes in functional requirements in 4408bis, I think they >should still count in the mix some how. I'll try and get more information about the implementation status of draft-ietf-spfbis-4408bis by sending this message (Bcc) to the email addresses listed on the web page. Please see the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg03347.html for more context. The list of changes to the SPF specification is in Appendix J ( http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-14 ). Regards, S. Moonesamy From spf2@kitterman.com Tue Apr 16 18:51: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 5E65421F9743 for ; Tue, 16 Apr 2013 18:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh9P5zu09Lm7 for ; Tue, 16 Apr 2013 18:51:08 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B3B2321F95FE for ; Tue, 16 Apr 2013 18:51:08 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3C35B20E40FC; Tue, 16 Apr 2013 21:51:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366163468; bh=h9XFZ86yxzBcMP2qGCnP0fHlLHuJLeUpSTki0+oo2og=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jIUc1JLx1globPkpJmr9qNrpVsOxYtjU9ydO+8VbSJjLQIBPsOTGlYnh3UmtAJl9j lJ3oexdwOEthVPhnfMGwvOLLUsFlmPG8UooSkss5//cF2bVXzxq08tVyQCV9HvOe2q Cgn/MMa4HMqVtLOuadMKdrak3F19sA+hVUhQzX/U= 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 1F26620E40C6; Tue, 16 Apr 2013 21:51:07 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 16 Apr 2013 21:51:07 -0400 Message-ID: <9424963.YHzqPUZEKJ@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <20130409062431.GK24624@mx1.yitter.info> References: <20130409062431.GK24624@mx1.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 17 Apr 2013 01:51:09 -0000 On Tuesday, April 09, 2013 02:24:32 AM Andrew Sullivan wrote: > Dear colleagues, > > This message initiates a two-week working group last call on > draft-ietf-spfbis-4408bis-14, our only work item. > > The draft has been through 14 revisions, and all open issues in the > tracker are closed. Please review the document and indicate any > comments you have by sending a note to the mailing list. If you have > no comments, it is valuable nevertheless to learn that you have read > the document and support its publication. > > WGLC will close at 2014-04-24 00:00 UTC. > > SM will be the shepherd for this document. > > Best regards, > > Andrew (for the chairs) Just as a reminder, we're ~half way through the WGLC period and things have been very quiet. Please don't save all your reviews/comments until the end. Scott K From dotzero@gmail.com Tue Apr 16 19:08: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 8030221F8E7C for ; Tue, 16 Apr 2013 19:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDe9PdyVH1kB for ; Tue, 16 Apr 2013 19:08:13 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7A50421F8E62 for ; Tue, 16 Apr 2013 19:08:13 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id w20so1138322lbh.4 for ; Tue, 16 Apr 2013 19:08:12 -0700 (PDT) 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=bNwklTc3BEEq5q0Mw8rSyBpzxEJi4f981dyqKMlnwi4=; b=hENFlYC9n8vqd/SZtW29MHXARjk/2gladG0Hj92rfZFXiTZolHHVOZt1BzzUB8DYKQ xI16KVclL5CoBDx+//Om1bqkUrDv2FVL2qjwmAgSEr5q+s3l3ipw8qy0vHo9Ck+/8Ras Y+4zVdpQ7VBbMv9jmib3LCSf4bRhrrdOCPVAK1Y1OMToEoTBRmML3aRMYGaRMrN3LRhy BgyIklEvTExqixgvtY6paUj5GgGFdUFs+EkSLQk3IG2rTB5CxYWTSH9/sp32kdbN+5o8 uvsoUA7W/9Tcnj2dWuM5jVDaQwe2raWKVnBqUtl2XMhmmrV3x4WAvGfdYSZACBE+qrnB OppQ== MIME-Version: 1.0 X-Received: by 10.152.45.37 with SMTP id j5mr2475308lam.9.1366164492423; Tue, 16 Apr 2013 19:08:12 -0700 (PDT) Received: by 10.112.72.166 with HTTP; Tue, 16 Apr 2013 19:08:12 -0700 (PDT) In-Reply-To: <20130409062431.GK24624@mx1.yitter.info> References: <20130409062431.GK24624@mx1.yitter.info> Date: Tue, 16 Apr 2013 22:08:12 -0400 Message-ID: From: Dotzero To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 17 Apr 2013 02:08:14 -0000 I've reviewed the draft and have one "nit" and one question/comment: In the Abstract the use of ADMD should be followed with (ADministrative Management Domains) 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. For section 2.6.7. Permerror A "permerror" result means the domain's published records could not be correctly interpreted. This signals an error condition that definitely requires manual intervention to be resolved. Manual intervention by whom? Does this need to be clarified? Other than these two relatively minor details, nothing jumped out at me. Mike On Tue, Apr 9, 2013 at 2:24 AM, Andrew Sullivan wrote: > Dear colleagues, > > This message initiates a two-week working group last call on > draft-ietf-spfbis-4408bis-14, our only work item. > > The draft has been through 14 revisions, and all open issues in the > tracker are closed. Please review the document and indicate any > comments you have by sending a note to the mailing list. If you have > no comments, it is valuable nevertheless to learn that you have read > the document and support its publication. > > WGLC will close at 2014-04-24 00:00 UTC. > > SM will be the shepherd for this document. > > Best regards, > > Andrew (for the chairs) > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From tim@eudaemon.net Tue Apr 16 19:10: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 6D38721F93BA for ; Tue, 16 Apr 2013 19:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYB4jCVDobf0 for ; Tue, 16 Apr 2013 19:10:01 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id E39D621F8EBB for ; Tue, 16 Apr 2013 19:10:00 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id D1BA5CB46; Tue, 16 Apr 2013 22:10:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Draegen In-Reply-To: Date: Tue, 16 Apr 2013 22:10:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7FE87BAF-B202-4CD5-B7BA-EDABE151E142@eudaemon.net> References: <20130409062431.GK24624@mx1.yitter.info> To: Dotzero X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 17 Apr 2013 02:10:01 -0000 On Apr 16, 2013, at 10:08 PM, Dotzero wrote: > I've reviewed the draft and have one "nit" and one question/comment: >=20 > In the Abstract the use of ADMD should be followed with > (ADministrative Management Domains) >=20 > 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. Oh dude! Get out of my head! I'm reviewing the document (about 5 = minutes in) and this was my first note!= From dotzero@gmail.com Tue Apr 16 19:43: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 91EA321F8E62 for ; Tue, 16 Apr 2013 19:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lmFEXUslQUD for ; Tue, 16 Apr 2013 19:42:59 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 0F65421F9697 for ; Tue, 16 Apr 2013 19:42:46 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id p11so1169582lbi.14 for ; Tue, 16 Apr 2013 19:42:46 -0700 (PDT) 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=0Pqk6BH7iS8Yj55vbDmTjZDxPI6m6x5MAi6Gm72Tdew=; b=NFrJKZAxYylha0+QRrBoLqr4xA/dPyCoqvxI5Ctfv1vWxEFTWKl1ZfGX4djDv3rUnf Lt2AII8EfSJ7lH29WVqO7AaXLdNgS6q6RRyTuiJ8E7uQHiQxr1gv/sNFFxIUHD/QV6RK 8bor2JkZBRZ9rh3hrvi0sChmyqBbPXQmDCVrXT57UMolJz+UsZJxMZcuTScvhN0vkgqi uGLfj3msU79akdg5YrWSBZ12vOI8VPQukOiZCW9uUIpCkwYFgjKb35xO+mQ8+124DIEK ypVfmHsL+n8cfNO9asq9JvSvRUX3GN4b+H3eke9Gs6fqWF01pDRVp1h6Jd4Mqa1HhVEa Bzzg== MIME-Version: 1.0 X-Received: by 10.112.170.7 with SMTP id ai7mr2637213lbc.42.1366166564829; Tue, 16 Apr 2013 19:42:44 -0700 (PDT) Received: by 10.112.72.166 with HTTP; Tue, 16 Apr 2013 19:42:44 -0700 (PDT) In-Reply-To: <7FE87BAF-B202-4CD5-B7BA-EDABE151E142@eudaemon.net> References: <20130409062431.GK24624@mx1.yitter.info> <7FE87BAF-B202-4CD5-B7BA-EDABE151E142@eudaemon.net> Date: Tue, 16 Apr 2013 22:42:44 -0400 Message-ID: From: Dotzero To: Tim Draegen Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 17 Apr 2013 02:43:02 -0000 On Tue, Apr 16, 2013 at 10:10 PM, Tim Draegen wrote: > On Apr 16, 2013, at 10:08 PM, Dotzero wrote: >> I've reviewed the draft and have one "nit" and one question/comment: >> >> In the Abstract the use of ADMD should be followed with >> (ADministrative Management Domains) >> >> 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. > > Oh dude! Get out of my head! I'm reviewing the document (about 5 minutes in) and this was my first note! At least what I found is relatively minor in the greater scheme of things. Reading the whole thing thoughtfully is so different from going back and forth on individual items. Mike From superuser@gmail.com Tue Apr 16 20:02: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 A6B7E21F8E9A for ; Tue, 16 Apr 2013 20:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTB-nGIa7eFG for ; Tue, 16 Apr 2013 20:02:53 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3871821F8526 for ; Tue, 16 Apr 2013 20:02:53 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id z2so914863wey.1 for ; Tue, 16 Apr 2013 20:02:51 -0700 (PDT) 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=hW/2GcS04d6Utw8O0ZMD0Mi0jy8f/hHRxyM2b/zYSB0=; b=iVOJvf0PcYQyrI9NvxO8puQQPQ67Vvg7Ko3ojL72YGwymzFc8U/AMzVVo78NVk0fAq tV2xFs3LaOTD029ReniaHXfAaiFYWFf7dphVQBw8JQSdLf7BuMNuUW5nT4WiRof10nqn WYGdVts2QsAJAc4ynup0CS5pxSpsc2APjTHM6a4S9nuxJvKQDe0xws4t/Zu3TtodhGN7 nlEFqWZMOPRPR5pRz997ppVW1cUSAauM5b/gg8pC+40YCldxk4uMqSReA3EiBcJCmZ2M NRSwvvzx8+rY6WYOZsvv+vFSvpxZuvEeHkhN72pn2cL44tixiU3jryvNa/e3ovhd7wot p0cQ== MIME-Version: 1.0 X-Received: by 10.180.84.162 with SMTP id a2mr7663694wiz.14.1366167771916; Tue, 16 Apr 2013 20:02:51 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Tue, 16 Apr 2013 20:02:51 -0700 (PDT) In-Reply-To: References: <20130409062431.GK24624@mx1.yitter.info> <7FE87BAF-B202-4CD5-B7BA-EDABE151E142@eudaemon.net> Date: Tue, 16 Apr 2013 20:02:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dotzero Content-Type: multipart/alternative; boundary=f46d04427194bfb47b04da85b83f Cc: "spfbis@ietf.org" , Tim Draegen , Andrew Sullivan Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 17 Apr 2013 03:02:54 -0000 --f46d04427194bfb47b04da85b83f Content-Type: text/plain; charset=ISO-8859-1 Apologies; I do plan to spend time on it this week. I've been buried with $DAYJOB, illness, travel, etc. lately and I'm quite behind on non-trivial IETF matters. On Tue, Apr 16, 2013 at 7:42 PM, Dotzero wrote: > On Tue, Apr 16, 2013 at 10:10 PM, Tim Draegen wrote: > > On Apr 16, 2013, at 10:08 PM, Dotzero wrote: > >> I've reviewed the draft and have one "nit" and one question/comment: > >> > >> In the Abstract the use of ADMD should be followed with > >> (ADministrative Management Domains) > >> > >> 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. > > > > Oh dude! Get out of my head! I'm reviewing the document (about 5 > minutes in) and this was my first note! > > At least what I found is relatively minor in the greater scheme of > things. Reading the whole thing thoughtfully is so different from > going back and forth on individual items. > > Mike > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d04427194bfb47b04da85b83f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Apologies; I do plan to spend time on it this week.=A0 I&#= 39;ve been buried with $DAYJOB, illness, travel, etc. lately and I'm qu= ite behind on non-trivial IETF matters.


On Tue, Apr 16, 2013 at 7:42 PM, Dotzero <d= otzero@gmail.com> wrote:
On Tue, Apr 16, 2013 at 10:10 PM, Tim Draegen <tim@eudaemon.net> wrote:
> On Apr 16, 2013, at 10:08 PM, Dotzero <dotzero@gmail.com> wrote:
>> I've reviewed the draft and have one "nit" and one q= uestion/comment:
>>
>> In the Abstract the use of ADMD should be followed with
>> (ADministrative Management Domains)
>>
>> =A0 Email on the Internet can be forged in a number of ways. =A0In=
>> =A0 particular, existing protocols place no restriction on what a = sending
>> =A0 host can use as the "MAIL FROM" of a message or the = domain given on
>> =A0 the SMTP HELO/EHLO commands. =A0This document describes versio= n 1 of
>> =A0 the Sender Policy Framework (SPF) protocol, whereby an ADMD ca= n
>> =A0 explicitly authorize the hosts that are allowed to use its dom= ain
>> =A0 names, and a receiving host can check such authorization.
>
> Oh dude! =A0 Get out of my head! =A0 I'm reviewing the document (a= bout 5 minutes in) and this was my first note!

At least what I found is relatively minor in the greater scheme of things. Reading the whole thing thoughtfully is so different from
going back and forth on individual items.

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

--f46d04427194bfb47b04da85b83f-- From tim@eudaemon.net Tue Apr 16 21:04: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 8DD5921F9794 for ; Tue, 16 Apr 2013 21:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMA0lTktGrlZ for ; Tue, 16 Apr 2013 21:04:05 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3E27821F8E47 for ; Tue, 16 Apr 2013 21:04:03 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 23981CB46; Wed, 17 Apr 2013 00:04:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Draegen In-Reply-To: <20130409062431.GK24624@mx1.yitter.info> Date: Wed, 17 Apr 2013 00:04:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1CB7A581-3E5E-436F-AFD8-B4434D84ABB5@eudaemon.net> References: <20130409062431.GK24624@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 17 Apr 2013 04:04:06 -0000 Read the document, support its publication. Notes from review: - Abstract mentioned ADMD before defined - extra quote first sentence of 2.2 - 2nd paragraph of 2.5 references "return-path", should be "MAIL FROM" - and 10.1.3, except the context references RFC5321 so might be ok - 10.2: missing ")" in first paragraph - Grammar nits in Appendix C. a lot of the bullets have naked = references at the end of sentences. Maybe put parenthesis around these? =3D- Tim From sm@elandsys.com Tue Apr 16 21:56: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 223CA21F97B3 for ; Tue, 16 Apr 2013 21:56:26 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqQKKZpOGgIi for ; Tue, 16 Apr 2013 21:56:23 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC3921F9636 for ; Tue, 16 Apr 2013 21:56:22 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.137]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3H4tBA5010151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 21:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366174523; bh=dd3kGrkZ36uO/sUsKYj5U0ye3tUoLNE3b6LW/omynDU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rX5LDU2fLs23j+inj484Y/ElOHFCp8YYkdNpXvr0xZMM1SPujSLrenck/kdHSz4ss 3uGHMwnADie7N+jbt7HiPP+nt4lNgoC3XsGpM306sKkP25e5VQO+CkxPatDVzrNL39 7taI3qV4vxOJFKDxengOeGpVDPRNwGJxJTRWdjB8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366174523; i=@elandsys.com; bh=dd3kGrkZ36uO/sUsKYj5U0ye3tUoLNE3b6LW/omynDU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EbizGLiOfkkVEymDn6WiOUgY+46xPaZbvIvLzgPZ7/pxjJpGcboOqKx4GIQEDonCB pFlSrTQbYmH7SZ7O6nI+4wc1ypsLAPKZx/jDXL7jyKgO7jSo/Mc8I+C2UNgE/Ch/pE OtXtFlBwoM2pWYJgAa9CrQ1tqLb/2i3W84pvXqxs= Message-Id: <6.2.5.6.2.20130416214029.0c16f0b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 16 Apr 2013 21:50:35 -0700 To: Dotzero , Tim Draegen From: S Moonesamy In-Reply-To: References: <20130409062431.GK24624@mx1.yitter.info> <7FE87BAF-B202-4CD5-B7BA-EDABE151E142@eudaemon.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 17 Apr 2013 04:56:26 -0000 Hi Mike, Tim, At 19:42 16-04-2013, Dotzero wrote: >At least what I found is relatively minor in the greater scheme of >things. Reading the whole thing thoughtfully is so different from >going back and forth on individual items. As Scott mentioned, things have been very quiet for this WGLC. It helps if there are people who read the draft as you did above as I can determine whether the working group reviewed the draft and is ok with it. Regards, S. Moonesamy (as document shepherd) From WebMaster@Commerco.Net Wed Apr 17 02:01: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 85C5021F8503 for ; Wed, 17 Apr 2013 02:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8338lCMX-1M for ; Wed, 17 Apr 2013 02:01:13 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3303921F8511 for ; Wed, 17 Apr 2013 02:01:13 -0700 (PDT) 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=EB6QV7p/F1HmdFeM9NBFq3eaJWglDtLiuvvKT+s8HDVeRmgR3jQ20jFH7YZmji02aHi2kUMB6sdiurI3jSIwuVgDdOSmH/1GE13K4y7qtXAoezsic4IqHrLcwOhZrLbgX4tOHCoaOMcP5cnSHMoPc7WdqLZ1UDnVBnWCO5jCI0s= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.6) with ESMTP (EHLO [10.240.241.49]); Wed, 17 Apr 2013 09:01:09 +0000 Message-ID: <516E64CE.5050509@Commerco.Net> Date: Wed, 17 Apr 2013 03:01:02 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andrew Sullivan References: <20130409062431.GK24624@mx1.yitter.info> In-Reply-To: <20130409062431.GK24624@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 17 Apr 2013 09:01:18 -0000 Having reviewed the draft again end to end, I had pretty much the same minor "nit" as Mike (AKA Dotzero) has already expressed on the list regarding expanding the ADMD acronym in the Abstract section. As the Abstract is the first place in the entire document where the ADMD acronym gets used, perhaps it should be expressed as ADministrative Management Domain (ADMD) to mirror what exists in Section 2.2.1. Originator of RFC5598, from whence the acronym comes, as later documented in the 4408bis-14 section 1. Introduction. Also perhaps the ADMDs (ADministrative Management Domains, see [RFC5598]), as it currently exists, should be ADministrative Management Domains (ADMDs, see[RFC5598]), closely mirroring the plural as seen in Section 2.3. Administrative Actors of RFC5598 with attribution to same as already exists in section 1. Introduction of SPFbis-4408bis-14. Overall, the work product contained in the SPFbis looks solid and all participants should be congratulated in helping to bring the SPFbis to this point. I think that special thanks to Editor Scott Kitterman and the co-chairs for all their work in keeping the process on track and constructive are in order. Finally, I also agree that the publication of this draft version (draft-ietf-spfbis-4408bis-14) should move forward with suggested changes at the editor's and co-chair's discretion. Best, Alan M. On 4/9/2013 12:24 AM, Andrew Sullivan wrote: > Dear colleagues, > > This message initiates a two-week working group last call on > draft-ietf-spfbis-4408bis-14, our only work item. > > The draft has been through 14 revisions, and all open issues in the > tracker are closed. Please review the document and indicate any > comments you have by sending a note to the mailing list. If you have > no comments, it is valuable nevertheless to learn that you have read > the document and support its publication. > > WGLC will close at 2014-04-24 00:00 UTC. > > SM will be the shepherd for this document. > > Best regards, > > Andrew (for the chairs) > From vesely@tana.it Thu Apr 18 10:44: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 5770121F8F2E for ; Thu, 18 Apr 2013 10:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.337 X-Spam-Level: X-Spam-Status: No, score=-4.337 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiEjMtzW9eWl for ; Thu, 18 Apr 2013 10:44:14 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5C65D21F8F63 for ; Thu, 18 Apr 2013 10:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366307053; bh=ry7t0ImCoO+La5bT0bFxc0tVEtbBnZW3nm0pBVbyHCw=; l=8416; h=Date:From:To:References:In-Reply-To; b=Ty0u53eccBAaRImwxvabTtFvKf3LkrcmIorX1efZT5BE6DmdSHxglTa2ydC1VMMkJ m2/1qnHuQwruWBUTPDvqRWT/XiJUNBTfGmaNoMFaxCA+1Ka5mOe2ol6LrQ+sTQ2JbP Ny2w6X9Z8B4Scyuvluu63PAv9DnGs20Urx+tejSY= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 18 Apr 2013 19:44:13 +0200 id 00000000005DC042.00000000517030ED.000050A5 Message-ID: <517030ED.20501@tana.it> Date: Thu, 18 Apr 2013 19:44:13 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130409062431.GK24624@mx1.yitter.info> <9424963.YHzqPUZEKJ@scott-latitude-e6320> In-Reply-To: <9424963.YHzqPUZEKJ@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 18 Apr 2013 17:44:16 -0000 On Wed 17/Apr/2013 03:51:07 +0200 Scott Kitterman wrote: > On Tuesday, April 09, 2013 02:24:32 AM Andrew Sullivan wrote: > >> WGLC will close at 2014-04-24 00:00 UTC. >> >> SM will be the shepherd for this document. >> >> Best regards, >> >> Andrew (for the chairs) > > Just as a reminder, we're ~half way through the WGLC period Oh, you mean the close date was a typo? Here's my notes, mostly nits. I pasted lots of text from the I-D, so that issues can be evaluated even without getting at the document. *Abstract* Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on [...] That was good in 2004, now SPF exists already. A possible replacement could be, e.g.: This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby an Administration Management Domain (ADMD) can explicitly authorize the hosts that are allowed to use its domain names. A receiving host can check such authorization based on the IP address of the sending client and the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. 1. *Introduction* The current email infrastructure has the property that any host injecting mail into the system can use any DNS domain name it wants in each of the various identifiers specified by [RFC5321] and [RFC5322]. This sounds oldish too. SPF is not the only email authentication method. Perhaps we could use the introduction to explain the differences. 1.2. *check_host()* Section 4 introduces an algorithm to evaluate an SPF policy against an arriving email transaction. s/arriving email transaction/incoming email message/? 2.5. *Location of Checks* The authorization check SHOULD be performed during the processing of the SMTP transaction that sends the mail. s/sends/receives/? 3. *SPF Records* Do we wish to give an example of multi-line format in the zone file? 4.3. *Initial Processing* Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]. s/on 2.3 of [RFC5890].// once. 4.4. *Record Lookup* If all DNS lookups that are made return a server failure (RCODE 2), or other error (RCODE other than 0 or 3), or time out, then check_host() terminates immediately with the result "temperror". That "all" seems to refer to the SPF and TXT types. I'd say: If the query returns a server failure (RCODE 2), 4.6.4. *DNS Lookup Limits* These limits are per mechanism or macro in the record, and are in addition to the lookup limits specified above. Hm... above where? Perhaps splitting the section into, say: 4.6.4.1 *Total Limits*, and 4.6.4.2 *Particular cases* would allow to specify it more clearly. If you do so, then move the following (last two) paragraphs up. 4.7. *Default Result* OLD Note that records SHOULD always use either a "redirect" modifier or an "all" mechanism to explicitly terminate processing. NEW The RECOMMENDED practice is to use either a "redirect" modifier or an "all" mechanism to explicitly terminate the record. (A reader has no way to actually "note" that, and modifiers don't always terminate processing.) 5. *Mechanism Definitions* OLD Designated sender mechanisms are used to designate a set of NEW Designated-sender mechanisms are used to qualify a set of (Just avoiding to explain a term with itself.) SPF implementations on IPv6 servers need to handle both "AAAA" and "A" secords, for clients on IPv4 mapped IPv6 addresses [RFC4291]. s/secords/records/ 5.2. *"include"* I have no suggestions. Do we need it? 5.5. *"ptr" (do not use)* After many years of SPF deployment experience it has been concluded it is unnecessary and more reliable alternatives used instead. Maybe it's me, or the page break, but I think a comma after "experience" would make it more readable. 5.6. *"ip4" and "ip6"* Production rules can be set as mentioned in http://www.ietf.org/mail-archive/web/spfbis/current/msg03266.html 6.1. *redirect: Redirected Query* There is no statement on whether redirect= can be applied by an "include" mechanism. 6.2. *exp: Explanation* If check_host() results in a "fail" due to a mechanism match (such as "-all"), and the "exp" modifier is present, then [...] This is incomprehensible after the reorganization. I'd add "and the verifier is going to reject the message", and a link to Section 8.4 Fail. 8. Result Handling As such, there is no normative requirement for message handling in response to any particular result. This section is provided to present a complete picture of the likely cause of each result, and where available, the experience gained during experimental deployment. Please remove those two sentences, as they are not true. We could say there is no normative requirement for rejecting a message. But, for example, for softfail we correctly have normative requirements: Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal. This not holds for 10.2. Receivers too. 8.2. *Neutral* A "neutral" result indicates that although a policy for the identity was discovered, there is no definite assertion about the (positive or negative) about the client. Remove the first "about the". 8.7. *Permerror* It is also possible that this result is generated by certain SPF clients due to the input arguments having an unexpected format; see Section 4.8. I'd s/client/verifiers/. Raw "client" throughout the document refers to SMTP clients. "SPF client" is mentioned a few times and could cause confusion. There is no mention of "exp". Is its usage permitted/recommended? Missing reference to Appendix H.3, but see below. 9.2. *SPF Results in the Authentication-Results Header Field* It is, however, possible to add CFWS in the "reason" part of an Authentication-Results header field and provide the equivalent information, if desired. s/CFWS/key-value pairs/? 10. Effects on Infrastructure a comprehensive list of what such entities SHOULD do in light of this document. Is that /meant/ to be normative? 10.1.2. Administrator's Considerations changes are common, it is better to use the less resource intensive mechanisms like "ip4" and "ip6" over "a" or "a" or "mx". s/"a" or "mx"/"a" over "mx"/ The hostname is generally the identity used in the 5321.HELO/.EHLO command. In the case of messages with a null 5321.MailFrom, this is used as the domain for 5321.MailFrom SPF checks, in addition to being used in 5321.HELO/.EHLO based SPF checks. "hostname" is called "domain" in the previous paragraph, and the long slash-dot form of the names is used. In addition to reword that, it may be worth to note that x@relay.example.com can be used as an address even if there's no corresponding MX. 10.2. *Receivers* As stated elsewhere in this document, there is no normative requirement for specific handling of a message based on any SPF result. See 8. Result Handling above. 11.1. *Processing Limits* Using SPF clients also allows the attacker to hide the true source of the attack. s/clients/verifiers/. 11.5.1. *Recorded Results* This information, passed to the receiver in the Received-SPF: or Authentication-Results: trace fields, may be returned to the client MTA as an SMTP rejection message. If such an SMTP rejection message s/may/can/ if needed. Appendix H. *Local Policy Considerations* Do we still need to have this text in an appendix? It seems to be possible to insert each subsection within the relevant subsection of Section 8. IMHO that would improve clarity. Considerations for temperror are missing, anyway. Appendix I. *Protocol Status* s/techincal/technical/ P.S.: what widely deployed extensions to SPF? Appendix J. *Change History* Resolved Section 2.5.7 PermError on invalid domains after macro expansion errata in favor of documenting that different clients produce different results. s/clients/verifiers/. From spf2@kitterman.com Thu Apr 18 21:18: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 4562B1F0D12 for ; Thu, 18 Apr 2013 21:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjFLWzFGl-75 for ; Thu, 18 Apr 2013 21:18:54 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF261F0D11 for ; Thu, 18 Apr 2013 21:18:54 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6FFB320E40D4; Fri, 19 Apr 2013 00:18:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366345133; bh=ISmlDBZ+I9E1rHXFqJsgUNL8I6Knp1iCZ/KvUfqYaY8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lECXXAHT9+TuvYnzICHPTguLGbMZLcIK88mGLTILZ0joughgi8eY/GCJvHrTaIAAd AjVfzFtqdVhU7+trN0kjQPxLhLGky14K+B/YOvgOhvapngOLfwiVdqP2DLBAi1FH7Y mkuMRs4uOAtRdGEIs8ctFl8ohzxXZifkx6LxY2ow= 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 557B420E4090; Fri, 19 Apr 2013 00:18:52 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 19 Apr 2013 00:18:52 -0400 Message-ID: <3819226.HNrkiDGy6d@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <20130409062431.GK24624@mx1.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 19 Apr 2013 04:18:55 -0000 On Tuesday, April 16, 2013 10:08:12 PM Dotzero wrote: > I've reviewed the draft and have one "nit" and one question/comment: > > In the Abstract the use of ADMD should be followed with > (ADministrative Management Domains) > > 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. Fixed locally. I moved it up from the next paragraph to this one. > > For section 2.6.7. Permerror > > A "permerror" result means the domain's published records could not > be correctly interpreted. This signals an error condition that > definitely requires manual intervention to be resolved. > > Manual intervention by whom? Does this need to be clarified? Since it's an error in the record, I think it's not something that needs to be changed. Anyone else? > Other than these two relatively minor details, nothing jumped out at me. > > Mike > Thanks for the review. Scott K From spf2@kitterman.com Thu Apr 18 21:33: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 360F01F0D16 for ; Thu, 18 Apr 2013 21:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqKKGzx5ugIO for ; Thu, 18 Apr 2013 21:33:06 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 24C8F1F0D11 for ; Thu, 18 Apr 2013 21:33:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 72E6320E40D4; Fri, 19 Apr 2013 00:33:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366345985; bh=9l2bbyNxiZ6EdPhigIjap+THB142JFSMzGrAVDwDXQw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CyM9I9Ot2gQarAvhOPZaW8DbKlhQ4KBGBSTTtBZt/KjUAT6SBruOHCsbDuC4G+Sp0 IolRNIcg3tgGIN6ZdZOqMIcalVarfv2kw2uIy/Ww025aFSldSyyR/UPA5S6hwVpFgw a76FhplidIIirxBMTpmhioZ119BXEntvPXtkyv+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 5D52D20E4090; Fri, 19 Apr 2013 00:33:04 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 19 Apr 2013 00:33:04 -0400 Message-ID: <3158153.nEPxg7ZhQN@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <1CB7A581-3E5E-436F-AFD8-B4434D84ABB5@eudaemon.net> References: <20130409062431.GK24624@mx1.yitter.info> <1CB7A581-3E5E-436F-AFD8-B4434D84ABB5@eudaemon.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] WGLC: draft-ietf-spfbis-4408bis-14 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, 19 Apr 2013 04:33:08 -0000 On Wednesday, April 17, 2013 12:04:03 AM Tim Draegen wrote: > Read the document, support its publication. Notes from review: > > - Abstract mentioned ADMD before defined Fixed locally. > - extra quote first sentence of 2.2 Fixed locally. > - 2nd paragraph of 2.5 references "return-path", should be "MAIL FROM" Fixed locally. > - and 10.1.3, except the context references RFC5321 so might be ok Fixed locally. That makes it consistent. > - 10.2: missing ")" in first paragraph Fixed locally. > - Grammar nits in Appendix C. a lot of the bullets have naked references at > the end of sentences. Maybe put parenthesis around these? Fixed things up locally, so it should be better now. > > =- Tim Thanks for the review. Scott K From spf2@kitterman.com Thu Apr 18 21: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 4C55621F93D1 for ; Thu, 18 Apr 2013 21:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bLtVfhPat8G for ; Thu, 18 Apr 2013 21:38:53 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 837FE21F93C4 for ; Thu, 18 Apr 2013 21:38:53 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 151B920E40D4; Fri, 19 Apr 2013 00:38:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366346333; bh=BLE+Nu9bvjJBDdrqwPfIAtdsdMT878OLfCrjjy2Zcx8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UFZBo6Enna81PhTT0CDFKQtYY8vVoe1cgKeb+w7jo4/Oddf6NRIli62p3Gkisj2pW 1LLSKh86glBQkhUXrFcerxpCbWUWAPKA9VBZdCbd99PYsw/Ib1kD1tjjKUdp+rsatJ dYPYQTqEoD/0CspTHPLu9Q5HfKmD248Pyb/DMrk0= 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 EBAD020E4090; Fri, 19 Apr 2013 00:38:52 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 19 Apr 2013 00:38:51 -0400 Message-ID: <1596956.i3S8EuikZp@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <516E64CE.5050509@Commerco.Net> References: <20130409062431.GK24624@mx1.yitter.info> <516E64CE.5050509@Commerco.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] WGLC: draft-ietf-spfbis-4408bis-14 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, 19 Apr 2013 04:38:54 -0000 On Wednesday, April 17, 2013 03:01:02 AM Commerco WebMaster wrote: > Having reviewed the draft again end to end, I had pretty much the same > minor "nit" as Mike (AKA Dotzero) has already expressed on the list > regarding expanding the ADMD acronym in the Abstract section. > > As the Abstract is the first place in the entire document where the ADMD > acronym gets used, perhaps it should be expressed as ADministrative > Management Domain (ADMD) to mirror what exists in Section 2.2.1. > Originator of RFC5598, from whence the acronym comes, as later > documented in the 4408bis-14 section 1. Introduction. > > Also perhaps the ADMDs (ADministrative Management Domains, see > [RFC5598]), as it currently exists, should be ADministrative Management > Domains (ADMDs, see[RFC5598]), closely mirroring the plural as seen in > Section 2.3. Administrative Actors of RFC5598 with attribution to same > as already exists in section 1. Introduction of SPFbis-4408bis-14. I made it plural. > Overall, the work product contained in the SPFbis looks solid and all > participants should be congratulated in helping to bring the SPFbis to > this point. I think that special thanks to Editor Scott Kitterman and > the co-chairs for all their work in keeping the process on track and > constructive are in order. > > Finally, I also agree that the publication of this draft version > (draft-ietf-spfbis-4408bis-14) should move forward with suggested > changes at the editor's and co-chair's discretion. > > Best, > > Alan M. Thanks for the review, Scott K From vesely@tana.it Sat Apr 20 02:56: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 9E48321F8550 for ; Sat, 20 Apr 2013 02:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXhzBAWHhMZb for ; Sat, 20 Apr 2013 02:56:44 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 88D8F21F84D4 for ; Sat, 20 Apr 2013 02:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366451789; bh=vwVJuK/2/48YowwgqU06EomOB8y93b6LaW0nWX4yE/Y=; l=790; h=Date:From:To; b=erM1+HqokU/bopD+r4fitEMuHQoqO11NaaPnjV5FbVBHWOvf8PAoYfI9IuXuNnavi 1o22DRnMU6TNyb3lyWuJ0tZXn+cI2MVAx7c2ev/MyCG3LWATVJ1v55+9XAUV2nlVue uHPDmyCZ2MQ2ggYzKnC01QkVhZDTNlfHJnqdAJE0= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [10.57.167.222] (93-32-135-54.ip33.fastwebnet.it [93.32.135.54]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sat, 20 Apr 2013 11:56:27 +0200 id 00000000005DC039.000000005172664B.0000132F Message-ID: <51726641.7070606@tana.it> Date: Sat, 20 Apr 2013 11:56:17 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 20 Apr 2013 09:56:45 -0000 Appendix H.2 should be merged into Section 8.4, as the reason to keep them separate was beaten out by Murray's reorganization. I mentioned that in my review. In addition, the combined text is not explicit in describing how reject-on-fail works when enabled. H.2 says "rejection can be done before the SMTP content is transferred." Explicit would be to to say that the negative response can be given to either the MAIL or the RCPT commands. Of course, it is also possible to reject after receiving the content. It is not typical of SPF implementations to do so. Early rejection may conflict with DMARC and similar policies, and the point of this issue is that an explicit note can save readers the time to puzzle it out themselves, and possibly avoid some misunderstanding. From johnl@iecc.com Sat Apr 20 07: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 C55C721F8D6A for ; Sat, 20 Apr 2013 07:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if+0hMlaelbr for ; Sat, 20 Apr 2013 07:41:18 -0700 (PDT) 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 D896E21F85CC for ; Sat, 20 Apr 2013 07:41:17 -0700 (PDT) Received: (qmail 71589 invoked from network); 20 Apr 2013 14:42:50 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Apr 2013 14:42:50 -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; s=5172a90c.xn--hew.k1304; i=johnl@user.iecc.com; bh=A3lfJwG82pt7RxVjARHiYrHLfWDT94ySu7rWC5bw+p4=; b=HtcQVAtSpp8JkUtqEm+bTow9gMlbdHou4x8Y298SLLYlaXnkGUoAv7DeGN4HULzIUaDDmD+gauJdT1oEdMaUZoDQUbpLVUvnQ0L2pzJ54G/dXSw/r6d+/9dQfxnclfVAu1OqTKynTvugV9T/maej4G7kNKP0AKdO1Um3oyGnfsE= 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; s=5172a90c.xn--hew.k1304; olt=johnl@user.iecc.com; bh=A3lfJwG82pt7RxVjARHiYrHLfWDT94ySu7rWC5bw+p4=; b=LHffWcMqpRGKN8tTluoUYd2+jEGTOFZjM9W/7VE5UTE43N0wxCWi1lx7ctak4/tU5sZSeoTQ2EX5sXDf9pn1qVVFfa15xUmVgGHsK581vHCmqR4Ntw4rPqERLmSltjAwegcPv3jI2HdIT0MgDJwC7cQomcaD7pHiFGq3jEjq6XY= Date: 20 Apr 2013 14:40:54 -0000 Message-ID: <20130420144054.45509.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <51726641.7070606@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 20 Apr 2013 14:41:18 -0000 In article <51726641.7070606@tana.it> you write: >Appendix H.2 should be merged into Section 8.4, as the reason to keep >them separate was beaten out by Murray's reorganization. I mentioned >that in my review. No. If anything, the second and third paragraphs of 8.4 should move into H.2, since they're beyond the scope of what SPF actually does. >In addition, the combined text is not explicit in describing how >reject-on-fail works when enabled. H.2 says "rejection can be done >before the SMTP content is transferred." Explicit would be to to say >that the negative response can be given to either the MAIL or the RCPT >commands. No. This draft already gives more gratuitous advice than it needs to. R's, John From hsantos@isdg.net Sat Apr 20 08:34: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 9A4AF21F85FC for ; Sat, 20 Apr 2013 08:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.138 X-Spam-Level: X-Spam-Status: No, score=-102.138 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xaro2CQU1-+h for ; Sat, 20 Apr 2013 08:34:10 -0700 (PDT) Received: from mail.catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A127221F856F for ; Sat, 20 Apr 2013 08:34:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2566; t=1366472046; h=Received:Received: Message-ID:Date:From:Subject:To:Organization:List-ID; bh=+qZ09FZ UkztjsJ9dq1M74Q9Nly8=; b=gOiRF6s9P8/KKM8++WYtE/s7xQTAop+5NLIWu/0 +RyVoE0KbB2M71SmqRcbY+doMinMyN4Z/68fX3zw6r8NYPchC0idJAaGY/YoG4qT y+BotkFqxEUw9TibbvQCI2Rgtk+AT/sdzYNXZpRwx7zvZGIVEbEh7J3T/MrgjxDt 35wE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 20 Apr 2013 11:34:06 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 970772664.2773.5340; Sat, 20 Apr 2013 11:34:05 -0400 Message-ID: <5172B524.9030305@isdg.net> Date: Sat, 20 Apr 2013 11:32:52 -0400 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 CC: spfbis@ietf.org References: <20130420144054.45509.qmail@joyce.lan> In-Reply-To: <20130420144054.45509.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 20 Apr 2013 15:34:11 -0000 On 4/20/2013 10:40 AM, John Levine wrote: > In article <51726641.7070606@tana.it> you write: >> Appendix H.2 should be merged into Section 8.4, as the reason to keep >> them separate was beaten out by Murray's reorganization. I mentioned >> that in my review. > > No. If anything, the second and third paragraphs of 8.4 should move > into H.2, since they're beyond the scope of what SPF actually does. I believe the opposite is true. In fact, I believe BIS tries very hard to beat around the bush to relax the original goal, intent and purpose of a SPF FAIL policy which is Rejection. I believe BIS is more harmful to the community in this way (if indeed SPF FAIL policies are relaxed or its handling is relaxed) because of relaxation of statements and increased unnecessary verbosity. >> In addition, the combined text is not explicit in describing how >> reject-on-fail works when enabled. H.2 says "rejection can be done >> before the SMTP content is transferred." Explicit would be to to say >> that the negative response can be given to either the MAIL or the RCPT >> commands. > > No. This draft already gives more gratuitous advice than it needs to. SMTP session level rejection is all that is required to be said. It can happen at HELO/ELHO, MAIL, RCPT (as SMTP 8321 offers a suggestion, see section 5.4) or DATA state machine points. There is nothing gratuitous about this. Its the SPF Protocol intent and goal of the FAIL policies. The title of the doc even implies it. The abstract of the doc implies it as a method to find authorized machines and by authorization implication, you can do the opposite, easily find expected fault in the system and thus reject the unauthorized machines. As stated a number of times, the only system that CAN/DOES NOT HONOR a SMTP level rejection of a SPF failed policy transaction is one that can afford and performs the Message Separation at the USER level. Otherwise you have a pure and simple security loophole - period. I wish we don't lose the key focus of this SPF FAIL policy. As it always bother the same folks still today, it was about rejecting unauthorized machines. That said, it doesn't mean it (negative replies) can't be done at DATA EOD after other integrated considerations are made. That is an implementator design option that it can offer to administrators and operators - all you can program it yourself. Those can only come in as augmented ideas and suggestions, hints. But despite all that, it (SPF FAIL) is still a REJECT concept. -- HLS From hsantos@isdg.net Sat Apr 20 08:50: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 39D7F21F86F2 for ; Sat, 20 Apr 2013 08:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.907 X-Spam-Level: X-Spam-Status: No, score=-101.907 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yqwA+DoNKLN for ; Sat, 20 Apr 2013 08:50:20 -0700 (PDT) Received: from mail.catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA5221F86CE for ; Sat, 20 Apr 2013 08:50:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3605; t=1366473019; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=qhCVBCJ /++kL5FIETXLBLeEqrJo=; b=j4KAiwdVWGyf26Bq8X9ijSUM3VX/NbUZV0Uz708 m1ZF/Fcnc2PQOXqGN0hiRyIq8yTkIYNk6ykal+t7ZLIxQVTzJPLj5fY5wOcAQCaC pCpx5oT1CJMfw/zp7yp2eLldy91C1NKIFRX5KWTbUIhsWeMGtuq5EgRXG1yLVJlU a2DE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 20 Apr 2013 11:50:19 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 971746110.2773.4164; Sat, 20 Apr 2013 11:50:18 -0400 Message-ID: <5172B8F2.2030108@isdg.net> Date: Sat, 20 Apr 2013 11:49:06 -0400 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: spfbis@ietf.org References: <20130420144054.45509.qmail@joyce.lan> <5172B524.9030305@isdg.net> In-Reply-To: <5172B524.9030305@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 20 Apr 2013 15:50:21 -0000 Small Correction, the reference to RFC 8321 Section 5.4 below should be instead a reference to section 3.3 [1] 3.3. Mail Transactions .... Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. This is a CRITICAL SPF/DNS Optimization factor that SHOULD NOT be included from the BIS "protocol" description. -- HLS [1]https://tools.ietf.org/html/rfc5321#section-3.3 On 4/20/2013 11:32 AM, Hector Santos wrote: > > > On 4/20/2013 10:40 AM, John Levine wrote: >> In article <51726641.7070606@tana.it> you write: >>> Appendix H.2 should be merged into Section 8.4, as the reason to keep >>> them separate was beaten out by Murray's reorganization. I mentioned >>> that in my review. >> >> No. If anything, the second and third paragraphs of 8.4 should move >> into H.2, since they're beyond the scope of what SPF actually does. > > I believe the opposite is true. In fact, I believe BIS tries very hard > to beat around the bush to relax the original goal, intent and purpose > of a SPF FAIL policy which is Rejection. I believe BIS is more harmful > to the community in this way (if indeed SPF FAIL policies are relaxed or > its handling is relaxed) because of relaxation of statements and > increased unnecessary verbosity. > >>> In addition, the combined text is not explicit in describing how >>> reject-on-fail works when enabled. H.2 says "rejection can be done >>> before the SMTP content is transferred." Explicit would be to to say >>> that the negative response can be given to either the MAIL or the RCPT >>> commands. >> >> No. This draft already gives more gratuitous advice than it needs to. > > > SMTP session level rejection is all that is required to be said. It can > happen at HELO/ELHO, MAIL, RCPT (as SMTP 8321 offers a suggestion, see > section 5.4) or DATA state machine points. There is nothing gratuitous > about this. Its the SPF Protocol intent and goal of the FAIL policies. > The title of the doc even implies it. The abstract of the doc implies it > as a method to find authorized machines and by authorization > implication, you can do the opposite, easily find expected fault in the > system and thus reject the unauthorized machines. > > As stated a number of times, the only system that CAN/DOES NOT HONOR a > SMTP level rejection of a SPF failed policy transaction is one that can > afford and performs the Message Separation at the USER level. Otherwise > you have a pure and simple security loophole - period. > > I wish we don't lose the key focus of this SPF FAIL policy. As it always > bother the same folks still today, it was about rejecting unauthorized > machines. That said, it doesn't mean it (negative replies) can't be > done at DATA EOD after other integrated considerations are made. That > is an implementator design option that it can offer to administrators > and operators - all you can program it yourself. Those can only come in > as augmented ideas and suggestions, hints. But despite all that, it (SPF > FAIL) is still a REJECT concept. > > -- > HLS > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From hsantos@isdg.net Sat Apr 20 09:14: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 E594821F86D3 for ; Sat, 20 Apr 2013 09:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJkY1htF+k1c for ; Sat, 20 Apr 2013 09:14:21 -0700 (PDT) Received: from mail.catinthebox.net (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D32D321F856D for ; Sat, 20 Apr 2013 09:14:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4075; t=1366474454; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=gr4NsYu oUc22Q9AS0w3NElxP9Rk=; b=OmHVdM5/c/s8z1UCg3RMflIonco+fdMemzH/iIl hTVFJ8so8Qd4fBKxwkV9+I87DRo2HwzTYos/IofFaqUsNIFUsNyJaQSNMiXZquQN eI/DhYHdz89RD0e00EBWsOs4qvP5FNeSV7TcjdlnUH0YjvBw5pfnEAfytIMe+8gG 2fag= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 20 Apr 2013 12:14:14 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 973181506.2773.4336; Sat, 20 Apr 2013 12:14:14 -0400 Message-ID: <5172BE8D.1060303@isdg.net> Date: Sat, 20 Apr 2013 12:13:01 -0400 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: spfbis@ietf.org References: <20130420144054.45509.qmail@joyce.lan> <5172B524.9030305@isdg.net> <5172B8F2.2030108@isdg.net> In-Reply-To: <5172B8F2.2030108@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 20 Apr 2013 16:14:22 -0000 darn it, I meant Excluded! This is a CRITICAL SPF/DNS Optimization factor that SHOULD NOT be excluded from the BIS "protocol" description. I'm out of here. Later -- HLS On 4/20/2013 11:49 AM, Hector Santos wrote: > Small Correction, the reference to RFC 8321 Section 5.4 below should be > instead a reference to section 3.3 [1] > > 3.3. Mail Transactions > > .... Despite the apparent > scope of this requirement, there are circumstances in which the > acceptability of the reverse-path may not be determined until one or > more forward-paths (in RCPT commands) can be examined. In those > cases, the server MAY reasonably accept the reverse-path (with a 250 > reply) and then report problems after the forward-paths are received > and examined. Normally, failures produce 550 or 553 replies. > > This is a CRITICAL SPF/DNS Optimization factor that SHOULD NOT be > included from the BIS "protocol" description. > > > -- > HLS > > [1]https://tools.ietf.org/html/rfc5321#section-3.3 > > On 4/20/2013 11:32 AM, Hector Santos wrote: >> >> >> On 4/20/2013 10:40 AM, John Levine wrote: >>> In article <51726641.7070606@tana.it> you write: >>>> Appendix H.2 should be merged into Section 8.4, as the reason to keep >>>> them separate was beaten out by Murray's reorganization. I mentioned >>>> that in my review. >>> >>> No. If anything, the second and third paragraphs of 8.4 should move >>> into H.2, since they're beyond the scope of what SPF actually does. >> >> I believe the opposite is true. In fact, I believe BIS tries very hard >> to beat around the bush to relax the original goal, intent and purpose >> of a SPF FAIL policy which is Rejection. I believe BIS is more harmful >> to the community in this way (if indeed SPF FAIL policies are relaxed or >> its handling is relaxed) because of relaxation of statements and >> increased unnecessary verbosity. >> >>>> In addition, the combined text is not explicit in describing how >>>> reject-on-fail works when enabled. H.2 says "rejection can be done >>>> before the SMTP content is transferred." Explicit would be to to say >>>> that the negative response can be given to either the MAIL or the RCPT >>>> commands. >>> >>> No. This draft already gives more gratuitous advice than it needs to. >> >> >> SMTP session level rejection is all that is required to be said. It can >> happen at HELO/ELHO, MAIL, RCPT (as SMTP 8321 offers a suggestion, see >> section 5.4) or DATA state machine points. There is nothing gratuitous >> about this. Its the SPF Protocol intent and goal of the FAIL policies. >> The title of the doc even implies it. The abstract of the doc implies it >> as a method to find authorized machines and by authorization >> implication, you can do the opposite, easily find expected fault in the >> system and thus reject the unauthorized machines. >> >> As stated a number of times, the only system that CAN/DOES NOT HONOR a >> SMTP level rejection of a SPF failed policy transaction is one that can >> afford and performs the Message Separation at the USER level. Otherwise >> you have a pure and simple security loophole - period. >> >> I wish we don't lose the key focus of this SPF FAIL policy. As it always >> bother the same folks still today, it was about rejecting unauthorized >> machines. That said, it doesn't mean it (negative replies) can't be >> done at DATA EOD after other integrated considerations are made. That >> is an implementator design option that it can offer to administrators >> and operators - all you can program it yourself. Those can only come in >> as augmented ideas and suggestions, hints. But despite all that, it (SPF >> FAIL) is still a REJECT concept. >> >> -- >> HLS >> >> _______________________________________________ >> 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 Sat Apr 20 09:30: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 134C721F89C3 for ; Sat, 20 Apr 2013 09:30:14 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knUDSr+dvFAK for ; Sat, 20 Apr 2013 09:30:13 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3985121F8A00 for ; Sat, 20 Apr 2013 09:30:13 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4DCD220E40D2; Sat, 20 Apr 2013 12:30:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366475412; bh=e5tT1TIYqhDAH4eHO598h/cR1TZUQJuwsblfbhw6zd4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BEWKRSUbaRRLA+OCluESLGyZ/5RECrHzJHKGAe6HtR7jV1e64012ZgZn+hAyFwJP0 jxIi304HiqgkimRlmnIQFc5kcfGEHXseql+RVM7yDXgqyngshF2zEDdVo7bx0vAZXw Z3esYjCHt6Sf7n/E3bcpLrA0FnjciUVCkEX8lfaM= 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 3918220E409E; Sat, 20 Apr 2013 12:30:11 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 20 Apr 2013 12:30:10 -0400 Message-ID: <1864999.316QoD3oTm@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <51726641.7070606@tana.it> References: <51726641.7070606@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] New issue: 8.4. Fail: rejection is not described explicitly 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, 20 Apr 2013 16:30:14 -0000 On Saturday, April 20, 2013 11:56:17 AM Alessandro Vesely wrote: > Appendix H.2 should be merged into Section 8.4, as the reason to keep > them separate was beaten out by Murray's reorganization. I mentioned > that in my review. I'm about half way through your long set of comments. Thanks. In my opinion, that would have additional side effects. If H.2 goes away, then H.1 and H.3 are in an odd position and we'd end up reorganizing the document again. I think we reached rough consensus on the organization and we shouldn't redo it (there are many things I'm not happy with about the organization, but I think we got to a place the group could support and I don't want to mess with it again). Let's see if there's support for another reorganization? > In addition, the combined text is not explicit in describing how > reject-on-fail works when enabled. H.2 says "rejection can be done > before the SMTP content is transferred." Explicit would be to to say > that the negative response can be given to either the MAIL or the RCPT > commands. Do we need to be that specific? It can also be done after HELO/EHLO if the rejection is based on the HELO identity. Except for connect, SPF reject might happen at any stage in the SMTP process, so I'm not sure what additional specificity would add. Note that 8.4 goes into detail about exactly how to reject, so I think that's not an issue. > Of course, it is also possible to reject after receiving the content. > It is not typical of SPF implementations to do so. Early rejection may > conflict with DMARC and similar policies, and the point of this issue is > that an explicit note can save readers the time to puzzle it out > themselves, and possibly avoid some misunderstanding. I'm not sure what's unclear. Would it help if it said before DATA instead of "before the SMTP content is transferred"? Scott K From spf2@kitterman.com Sat Apr 20 09:32: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 977E321F8BE9 for ; Sat, 20 Apr 2013 09:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+a3i5zfDg8R for ; Sat, 20 Apr 2013 09:32:21 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CD50421F8B3A for ; Sat, 20 Apr 2013 09:32:20 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 50B4F20E40D2; Sat, 20 Apr 2013 12:32:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366475540; bh=j6XataS7/gIjJGkLyNHTNP2Gx4ffKJ2mTO+Z5+fr7R4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WIIXWtGlqfPmgmzx7PKoAj4dZ6Y8+NYXhlwoRAWvShF94WipOwh+wccOJdgAOP/bz SQiYouxv1xadK/aqUAmQztc9rWmgie/nwHMozAgd41yXvAwwiQ9B3/WFtkmVmXGujj 4Csk260EHKA0MlIFhp7bDC2cv+5jM4+HyLBYPYLE= 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 363FA20E409E; Sat, 20 Apr 2013 12:32:19 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 20 Apr 2013 12:32:19 -0400 Message-ID: <2770903.UPRLLI2RR6@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <5172B524.9030305@isdg.net> References: <20130420144054.45509.qmail@joyce.lan> <5172B524.9030305@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 20 Apr 2013 16:32:21 -0000 On Saturday, April 20, 2013 11:32:52 AM Hector Santos wrote: > On 4/20/2013 10:40 AM, John Levine wrote: > > In article <51726641.7070606@tana.it> you write: > >> Appendix H.2 should be merged into Section 8.4, as the reason to keep > >> them separate was beaten out by Murray's reorganization. I mentioned > >> that in my review. > > > > No. If anything, the second and third paragraphs of 8.4 should move > > into H.2, since they're beyond the scope of what SPF actually does. > > I believe the opposite is true. In fact, I believe BIS tries very hard > to beat around the bush to relax the original goal, intent and purpose > of a SPF FAIL policy which is Rejection. I believe BIS is more harmful > to the community in this way (if indeed SPF FAIL policies are relaxed or > its handling is relaxed) because of relaxation of statements and > increased unnecessary verbosity. > > >> In addition, the combined text is not explicit in describing how > >> reject-on-fail works when enabled. H.2 says "rejection can be done > >> before the SMTP content is transferred." Explicit would be to to say > >> that the negative response can be given to either the MAIL or the RCPT > >> commands. > > > > No. This draft already gives more gratuitous advice than it needs to. > > SMTP session level rejection is all that is required to be said. It can > happen at HELO/ELHO, MAIL, RCPT (as SMTP 8321 offers a suggestion, see > section 5.4) or DATA state machine points. There is nothing gratuitous > about this. Its the SPF Protocol intent and goal of the FAIL policies. > The title of the doc even implies it. The abstract of the doc implies it > as a method to find authorized machines and by authorization > implication, you can do the opposite, easily find expected fault in the > system and thus reject the unauthorized machines. > > As stated a number of times, the only system that CAN/DOES NOT HONOR a > SMTP level rejection of a SPF failed policy transaction is one that can > afford and performs the Message Separation at the USER level. Otherwise > you have a pure and simple security loophole - period. > > I wish we don't lose the key focus of this SPF FAIL policy. As it always > bother the same folks still today, it was about rejecting unauthorized > machines. That said, it doesn't mean it (negative replies) can't be > done at DATA EOD after other integrated considerations are made. That > is an implementator design option that it can offer to administrators > and operators - all you can program it yourself. Those can only come in > as augmented ideas and suggestions, hints. But despite all that, it (SPF > FAIL) is still a REJECT concept. Since how to give a 550 reject is right in the fail definition, I don't think your argument is consistent with the text. Scott K From spf2@kitterman.com Sat Apr 20 09:36: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 B9BDC21F8BDE for ; Sat, 20 Apr 2013 09:36:28 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtqZDyDaLGRs for ; Sat, 20 Apr 2013 09:36:27 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B8DB321F8B3A for ; Sat, 20 Apr 2013 09:36:27 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 47EB320E40D2; Sat, 20 Apr 2013 12:36:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366475787; bh=8IWB608/zG3uJtoO7FIwLJMMCKDU2lsxg9aKwJ5TnDA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PDUb034H6LML7okqUGdQLIIbV/2lnr9KKrPd/SNDRqoy85uJHdvK7i2EBdk/2OJ2Z wlJoXdNoXiop8Gt7fJy48u25b5w41C4wwhNYMY2XtMTWU8PIat5aqKsf26gzu23ZVQ y2tVC5IM4qO1Meey8M9c2G0Qz7Qpfj7zEm3qiVcM= 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 3140520E409E; Sat, 20 Apr 2013 12:36:26 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 20 Apr 2013 12:36:26 -0400 Message-ID: <3006012.4xjPI9KomB@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <5172B8F2.2030108@isdg.net> References: <20130420144054.45509.qmail@joyce.lan> <5172B524.9030305@isdg.net> <5172B8F2.2030108@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 20 Apr 2013 16:36:29 -0000 Please propose specific text for evaluation. I have no idea what it is you want changed in the draft. Personally, I doubt we need to repeat things from RFC 5321 into the draft (they are already incorporated by reference effectively), I'd like to understand better what it is you think needs changing. Scott K On Saturday, April 20, 2013 11:49:06 AM Hector Santos wrote: > Small Correction, the reference to RFC 8321 Section 5.4 below should be > instead a reference to section 3.3 [1] > > 3.3. Mail Transactions > > .... Despite the apparent > scope of this requirement, there are circumstances in which the > acceptability of the reverse-path may not be determined until one or > more forward-paths (in RCPT commands) can be examined. In those > cases, the server MAY reasonably accept the reverse-path (with a 250 > reply) and then report problems after the forward-paths are received > and examined. Normally, failures produce 550 or 553 replies. > > This is a CRITICAL SPF/DNS Optimization factor that SHOULD NOT be > included from the BIS "protocol" description. > > > -- > HLS > > [1]https://tools.ietf.org/html/rfc5321#section-3.3 > > On 4/20/2013 11:32 AM, Hector Santos wrote: > > On 4/20/2013 10:40 AM, John Levine wrote: > >> In article <51726641.7070606@tana.it> you write: > >>> Appendix H.2 should be merged into Section 8.4, as the reason to keep > >>> them separate was beaten out by Murray's reorganization. I mentioned > >>> that in my review. > >> > >> No. If anything, the second and third paragraphs of 8.4 should move > >> into H.2, since they're beyond the scope of what SPF actually does. > > > > I believe the opposite is true. In fact, I believe BIS tries very hard > > to beat around the bush to relax the original goal, intent and purpose > > of a SPF FAIL policy which is Rejection. I believe BIS is more harmful > > to the community in this way (if indeed SPF FAIL policies are relaxed or > > its handling is relaxed) because of relaxation of statements and > > increased unnecessary verbosity. > > > >>> In addition, the combined text is not explicit in describing how > >>> reject-on-fail works when enabled. H.2 says "rejection can be done > >>> before the SMTP content is transferred." Explicit would be to to say > >>> that the negative response can be given to either the MAIL or the RCPT > >>> commands. > >> > >> No. This draft already gives more gratuitous advice than it needs to. > > > > SMTP session level rejection is all that is required to be said. It can > > happen at HELO/ELHO, MAIL, RCPT (as SMTP 8321 offers a suggestion, see > > section 5.4) or DATA state machine points. There is nothing gratuitous > > about this. Its the SPF Protocol intent and goal of the FAIL policies. > > The title of the doc even implies it. The abstract of the doc implies it > > as a method to find authorized machines and by authorization > > implication, you can do the opposite, easily find expected fault in the > > system and thus reject the unauthorized machines. > > > > As stated a number of times, the only system that CAN/DOES NOT HONOR a > > SMTP level rejection of a SPF failed policy transaction is one that can > > afford and performs the Message Separation at the USER level. Otherwise > > you have a pure and simple security loophole - period. > > > > I wish we don't lose the key focus of this SPF FAIL policy. As it always > > bother the same folks still today, it was about rejecting unauthorized > > machines. That said, it doesn't mean it (negative replies) can't be > > done at DATA EOD after other integrated considerations are made. That > > is an implementator design option that it can offer to administrators > > and operators - all you can program it yourself. Those can only come in > > as augmented ideas and suggestions, hints. But despite all that, it (SPF > > FAIL) is still a REJECT concept. > > > > -- > > HLS > > > > _______________________________________________ > > 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 Sat Apr 20 10:20: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 7D4BC21F87B7 for ; Sat, 20 Apr 2013 10:20:00 -0700 (PDT) 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.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV2u35UG2BNA for ; Sat, 20 Apr 2013 10:20:00 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A57F721F8771 for ; Sat, 20 Apr 2013 10:19:59 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id c10so2330638wiw.0 for ; Sat, 20 Apr 2013 10:19:58 -0700 (PDT) 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=HgnF0TvsF8HWWRSLA/G1dyCQxsncEvF0ho1Yqt33468=; b=qWh0PkzyeCJUWQ344+9emFby/wjUX9oN8WazYJGVt1EuxUwr3hNPWl/3zldsAyV8+F Wwz0zppeocCGH9SlJ80dwxbmhN1TTKP9RpeUXQi3HcNxKcXTLak5evgOyJ02W2zzh0zy DsUna/EaMujdwjZMyADPMOP+fGPfLAZNaMbglxrG3unQ3NCTwdRIBSIswgLAYVkr22To qEpuEdNcqIHoWwbMMkj8NJC4w7LSkDnfD5lZjMJ/vFcFg4dd59O+LB4NqM4xktZxjemr w8eSPb6trqW3FX/2F9oaD0tnbm2LjccK+H0R3juIBEA/fMgjkrWpUu40WfkBi+02T1mv vucA== MIME-Version: 1.0 X-Received: by 10.180.84.162 with SMTP id a2mr35366183wiz.14.1366478398843; Sat, 20 Apr 2013 10:19:58 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sat, 20 Apr 2013 10:19:58 -0700 (PDT) In-Reply-To: <51726641.7070606@tana.it> References: <51726641.7070606@tana.it> Date: Sat, 20 Apr 2013 10:19:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d044271948e710104dace0bfd Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 20 Apr 2013 17:20:00 -0000 --f46d044271948e710104dace0bfd Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 20, 2013 at 2:56 AM, Alessandro Vesely wrote: > Appendix H.2 should be merged into Section 8.4, as the reason to keep > them separate was beaten out by Murray's reorganization. I mentioned > that in my review. > I don't agree. What's in H.2 discusses local policy development which cannot be normative. It's strictly pedagogical. Section 8 contains purely definitions and normative material. I don't support mixing them. I also agree with what John said about this. In addition, the combined text is not explicit in describing how > reject-on-fail works when enabled. H.2 says "rejection can be done > before the SMTP content is transferred." Explicit would be to to say > that the negative response can be given to either the MAIL or the RCPT > commands. > I would be fine with changing H.2 to make that very explicit, although I think we can rely on people understanding SMTP already since it's a normative reference, so I'm also fine with leaving it as-is, and at this late stage that is also my preference. > > Of course, it is also possible to reject after receiving the content. > It is not typical of SPF implementations to do so. Early rejection may > conflict with DMARC and similar policies, and the point of this issue is > that an explicit note can save readers the time to puzzle it out > themselves, and possibly avoid some misunderstanding. > We should absolutely not discuss DMARC or other layers here. -MSK --f46d044271948e710104dace0bfd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 20, 2013 at 2:56 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
Appendix H.2 should be merged into Section 8= .4, as the reason to keep
them separate was beaten out by Murray's reorganization. =A0I mentioned=
that in my review.

I don't agree.= =A0 What's in H.2 discusses local policy development which cannot be no= rmative.=A0 It's strictly pedagogical.=A0 Section 8 contains purely def= initions and normative material.=A0 I don't support mixing them.

I also agree with what John said about this.

In addition, the combined text is not explicit in describing how
reject-on-fail works when enabled. =A0H.2 says "rejection can be done<= br> before the SMTP content is transferred." =A0Explicit would be to to sa= y
that the negative response can be given to either the MAIL or the RCPT
commands.

I would be fine with changing= H.2 to make that very explicit, although I think we can rely on people und= erstanding SMTP already since it's a normative reference, so I'm al= so fine with leaving it as-is, and at this late stage that is also my prefe= rence.
=A0

Of course, it is also possible to reject after receiving the content.
It is not typical of SPF implementations to do so. =A0Early rejection may conflict with DMARC and similar policies, and the point of this issue is that an explicit note can save readers the time to puzzle it out
themselves, and possibly avoid some misunderstanding.
=
We should absolutely not discuss DMARC or other layers here.=

-MSK
--f46d044271948e710104dace0bfd-- From johnl@iecc.com Sat Apr 20 12:46: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 D148921F925B for ; Sat, 20 Apr 2013 12:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkCriYfi2o3m for ; Sat, 20 Apr 2013 12:46:36 -0700 (PDT) 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 C537121F926E for ; Sat, 20 Apr 2013 12:46:35 -0700 (PDT) Received: (qmail 54480 invoked from network); 20 Apr 2013 19:48:06 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Apr 2013 19:48:06 -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; s=5172f099.xn--3zv.k1304; i=johnl@user.iecc.com; bh=FspSb5Bbmt6WtImLa4N3tnlSs5cQ+cJ6cB0WXERgImM=; b=ihPo7ufo6kiMN4wnvQ9/9peZ4Tc10zDPw3WGKqO01JzE59P6JuHh8beQQnu3wRP/mo5EUIBcONATNY++4G8sEvdTAKs5YvaeUTgXJs1dlGhAsuW2wMupYk0Gjak0Tsd6l52mnq0zRcSDx/mtZZEr7W/XiEdBW21iv5yZD6rS234= 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; s=5172f099.xn--3zv.k1304; olt=johnl@user.iecc.com; bh=FspSb5Bbmt6WtImLa4N3tnlSs5cQ+cJ6cB0WXERgImM=; b=UXRfvB55bQkvGkEzTk9xSUp9Dj48yNC+5Zu0vW39JeENeB3h01MLf2WHD5EB0fh/MIEqv5izcRg1bwd6mZ7bDocEHM/tx5Jm6TjqQZtApQCqIeg3iej5KbaZ97jW0aRWYqSS5HCQBVK9OLNG8k1f4IyEWOCS1aGLrO5JiPQTFuc= Date: 20 Apr 2013 19:46:10 -0000 Message-ID: <20130420194610.46217.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <3819226.HNrkiDGy6d@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] WGLC: draft-ietf-spfbis-4408bis-14 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, 20 Apr 2013 19:46:36 -0000 These are mostly nits. I'm not worrying about typos and minor grammatical issues, since the skilled staff at the RFC production center will find them better than I do. 2.1 HELO identity Checking "HELO" promotes consistency of results and can reduce DNS resource usage. I understand the consistency, but how does doing two lookups rather than one reduce DNS resource usage? Suggest just removing the second clause. 2.4 Checking Authorization Without explicit approval of the domain owner, checking other identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results. For example, almost all mailing lists rewrite the "MAIL FROM" identity (see Section 10.3), but some do not change any other identities in the message. Documents that define other identities will have to define the method for explicit approval. I realize that this paragraph translates to "Sender-ID sucks", but as it stands it raises more questions than it answers, e.g., how would a receiver know what a domain owner approves, and what should I check then. Since Sender-ID is dead, I suggest removing it. When a mail receiver decides to perform an SPF check, it MUST use a correctly-implemented check_host() function (Section 4) evaluated with the correct parameters. Although the test as a whole is optional, once it has been decided to perform a test it has to be performed as specified so that the correct semantics are preserved between publisher and receiver. If people haven't already figured out that they have to implement the spec correctly, this won't help. I suggest removing it. 2.6. Results of Evaluation An SPF verifier implements something semantically identical to the function defined there. Suggest "semantically equivalent" to match langauge in Sec 4. 3. SPF Records The SPF record is a single string of text. Suggest "The SPF record is interpreted as a single string of text" since in fact the record may well have several strings. 8.4. Fail Suggest moving everything after the first paragraph to App. H.2. since it's basically an example. 8.5. Softfail Suggest moving everything after the first paragraph to a new subsection of App. H. Please do our users a favor and remove the bad advice about highlighting failures in MUAs. 9.2. SPF Results in the Authentication-Results Header Field Odd bug in the xml, the last para and example are switched in the html output. R's, John From spf2@kitterman.com Sat Apr 20 15:06: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 4116921F92CB for ; Sat, 20 Apr 2013 15:06:07 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzOsRLWD6Em2 for ; Sat, 20 Apr 2013 15:06:05 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A5F5621F8FB3 for ; Sat, 20 Apr 2013 15:06:02 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C6D9E20E40D2; Sat, 20 Apr 2013 18:06:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366495561; bh=xjFY8cTAaO8nrhqc7+vH66pku4N5Dukt2Ydnupiu8HI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bsjOLn64zwGReQ9VN5OUut8xUrxeq73AOqJ83+AGRK6pnz21OmgYFgcEu69tch2S9 rBpTtARWxD+DwGNPrENgXiJZ25xRAKaJWjCL8dSgLgk+2/Kd7e28aVEkAnTTkXbffm uWEGoZzIgpcc8F0NGLTymMZcVPefyvmrUKkMjspM= 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 AA74C20E409E; Sat, 20 Apr 2013 18:06:01 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 20 Apr 2013 18:06 -0400 Message-ID: <5830786.tCECZPYMZs@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <517030ED.20501@tana.it> References: <20130409062431.GK24624@mx1.yitter.info> <9424963.YHzqPUZEKJ@scott-latitude-e6320> <517030ED.20501@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] WGLC: draft-ietf-spfbis-4408bis-14 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, 20 Apr 2013 22:06:07 -0000 On Thursday, April 18, 2013 07:44:13 PM Alessandro Vesely wrote: > On Wed 17/Apr/2013 03:51:07 +0200 Scott Kitterman wrote: > > On Tuesday, April 09, 2013 02:24:32 AM Andrew Sullivan wrote: > >> WGLC will close at 2014-04-24 00:00 UTC. > >> > >> SM will be the shepherd for this document. > >> > >> Best regards, > >> > >> Andrew (for the chairs) > > > > Just as a reminder, we're ~half way through the WGLC period > > Oh, you mean the close date was a typo? No. April 17 is roughly half way between April 9 and April 24. > Here's my notes, mostly nits. I pasted lots of text from the I-D, so > that issues can be evaluated even without getting at the document. > > > *Abstract* > > Email on the Internet can be forged in a number of ways. In > particular, existing protocols place no restriction on [...] > > That was good in 2004, now SPF exists already. A possible replacement > could be, e.g.: > > This document describes version 1 of the Sender Policy Framework > (SPF) protocol, whereby an Administration Management Domain (ADMD) > can explicitly authorize the hosts that are allowed to use its domain > names. A receiving host can check such authorization based on the IP > address of the sending client and the "MAIL FROM" of a message or > the domain given on the SMTP HELO/EHLO commands. I would rather not rewrite the abstract at this stage. Yes, SPF has existed for a long time, but for many it's been "only an experiment", so I think the current text is good. > > 1. *Introduction* > > The current email infrastructure has the property that any host > injecting mail into the system can use any DNS domain name it wants > in each of the various identifiers specified by [RFC5321] and > [RFC5322]. > > This sounds oldish too. SPF is not the only email authentication > method. Perhaps we could use the introduction to explain the differences. We did discuss including information about DKIM and how it related to SPF, but there was push back. I think that since anything about DKIM is out of scope, we ought not get into it. No where in the existing text does it claim SPF is the only solution. > > 1.2. *check_host()* > > Section 4 introduces an algorithm to evaluate an SPF policy against > an arriving email transaction. > > s/arriving email transaction/incoming email message/? That seems OK to me, but I didn't write that, so I'll wait for others to chime in to change it. > > 2.5. *Location of Checks* > > The authorization check SHOULD be performed during the processing of > the SMTP transaction that sends the mail. > > s/sends/receives/? Fixed locally. > > 3. *SPF Records* > > Do we wish to give an example of multi-line format in the zone file? No, I think zone file tutorials are out of scope. There's plenty of documentation on making zone files and not everyone uses BIND anyway. > > 4.3. *Initial Processing* > > Internationalized domain names > MUST be encoded as A-labels, as described in Section 2.3 of > [RFC5890].on 2.3 of [RFC5890]. > > s/on 2.3 of [RFC5890].// once. Fixed locally. > > 4.4. *Record Lookup* > > If all DNS lookups that are made return a server failure (RCODE 2), > or other error (RCODE other than 0 or 3), or time out, then > check_host() terminates immediately with the result "temperror". > > That "all" seems to refer to the SPF and TXT types. I'd say: > > If the query returns a server failure (RCODE 2), Fixed locally. I kept DNS lookup instead of query, but it's all singular now. > > 4.6.4. *DNS Lookup Limits* > > These limits are per mechanism or macro in the record, and are in > addition to the lookup limits specified above. > > Hm... above where? Perhaps splitting the section into, say: > > 4.6.4.1 *Total Limits*, and > 4.6.4.2 *Particular cases* > > would allow to specify it more clearly. If you do so, then move the > following (last two) paragraphs up. above is the previous paragraph. I'm not sure that helps. I'd like to hear other opinions. > > 4.7. *Default Result* > > OLD > Note that records SHOULD always use either a "redirect" modifier or > an "all" mechanism to explicitly terminate processing. > NEW > The RECOMMENDED practice is to use either a "redirect" modifier or > an "all" mechanism to explicitly terminate the record. > > (A reader has no way to actually "note" that, and modifiers don't > always terminate processing.) I got rid of "Note that" and I also changed the word included to provided at the end of the paragraph (to avoid possible confusion about the include mechanism). > > 5. *Mechanism Definitions* > > OLD > Designated sender mechanisms are used to designate a set of > NEW > Designated-sender mechanisms are used to qualify a set of > > (Just avoiding to explain a term with itself.) Fixed using identify in place of designate. > SPF implementations on IPv6 > servers need to handle both "AAAA" and "A" secords, for clients on > IPv4 mapped IPv6 addresses [RFC4291]. > > s/secords/records/ Fixed locally. > > 5.2. *"include"* > > > > > I have no suggestions. Do we need it? No. Not needed, so removed. > > 5.5. *"ptr" (do not use)* > > After many years of SPF deployment > experience it has been concluded it is unnecessary and more reliable > alternatives used instead. > > Maybe it's me, or the page break, but I think a comma after > "experience" would make it more readable. Added. > > 5.6. *"ip4" and "ip6"* > > Production rules can be set as mentioned in > http://www.ietf.org/mail-archive/web/spfbis/current/msg03266.html I think RFC 4291 is a better source for IPv6 than RFC 3986. For IPv4, that looks like it might be a good idea. I'd appreciate input from people with more ABNF experience than me before I change anything. > > > 6.1. *redirect: Redirected Query* > > There is no statement on whether redirect= can be applied by an > "include" mechanism. I don't understand the question? > > 6.2. *exp: Explanation* > > If check_host() results in a "fail" due to a mechanism match (such as > "-all"), and the "exp" modifier is present, then [...] > > This is incomprehensible after the reorganization. I'd add "and the > verifier is going to reject the message", and a link to Section 8.4 Fail. When I first looked at this, I agreed with you, but you have to consider that when the document is referring to 'returning' the explanation, it's check_host() returning it to the calling application. Check_host() doesn't know if the message will be rejected or not. I've added "... MUST be returned to the calling application." to the end of the paragraph to (hopefully) clarify this. > > 8. Result Handling > > As such, there is no normative requirement for > message handling in response to any particular result. This section > is provided to present a complete picture of the likely cause of each > result, and where available, the experience gained during > experimental deployment. > > Please remove those two sentences, as they are not true. We could say > there is no normative requirement for rejecting a message. But, for > example, for softfail we correctly have normative requirements: > > Receiving software SHOULD NOT reject the message based solely on this > result, but MAY subject the message to closer scrutiny than normal. The statement is generally true, but as you state not 100% correct. I've added the word comprehensive so that it now reads, "... comprehensive normative requirement ..." to make it clearer that this is generally true even though there are a few exceptions. > This not holds for 10.2. Receivers too. I tried to clarify it there too. The relevant sentence now reads: > As stated elsewhere in this document, there is no comprehensive > normative requirement for specific handling of a message based > on SPF results. I think that clears it up. > > 8.2. *Neutral* > > A "neutral" result indicates that although a policy for the identity > was discovered, there is no definite assertion about the (positive or > negative) about the client. > > Remove the first "about the". Done locally. > > 8.7. *Permerror* > > It is also possible > that this result is generated by certain SPF clients due to the input > arguments having an unexpected format; see Section 4.8. > > I'd s/client/verifiers/. Raw "client" throughout the document refers > to SMTP clients. "SPF client" is mentioned a few times and could > cause confusion. Done locally. > There is no mention of "exp". Is its usage permitted/recommended? No. Exp is a message from the sending domain back to senders of mail from the domain that fails SPF checks. It's appropriate for receivers to send sensible text back with the 550 if they reject due to permerror, but that's not the case that exp supports. > Missing reference to Appendix H.3, but see below. Fixed. I do think we need to keep it as has been discussed in reply to your later message. > > 9.2. *SPF Results in the Authentication-Results Header Field* > > It is, however, possible to add CFWS in the "reason" part of an > Authentication-Results header field and provide the equivalent > information, if desired. > > s/CFWS/key-value pairs/? msk: I think you provided this text. Would you please comment? > > 10. Effects on Infrastructure > > a comprehensive list of what such entities SHOULD do in light of this > document. > > Is that /meant/ to be normative? I think you missed the not. "... not a comprehensive list of what such entities SHOULD do ..." No. It's not meant to be normative. > > 10.1.2. Administrator's Considerations > > changes are common, it is better to use the less resource intensive > mechanisms like "ip4" and "ip6" over "a" or "a" or "mx". > > s/"a" or "mx"/"a" over "mx"/ > > The hostname is generally the identity used in the 5321.HELO/.EHLO > command. In the case of messages with a null 5321.MailFrom, this is > used as the domain for 5321.MailFrom SPF checks, in addition to being > used in 5321.HELO/.EHLO based SPF checks. > > "hostname" is called "domain" in the previous paragraph, and the long > slash-dot form of the names is used. In addition to reword that, it > may be worth to note that x@relay.example.com can be used as an > address even if there's no corresponding MX. I'm not sure what you're after here, would you please provide text so I can better understand? Also, due to the implicit MX fallback to A, any host with an A record can receiver mail, so I don't understand why "evern if there's no MX" is relevant to anything. > > 10.2. *Receivers* > > As stated elsewhere in this document, there is > no normative requirement for specific handling of a message based on > any SPF result. > > See 8. Result Handling above. > Fixed. See above. > 11.1. *Processing Limits* > > Using SPF clients also allows the attacker to > hide the true source of the attack. > > s/clients/verifiers/. Fixed locally. > > 11.5.1. *Recorded Results* > > This information, passed to the receiver in the Received-SPF: or > Authentication-Results: trace fields, may be returned to the client > MTA as an SMTP rejection message. If such an SMTP rejection message > > s/may/can/ if needed. Made it can. > > Appendix H. *Local Policy Considerations* > > Do we still need to have this text in an appendix? It seems to be > possible to insert each subsection within the relevant subsection of > Section 8. IMHO that would improve clarity. Yes. I think it needs to be in the appendix as discussed in the other thread. > Considerations for temperror are missing, anyway. OK. Fixed. I took the permerror considerations and modeled words for temperror on them. I aimed to avoid novelty or controversy. Let's see if I succeeded. Here's what I added locally: > H.4. Policy For SPF Temperror > > The "temperror" result (see Section 2.6.6) indicates the SPF > processing module at the receiver could not retrieve and SPF policy > record due to a (probably) transient condition. This gives no true > indication about the authorized use of the data found in the > envelope. > > As with all results, implementers have a choice to make regarding > what to do with a message that yields this result. SMTP allows only > a few basic options. > > Deferring the message is an option, in that it is the one thing a > receiver can do to draw attention to the difficulty encountered while > protecting itself from messages that do not have a definite SPF > result of some kind. However, if the SPF implementation is defective > and returns spurious "temperror" results, only the sender is actively > notified of the defect (in the form of mail rejected after it times > out of the sending queue), and not the receiver making use of SPF. > > Because of long queue lifetimes, it is possible that mail will be > repeatedly deferred for several days and so any awareness by the > sender of a problem could be quite delayed. If "temperrors" persist > for multiple delivery attempts, it might be perferable to treat the > error as permanent and reduce the amount of time the message is in > transit. > > The less intrusive handling choice is to deliver the message, perhaps > with some kind of annotation of the difficulty encountered and/or > logging of a similar nature. However, this will not be desirable to > operators that wish to implement SPF checking as strictly as > possible, nor is this sort of passive problem reporting typically > effective. > > There is of course the option placing this choice in the hands of the > operator rather than the implementer since this kind of choice is > often a matter of local policy rather than a condition with a > universal solution, but this adds one more piece of complexity to an > already non-trivial environment. > > Both implementers and operators need to be cautious of all choices > and outcomes when handling SPF results. How's that? > Appendix I. *Protocol Status* > > s/techincal/technical/ Fixed locally. > P.S.: what widely deployed extensions to SPF? As I recall, the two cases where we invoked widely deployed to include things in 4408bis (per the charter) are use of Authentication Results in place of Received SPF and the "void lookup" processing limit. > > Appendix J. *Change History* > > Resolved Section 2.5.7 PermError on invalid domains after macro > expansion errata in favor of documenting that different clients > produce different results. > > s/clients/verifiers/. Fixed locally. Thanks for the detailed review. Scott K From spf2@kitterman.com Sat Apr 20 15:26: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 186CA21F8F4A for ; Sat, 20 Apr 2013 15:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vst6y4pggtY8 for ; Sat, 20 Apr 2013 15:26:03 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA0821F8F0C for ; Sat, 20 Apr 2013 15:26:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 902EF20E40D2; Sat, 20 Apr 2013 18:26:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366496762; bh=HlGkTQDVmvqOMxK86qKvypOM07EUsZ5hzwGXCCDvxnU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NtFzZSXiYow9/LAvVYk6RVEqqexldONAzNlgEfpcWYp9mIwsBfGcdMOdsECIkyRSc VzAOJEnoeWWKl1jO6pzl+TJw28WPqojwPosuMCO86SgdfoYNt075usxzDKHR7SOuj9 sIO1uhR0wt5aMeiai/WPNST3tb6glyGS4DBeFCLM= 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 72A7220E409E; Sat, 20 Apr 2013 18:26:02 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 20 Apr 2013 18:26:01 -0400 Message-ID: <1903338.omVMzuiKyh@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <20130420194610.46217.qmail@joyce.lan> References: <20130420194610.46217.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] WGLC: draft-ietf-spfbis-4408bis-14 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, 20 Apr 2013 22:26:04 -0000 On Saturday, April 20, 2013 07:46:10 PM John Levine wrote: > These are mostly nits. I'm not worrying about typos and minor > grammatical issues, since the skilled staff at the RFC production > center will find them better than I do. > > 2.1 HELO identity > > Checking "HELO" promotes consistency of results and can reduce DNS > resource usage. > > I understand the consistency, but how does doing two lookups rather > than one reduce DNS resource usage? Suggest just removing the second > clause. Generally, the SPF record for HELO requires at most one additional DNS lookup, so even if you have a relatively low rejection rate base on these records, you can come out ahead on resource expenditure because it's generally an inexpensive check compared to Mail From records. > 2.4 Checking Authorization > > Without explicit approval of the domain owner, checking other > identities against SPF version 1 records is NOT RECOMMENDED because > there are cases that are known to give incorrect results. For example, > almost all mailing lists rewrite the "MAIL FROM" identity (see Section > 10.3), but some do not change any other identities in the message. > Documents that define other identities will have to define the method > for explicit approval. > > I realize that this paragraph translates to "Sender-ID sucks", but as > it stands it raises more questions than it answers, e.g., how would a > receiver know what a domain owner approves, and what should I check > then. Since Sender-ID is dead, I suggest removing it. That's certainly the original reason it got included, but the issue keeps coming up. DMARC was forced to work around this issue very carefully (I think they got it right, but it was non-trivial to get there). There are any number of schemes people have come up with to leverage the information in SPF records and I think it's useful to keep the words in there about record reuse being a bad idea. Even though there are no internet police, sometimes it actually does help to be able to point to an RFC and say "See - it says that's wrong right here". I'd prefer to keep it. Let's see what others say. > When a mail receiver decides to perform an SPF check, it MUST use a > correctly-implemented check_host() function (Section 4) evaluated with > the correct parameters. Although the test as a whole is optional, once > it has been decided to perform a test it has to be performed as > specified so that the correct semantics are preserved between > publisher and receiver. > > If people haven't already figured out that they have to implement the > spec correctly, this won't help. I suggest removing it. It was in RFC 4408 that way, so keeping it is consistent, but I'm OK with removing it if we keep the other language in your previous point. > 2.6. Results of Evaluation > > An SPF verifier implements something semantically identical to the > function defined there. > > Suggest "semantically equivalent" to match langauge in Sec 4. Fixed locally. > 3. SPF Records > > The SPF record is a single string of text. > > Suggest "The SPF record is interpreted as a single string of text" since in > fact the record may well have several strings. Fixed locally. > 8.4. Fail > > Suggest moving everything after the first paragraph to App. H.2. since > it's basically an example. > > 8.5. Softfail > > Suggest moving everything after the first paragraph to a new > subsection of App. H. Please do our users a favor and remove the bad > advice about highlighting failures in MUAs. For both your comments on Fail and Softfail, my perspective is the same: We have been through what goes in the main body and what goes into an appendix several times and finally got to something people are roughly happy with. I would propose not having the 4408bis organization discussion again. If people are really unhappy with the organization, I have several comments against it as well that I'll submit, but I think that we're better off to leave well enough alone. > 9.2. SPF Results in the Authentication-Results Header Field > > Odd bug in the xml, the last para and example are switched in > the html output. I found one oddity in the XML. The output now looks like: > 9.2. SPF Results in the Authentication-Results Header Field > > As mentioned in Section 9, the Authentication-Results header field is > designed to communicate lists of tests a border MTA did and their > results. The specified elements of the field provide less > information than the Received-SPF field: > > Authentication-Results: myhost.example.org; spf=pass > smtp.mailfrom=example.net > > Received-SPF: pass (myhost.example.org: domain of > myname@example.com designates 192.0.2.1 as permitted sender) > receiver=mybox.example.org; client-ip=192.0.2.1; > envelope-from="myname@example.com"; helo=foo.example.com; > > It is, however, possible to add CFWS in the "reason" part of an > > Authentication-Results header field and provide the equivalent > information, if desired. > > As an example, an expanded Authentication-Results header field might > look like (for a "MAIL FROM" check in this example): > > Authentication-Results: myhost.example.org; spf=pass > reason="client-ip=192.0.2.1; smtp.helo=foo.example.com" > smtp.mailfrom=user@example.net Is that more like what you were expecting? Thanks for the review. Scott K From johnl@iecc.com Sat Apr 20 16:32: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 2A7CF21F91BF for ; Sat, 20 Apr 2013 16:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18TnfIcDCXC6 for ; Sat, 20 Apr 2013 16:32:52 -0700 (PDT) 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 40A4F21F9156 for ; Sat, 20 Apr 2013 16:32:52 -0700 (PDT) Received: (qmail 10453 invoked from network); 20 Apr 2013 23:34:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Apr 2013 23:34:25 -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; s=517325a3.xn--yuvv84g.k1304; i=johnl@user.iecc.com; bh=WUEZvALwGPi2DyBGBzXDsEAAXzfwS9a+XQlk6drL3P8=; b=Rrq/Uex8bK/uhqdXNZr56WGf/nY3sjZeqbp/xHkSHVyz04s/S45ZKzooVhE0heuGDW2J9tq/Ui7EqZa+7OGKIJQ4SsasClqZvzfnlLbyhdvyKgLTPiUOvmbmiiWXD0psduHB+hq/OQ4jdpL7vECnh2d3sKsSw2pTczinwWnTnhY= 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; s=517325a3.xn--yuvv84g.k1304; olt=johnl@user.iecc.com; bh=WUEZvALwGPi2DyBGBzXDsEAAXzfwS9a+XQlk6drL3P8=; b=3JJF9Mx/XgbicFso48JioXv9F7rcAlNf1k1B8yJrPolRNlAqCGpbk4HQ/pwgtsXI1WCdX31aahNshcUv+JkNrXwMeZIJvwuU2I6sM7lKikM+pymjHOiin8jpgOi+xtwVRidhKGlF/sLW8C6KkF0uV/uZ7bJHhb8LmWCX86WRmSk= Date: 20 Apr 2013 23:32:29 -0000 Message-ID: <20130420233229.47086.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1903338.omVMzuiKyh@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] WGLC: draft-ietf-spfbis-4408bis-14 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, 20 Apr 2013 23:32:53 -0000 >> Checking "HELO" promotes consistency of results and can reduce DNS >> resource usage. >> >> I understand the consistency, but how does doing two lookups rather >> than one reduce DNS resource usage? Suggest just removing the second >> clause. > >Generally, the SPF record for HELO requires at most one additional DNS lookup, >so even if you have a relatively low rejection rate base on these records, you >can come out ahead on resource expenditure because it's generally an >inexpensive check compared to Mail From records. Well, maybe. If someone says "HELO hotmail.com" as some spamware has been known to do, you're going to do a lot of extra work before you look at the Mail From. >We have been through what goes in the main body and what goes into an appendix >several times and finally got to something people are roughly happy with. I >would propose not having the 4408bis organization discussion again. If people >are really unhappy with the organization, I have several comments against it >as well that I'll submit, but I think that we're better off to leave well >enough alone. If moving this stuff requires a lot of argument, I agree it's not worth it. >I found one oddity in the XML. The output now looks like: ... >Is that more like what you were expecting? Yup. R's, John From spf2@kitterman.com Sat Apr 20 16: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 D633621F88E6 for ; Sat, 20 Apr 2013 16:40:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3bjBs+iNmJ2 for ; Sat, 20 Apr 2013 16:40:04 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CACDE21F888F for ; Sat, 20 Apr 2013 16:40:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3C32920E40D2; Sat, 20 Apr 2013 19:39:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366501194; bh=QrgwkO8ivBNTNFKHs9Um8TT4sw54nvGXiOnTurNjbZw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fpobXCfDB0rbIVqd0PZat++xUzr8LkDjl9/WGMXgw6+zF6F73pMGsD0b5RXiuHucu AmWrcJHD2l3zI/zO2PNj/b8s9eljqMfAGlXg3p7y8KeWHUwex0sg11JN8tHSpuV2qw ETb2b0OuYjsv8DyPXpnxcPNU58HYZhF5CcSuRAeI= 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 1F86B20E409E; Sat, 20 Apr 2013 19:39:53 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 20 Apr 2013 19:39:52 -0400 Message-ID: <4648119.hrfo14norY@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <20130420233229.47086.qmail@joyce.lan> References: <20130420233229.47086.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] WGLC: draft-ietf-spfbis-4408bis-14 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, 20 Apr 2013 23:40:05 -0000 On Saturday, April 20, 2013 11:32:29 PM John Levine wrote: > >> Checking "HELO" promotes consistency of results and can reduce DNS > >> > >> resource usage. > >> > >> I understand the consistency, but how does doing two lookups rather > >> than one reduce DNS resource usage? Suggest just removing the second > >> clause. > > > >Generally, the SPF record for HELO requires at most one additional DNS > >lookup, so even if you have a relatively low rejection rate base on these > >records, you can come out ahead on resource expenditure because it's > >generally an inexpensive check compared to Mail From records. > > Well, maybe. If someone says "HELO hotmail.com" as some spamware has > been known to do, you're going to do a lot of extra work before you > look at the Mail From. That's why it says "can reduce", not "does reduce". In my experience, it's generally a savings, but there are certainly cases where it's not. (snipped the rest since I vote let's not argue). Scott K From vesely@tana.it Sun Apr 21 03:27: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 0170A21F8EC7 for ; Sun, 21 Apr 2013 03:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCoa11hQH3qN for ; Sun, 21 Apr 2013 03:27:08 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0F66721F84F5 for ; Sun, 21 Apr 2013 03:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366540025; bh=R/EjydANkJ6MMdKOZqlZJOGVZBpcd8mEHpri55ApCdY=; l=1041; h=Date:From:To:References:In-Reply-To; b=sUO8CRi66zC+VmnNkvvb+B46bFAXqHTr2FxZdVFmxZXDJ3vggWf/0wb6lo6+d4X/p y4qPkTXr+fWYeZ2E+ZhvC5dkmqj/l1n7fVCjSx3KQw9OgNjVxYp19sP2Wv0zwrxEsJ lA1SGAFsyTpDzRHVvoRyGWKD108GrR646phyILQo= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [10.57.167.221] (93-32-176-237.ip34.fastwebnet.it [93.32.176.237]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sun, 21 Apr 2013 12:27:05 +0200 id 00000000005DC044.000000005173BEF9.00001BDB Message-ID: <5173BEF0.10707@tana.it> Date: Sun, 21 Apr 2013 12:26:56 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: spfbis@ietf.org References: <51726641.7070606@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 21 Apr 2013 10:27:09 -0000 I gather there are better means to signify requirement than to spread a subject across multiple places. But then I'm almost 60 and I won't earn any more or less money if the spec will be more comprehensible, so I'll keep rather dispassionate on that topic. On Sat 20/Apr/2013 19:19:58 +0200 Murray S. Kucherawy wrote: > On Sat, Apr 20, 2013 at 2:56 AM, Alessandro Vesely wrote: > >> Of course, it is also possible to reject after receiving the content. >> It is not typical of SPF implementations to do so. Early rejection may >> conflict with DMARC and similar policies, and the point of this issue is >> that an explicit note can save readers the time to puzzle it out >> themselves, and possibly avoid some misunderstanding. > > We should absolutely not discuss DMARC or other layers here. That's what I want to clarify. SPF does not separate algorithm from policy in the same way that DKIM is separated from ADSP. How can DMARC specify an interface to the SPF layer if SPF does not provide for one? From vesely@tana.it Sun Apr 21 04:51: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 EA54521F8EB5 for ; Sun, 21 Apr 2013 04:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVnn4svadjeL for ; Sun, 21 Apr 2013 04:51:41 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D22CB21F8EBE for ; Sun, 21 Apr 2013 04:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366545099; bh=yIJF/1rP1TOfIZyJQHhGo8XkfdJcH5B3Qk1BFqZVdq4=; l=2671; h=Date:From:To:References:In-Reply-To; b=Q+UFAflBED9RctLYljz5isMVp4uKIoYcfKWiBxN+nZVfYpTV5X0LXOBIF3IpXjSOz otVGlCau/2avu20JHKlvYFBVQ2o/vGo/W0lNaJW0nvuxp0L7TRHHbiJG0HDd6biRTb oSvFNK5syB/9IG6/CL9P1u8QJAg/PPFraWUNinl4= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [10.57.167.221] (93-32-176-237.ip34.fastwebnet.it [93.32.176.237]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sun, 21 Apr 2013 13:51:39 +0200 id 00000000005DC03F.000000005173D2CB.0000220C Message-ID: <5173D2CA.6010008@tana.it> Date: Sun, 21 Apr 2013 13:51:38 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130409062431.GK24624@mx1.yitter.info> <9424963.YHzqPUZEKJ@scott-latitude-e6320> <517030ED.20501@tana.it> <5830786.tCECZPYMZs@scott-latitude-e6320> In-Reply-To: <5830786.tCECZPYMZs@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 21 Apr 2013 11:51:42 -0000 On Sun 21/Apr/2013 00:06:00 +0200 Scott Kitterman wrote: > On Thursday, April 18, 2013 07:44:13 PM Alessandro Vesely wrote: >> On Wed 17/Apr/2013 03:51:07 +0200 Scott Kitterman wrote: >>> On Tuesday, April 09, 2013 02:24:32 AM Andrew Sullivan wrote: >>>> WGLC will close at 2014-04-24 00:00 UTC. >>> >>> Just as a reminder, we're ~half way through the WGLC period >> >> Oh, you mean the close date was a typo? > > No. April 17 is roughly half way between April 9 and April 24. Of 2013... ;-) >> 6.1. *redirect: Redirected Query* >> >> There is no statement on whether redirect= can be applied by an >> "include" mechanism. > > I don't understand the question? Section 6 says: These two modifiers MUST NOT appear in a record more than once each. So it seems it is possible to specify "redirect" in one or more included records, as well as in redirected record. Defining the redirect during a recursive call looks less safe and is not common. Is it legal? >> 10.1.2. Administrator's Considerations >> >> changes are common, it is better to use the less resource intensive >> mechanisms like "ip4" and "ip6" over "a" or "a" or "mx". >> >> s/"a" or "mx"/"a" over "mx"/ >> >> The hostname is generally the identity used in the 5321.HELO/.EHLO >> command. In the case of messages with a null 5321.MailFrom, this is >> used as the domain for 5321.MailFrom SPF checks, in addition to being >> used in 5321.HELO/.EHLO based SPF checks. >> >> "hostname" is called "domain" in the previous paragraph, and the long >> slash-dot form of the names is used. In addition to reword that, it >> may be worth to note that x@relay.example.com can be used as an >> address even if there's no corresponding MX. > > I'm not sure what you're after here, would you please provide text so I can > better understand? Also, due to the implicit MX fallback to A, any host with > an A record can receiver mail, so I don't understand why "evern if there's no > MX" is relevant to anything. Perhaps: Domain names can refer to both individual hosts or mail domains. Albeit "HELO" identities happen to be individual hosts more frequently than "MAIL FROM", either can be used to form an email address, and "HELO" can be the only identity available. A standard SPF record for an individual host that is involved in mail sending is: ? >> H.4. Policy For SPF Temperror >> >> The "temperror" result (see Section 2.6.6) indicates the SPF >> processing module at the receiver could not retrieve and SPF policy ...........................................................^^^ >> [...] > > How's that? WFM, albeit lengthy. From spf2@kitterman.com Sun Apr 21 07:29: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 4B24B21F84D6 for ; Sun, 21 Apr 2013 07:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwtoM31baAsz for ; Sun, 21 Apr 2013 07:29:10 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8313221F84CD for ; Sun, 21 Apr 2013 07:29:10 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 61950D0407E; Sun, 21 Apr 2013 09:29:09 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366554549; bh=8PKoxp8qpzuE8/ke1kqsYGyFC2ouYjR4B62efCUNXzc=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Zt2Oj9tgqmFeSUtt1ehJgAAJr3QOM+smTvobyrycnMHtDsL4pkNW9Fm1O3Pi4Ku2A pGF0RBYUl7tlrOqRZAvAveMc+JwYmyA6yb3XRkS3dHdHsVd6JVcS1uvS5akZNOjUAl o/jXXvz9X/DUj1py1AmUiBk6vvT2nwFfhr3Ch4FU= Received: from [IPV6:2600:1003:b027:cc1:496d:2ade:177c:325b] (unknown [IPv6:2600:1003:b027:cc1:496d:2ade:177c:325b]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EE55CD04056; Sun, 21 Apr 2013 09:29:08 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <5173D2CA.6010008@tana.it> References: <20130409062431.GK24624@mx1.yitter.info> <9424963.YHzqPUZEKJ@scott-latitude-e6320> <517030ED.20501@tana.it> <5830786.tCECZPYMZs@scott-latitude-e6320> <5173D2CA.6010008@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 21 Apr 2013 10:29:05 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 21 Apr 2013 14:29:11 -0000 Alessandro Vesely wrote: > On Sun 21/Apr/2013 00:06:00 +0200 Scott Kitterman wrote: >> On Thursday, April 18, 2013 07:44:13 PM Alessandro Vesely wrote: >>> On Wed 17/Apr/2013 03:51:07 +0200 Scott Kitterman wrote: >>>> On Tuesday, April 09, 2013 02:24:32 AM Andrew Sullivan wrote: > >>>>> WGLC will close at 2014-04-24 00:00 UTC. >>>> >>>> Just as a reminder, we're ~half way through the WGLC period >>> >>> Oh, you mean the close date was a typo? >> >> No. April 17 is roughly half way between April 9 and April 24. > >Of 2013... ;-) > >>> 6.1. *redirect: Redirected Query* >>> >>> There is no statement on whether redirect= can be applied by an >>> "include" mechanism. >> >> I don't understand the question? > >Section 6 says: > > These two modifiers MUST NOT appear in a record more than once each. > >So it seems it is possible to specify "redirect" in one or more >included >records, as well as in redirected record. Defining the redirect during >a recursive call looks less safe and is not common. Is it legal? Yes. I don't think we need to be explicit about it. It's rare and I think the existing text is sufficient. > >>> 10.1.2. Administrator's Considerations >>> >>> changes are common, it is better to use the less resource intensive >>> mechanisms like "ip4" and "ip6" over "a" or "a" or "mx". >>> >>> s/"a" or "mx"/"a" over "mx"/ >>> >>> The hostname is generally the identity used in the 5321.HELO/.EHLO >>> command. In the case of messages with a null 5321.MailFrom, this >is >>> used as the domain for 5321.MailFrom SPF checks, in addition to >being >>> used in 5321.HELO/.EHLO based SPF checks. >>> >>> "hostname" is called "domain" in the previous paragraph, and the >long >>> slash-dot form of the names is used. In addition to reword that, it >>> may be worth to note that x@relay.example.com can be used as an >>> address even if there's no corresponding MX. >> >> I'm not sure what you're after here, would you please provide text so >I can >> better understand? Also, due to the implicit MX fallback to A, any >host with >> an A record can receiver mail, so I don't understand why "evern if >there's no >> MX" is relevant to anything. > >Perhaps: > > Domain names can refer to both individual hosts or mail domains. > Albeit "HELO" identities happen to be individual hosts more frequently > than "MAIL FROM", either can be used to form an email address, and > "HELO" can be the only identity available. A standard SPF record > for an individual host that is involved in mail sending is: > >? Generally v=spf1 a -all works. One can also specify the IP address directly with ip4/ip6. I don't see a need to add text about this. >>> H.4. Policy For SPF Temperror >>> >>> The "temperror" result (see Section 2.6.6) indicates the SPF >>> processing module at the receiver could not retrieve and SPF >policy >...........................................................^^^ >>> [...] >> >> How's that? > >WFM, albeit lengthy. Agreed. If I'd had more time I'd have written something shorter. Given where we are in the process, text highly parallel to the permerror text the group's already reviewed seemed best. Thanks for reviewing. Scott K From superuser@gmail.com Sun Apr 21 07:53: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 2F8FA21F9019 for ; Sun, 21 Apr 2013 07:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynKDaH045rMT for ; Sun, 21 Apr 2013 07:53:50 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 797AC21F84F2 for ; Sun, 21 Apr 2013 07:53:50 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so510285wgh.2 for ; Sun, 21 Apr 2013 07:53:49 -0700 (PDT) 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=VmB9U0S523wNWKbWF6X479h/SXHXcEBiPo1S05Zh2ao=; b=ASllwn2ftthzoSD6rqxAsSTefBquWGkKdEd5Vuhv6isI65jB0eZJ6c8f4E4184TeCW bZXj9yfnPCk1VxEIlHHmidwu4f/XtTXunHOpX61+ooWqp1/ZbSZqxN/3nTvSi2DJR7Nw MKOryUwK/s/PmNepl4XCtTJcVLuFZW98PU6RWWRcFjlsxY8yDX0kvpUXp0CBYlH+c8qs cD795wGjpZSRAuVhN6LCKAdbAhc1uYNlPQsZv/r3VVw80e6UWWKWj9GqPq8uDf36g4cm P5InmtU87loQjunM8zsnygAs27JTedl846C/VIjH++YkDiU/pRFxBcUdcXo4isiq4Wck 0V7A== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr43635275wjb.15.1366556029602; Sun, 21 Apr 2013 07:53:49 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sun, 21 Apr 2013 07:53:49 -0700 (PDT) In-Reply-To: <5173BEF0.10707@tana.it> References: <51726641.7070606@tana.it> <5173BEF0.10707@tana.it> Date: Sun, 21 Apr 2013 07:53:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=089e010d8574b5d12204dae01e2e Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 21 Apr 2013 14:53:51 -0000 --089e010d8574b5d12204dae01e2e Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 21, 2013 at 3:26 AM, Alessandro Vesely wrote: > > We should absolutely not discuss DMARC or other layers here. > > That's what I want to clarify. SPF does not separate algorithm from > policy in the same way that DKIM is separated from ADSP. How can DMARC > specify an interface to the SPF layer if SPF does not provide for one? > > RFC5451 is a perfectly good interface. It works fine for OpenDMARC, for example. -MSK --089e010d8574b5d12204dae01e2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 21, 2013 at 3:26 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
> We should absolutely= not discuss DMARC or other layers here.

That's what I want to clarify. =A0SPF does not separate algorithm= from
policy in the same way that DKIM is separated from ADSP. =A0How can DMARC specify an interface to the SPF layer if SPF does not provide for one?


RFC5451 is a perfectly good interface.=A0 It works fine for OpenDMARC, fo= r example.

-MSK

--089e010d8574b5d12204dae01e2e-- From SRS0=52O0n=OJ==stuart@gathman.org Sun Apr 21 18:21: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 8320F21F86AD for ; Sun, 21 Apr 2013 18:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkzTzt5NHgrl for ; Sun, 21 Apr 2013 18:21:53 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0D321F875C for ; Sun, 21 Apr 2013 18:21:53 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (PLAIN sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1366593722; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=uf1ELnvzBvqL/aacenilZuvXy5VOa17ZzABtr6nLTLw=; b=TmFbd4jSeWseRn7Usb/zrxBryn5b9QpRHrh4voBdl5/zZvJTjgIl1ba0LmUdAAe8q1qq1N cYBSlnbkB6Hdo16S/ys5P8MyWWrwHk5Q/OwSGU8NeMVUUMARMtGNau3IHhCzDMYUX9ChDaJa q7jYgmx83yOFpOdmii14++PJPMfEo= Received: from silver.gathman.org ([IPv6:2001:470:8:809:792e:665c:d618:15ec]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3M1Lvmb008243 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 21 Apr 2013 21:22:02 -0400 Message-ID: <517490A6.5020502@gathman.org> Date: Sun, 21 Apr 2013 21:21:42 -0400 From: Stuart Gathman Organization: BWI Corporation User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130409062431.GK24624@mx1.yitter.info> <7FE87BAF-B202-4CD5-B7BA-EDABE151E142@eudaemon.net> <6.2.5.6.2.20130416214029.0c16f0b8@resistor.net> In-Reply-To: <6.2.5.6.2.20130416214029.0c16f0b8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 22 Apr 2013 02:07:30 -0000 On 04/17/2013 12:50 AM, S Moonesamy wrote: > > As Scott mentioned, things have been very quiet for this WGLC. It > helps if there are people who read the draft as you did above as I can > determine whether the working group reviewed the draft and is ok with it. Minor nit: Section 5.1 Mechanisms listed after "all" MUST be ignored. Sure, section 4.6 says If there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation. But an implementer could misinterpret this as saying the following should get Fail rather than PermError: v=spf1 mx -all foobar Section 4.6 doesn't make it clear you have to parse everything (returning permerror on syntax errors), and only *then* interpret. The wording makes it sound like you could parse and interpret one term at a time, stopping when you get a match or syntax error. From vesely@tana.it Mon Apr 22 01:12: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 046AF21F8E42 for ; Mon, 22 Apr 2013 01:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqChZggdDumV for ; Mon, 22 Apr 2013 01:12:45 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8621321F8DBB for ; Mon, 22 Apr 2013 01:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366618356; bh=8bbPX7CEvhUFgE8DgMiEcpX2Ux8wHBM089CAs4u5RUE=; l=1501; h=Date:From:To:References:In-Reply-To; b=YmXR9fFx/rtbQ+WBuPbka8mfyLtFy/RDeeDV8fuhgAHn1JqE+PtTwSmgfFlmHvJJ5 Wv723w/rwFNHci+x+UVrcVbty4XwO/aj/8Mjl9SrAAGhLFfJZP476lphPqNx7zyMdJ Qi38o0s6517mJ13DYVStp6mMCDChtOL5gMExPlk4= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 22 Apr 2013 10:12:36 +0200 id 00000000005DC035.000000005174F0F4.00003690 Message-ID: <5174F0F4.2090805@tana.it> Date: Mon, 22 Apr 2013 10:12:36 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130409062431.GK24624@mx1.yitter.info> <9424963.YHzqPUZEKJ@scott-latitude-e6320> <517030ED.20501@tana.it> <5830786.tCECZPYMZs@scott-latitude-e6320> <5173D2CA.6010008@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 22 Apr 2013 08:12:47 -0000 On Sun 21/Apr/2013 16:29:05 +0200 Scott Kitterman wrote: > Alessandro Vesely wrote: > >>>> 10.1.2. Administrator's Considerations >>>> [...] >> >> Perhaps: >> >> Domain names can refer to both individual hosts or mail domains. >> Albeit "HELO" identities happen to be individual hosts more frequently >> than "MAIL FROM", either can be used to form an email address, and >> "HELO" can be the only identity available. A standard SPF record >> for an individual host that is involved in mail sending is: >> >>? > > Generally v=spf1 a -all works. One can also specify the IP address > directly with ip4/ip6. I don't see a need to add text about this. Yeah, no doubt about the record content. The paragraph quoted from my previous message was meant to e a possible replacement for: The hostname is generally the identity used in the 5321.HELO/.EHLO command. In the case of messages with a null 5321.MailFrom, this is used as the domain for 5321.MailFrom SPF checks, in addition to being used in 5321.HELO/.EHLO based SPF checks. The standard SPF record for an individual host that is involved in mail processing is: At least, for uniformity with the rest of the document, replacement of the terms defined in Sections 1.1.3 and 1.1.4 ought to be done. The term "hostname" is used once more in the I-D, and I propose a replacement it in order to make the text smoother in Section 10.1.2. Please do what you think is better. Thank you for editing. From vesely@tana.it Mon Apr 22 01: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 1C87521F8E84 for ; Mon, 22 Apr 2013 01:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG-+yP5+b31M for ; Mon, 22 Apr 2013 01:34:01 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDFD21F8E7A for ; Mon, 22 Apr 2013 01:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366619629; bh=ZbPMZxsTCq/t21o+oFPRSaCJ6mG9FfJe4JmmIscuxhA=; l=1206; h=Date:From:To:References:In-Reply-To; b=RVXX9brlneN/fMKSt64vCyKnSSiGK48DYUiTztKip27tFMg8rp1fKtQa7gDcHVaoB xGX5bm9bUirOMFqeuGUitzdfAhW1QuIXywbRW/yXK2ECb6CUu6OrVdQ/wLFAPQv/zh 25TO08UiMCNLsNyy9XKaaH2OiOlgX7+nXKvRFJuU= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 22 Apr 2013 10:33:49 +0200 id 00000000005DC035.000000005174F5ED.000019AD Message-ID: <5174F5ED.4080303@tana.it> Date: Mon, 22 Apr 2013 10:33:49 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <51726641.7070606@tana.it> <5173BEF0.10707@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 22 Apr 2013 08:34:02 -0000 On Sun 21/Apr/2013 16:53:49 +0200 Murray S. Kucherawy wrote: > On Sun, Apr 21, 2013 at 3:26 AM, Alessandro Vesely wrote: > >>> We should absolutely not discuss DMARC or other layers here. >> >> That's what I want to clarify. SPF does not separate algorithm from >> policy in the same way that DKIM is separated from ADSP. How can DMARC >> specify an interface to the SPF layer if SPF does not provide for one? > > RFC5451 is a perfectly good interface. It works fine for OpenDMARC, for > example. Hm... RFC 5451 has phrases like 'if, for example, [SPF] returned as "pass" result'. It is not clear whether that refers to the result of the check_host() function rather than, considering Section 4.2 "Local Policy Enforcement", the combined result of check_host() and local policy up to that point in the processing. As a further example, Section 7.3 of RFC 5518 is formally ambiguous too, because SPF could produce a "pass" result by validating the "HELO" identity, and then VBR would be checked against a possibly spoofed . Notwithstanding the loads of gratuitous advice we write, it seems we're still missing crispy definitions of SPF results :-( From spf2@kitterman.com Mon Apr 22 07:04: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 BD06321F8681 for ; Mon, 22 Apr 2013 07:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boLx7Jh38Bdf for ; Mon, 22 Apr 2013 07:04:23 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 055AE21F870F for ; Mon, 22 Apr 2013 07:04:23 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 299E420E410C; Mon, 22 Apr 2013 10:04:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366639462; bh=HAGhC3s8BoXEJbyn/paJpdKDIs7uq8JBQHU8AcIqj6A=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bADcZVL66nEzUC/WfYypLsJ66mNUr7x03VaBR0QWEfUJ49Os/xf8JXvVECv+GUX0k UuUG9WqwfpH66TRPC4VYr77VpgJ7mDmp+ltXEVWIRI3dS5OR3FKPSLNLTc+6GI/sdf M6NAc+ep2vLb4gOE6PI+GY4SYbjWFdenS5J5Xe50= 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 0BDF320E40CD; Mon, 22 Apr 2013 10:04:11 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 22 Apr 2013 10:04:11 -0400 Message-ID: <17085583.vi2SDUBAix@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <517490A6.5020502@gathman.org> References: <20130409062431.GK24624@mx1.yitter.info> <6.2.5.6.2.20130416214029.0c16f0b8@resistor.net> <517490A6.5020502@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] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 22 Apr 2013 14:04:23 -0000 On Sunday, April 21, 2013 09:21:42 PM Stuart Gathman wrote: > On 04/17/2013 12:50 AM, S Moonesamy wrote: > > As Scott mentioned, things have been very quiet for this WGLC. It > > helps if there are people who read the draft as you did above as I can > > determine whether the working group reviewed the draft and is ok with it. > > Minor nit: > > Section 5.1 > > Mechanisms listed after "all" MUST be ignored. > > Sure, section 4.6 says > > If there are any syntax errors > anywhere in the record, check_host() returns immediately with the > result "permerror", without further interpretation. > > But an implementer could misinterpret this as saying the following > should get Fail rather than PermError: > > v=spf1 mx -all foobar > > Section 4.6 doesn't make it clear you have to parse everything > (returning permerror on syntax errors), and only *then* interpret. The > wording makes it sound like you could parse and interpret one term at a > time, stopping when you get a match or syntax error. I would tend to favor the MUST be ignored over the returns immediately with a permerror (yielding the opposed view of the preferred result from yours). I think this confirms there's an ambiguity in the current draft. If I take your view that it's better to raise the error (unknown mechanism), the perhaps changing the 5.1 language would help. Adding the sentence before in, for more context: > Mechanisms after "all" will never be tested. Mechanisms listed after "all" > MUST be ignored. Perhaps if we combine those it helps: > Mechanisms after "all" MUST not be tested. Mechanisms listed after "all" > will be ignored for all purposes except syntax error evaluation. Does that help? Scott K From spf2@kitterman.com Mon Apr 22 07:26: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 AA5E211E80A6 for ; Mon, 22 Apr 2013 07:26:10 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGuN5moVlSNm for ; Mon, 22 Apr 2013 07:26:09 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C8B5211E80A3 for ; Mon, 22 Apr 2013 07:26:08 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5693720E410C; Mon, 22 Apr 2013 10:26:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366640768; bh=9hWq2uF0KneAnz0Bh5o2gPlRmSKl9eDW0BxCjWBYGl8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iVSHY6PGMs7owzd/eevXVRYK0z7sZsoj/jFSS5JPLfP5qui3J3jUhQj3EOAvkKzJU yjL0J+9BxhPc0Glasikjs+ODzsEHYQ1fT1FtU8S/iJ45KW4NafH50vu73S0Z68gwlq sAOkDluSew5HMFnR8lg56UYASgW8JtiU7/tdBvwY= 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 3B55E20E40CD; Mon, 22 Apr 2013 10:26:07 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 22 Apr 2013 10:26:07 -0400 Message-ID: <6835793.IxuTqepqcv@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <5174F0F4.2090805@tana.it> References: <20130409062431.GK24624@mx1.yitter.info> <5174F0F4.2090805@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] WGLC: draft-ietf-spfbis-4408bis-14 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, 22 Apr 2013 14:26:10 -0000 On Monday, April 22, 2013 10:12:36 AM Alessandro Vesely wrote: > On Sun 21/Apr/2013 16:29:05 +0200 Scott Kitterman wrote: > > Alessandro Vesely wrote: > >>>> 10.1.2. Administrator's Considerations > >>>> [...] > >> > >> Perhaps: > >> Domain names can refer to both individual hosts or mail domains. > >> Albeit "HELO" identities happen to be individual hosts more frequently > >> than "MAIL FROM", either can be used to form an email address, and > >> "HELO" can be the only identity available. A standard SPF record > >> > >> for an individual host that is involved in mail sending is: > >>? > >> > > Generally v=spf1 a -all works. One can also specify the IP address > > directly with ip4/ip6. I don't see a need to add text about this. > > Yeah, no doubt about the record content. The paragraph quoted from my > previous message was meant to e a possible replacement for: Sorry about that. That's what I get for not looking in the draft for context, I didn't realize you were quoting. > The hostname is generally the identity used in the 5321.HELO/.EHLO > command. In the case of messages with a null 5321.MailFrom, this is > used as the domain for 5321.MailFrom SPF checks, in addition to being > used in 5321.HELO/.EHLO based SPF checks. The standard SPF record > for an individual host that is involved in mail processing is: > > At least, for uniformity with the rest of the document, replacement of > the terms defined in Sections 1.1.3 and 1.1.4 ought to be done. The > term "hostname" is used once more in the I-D, and I propose a > replacement it in order to make the text smoother in Section 10.1.2. > > Please do what you think is better. Thank you for editing. I think hostname is sufficiently standard that it's OK to use there and appropriate because we're generally referring to the name of and individual host and not a domain that may have multiple hosts. Any other opinions? Scott K > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From kurta@drkurt.com Mon Apr 22 07:40: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 3B09A21E808F for ; Mon, 22 Apr 2013 07:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mIKvCnC77OV for ; Mon, 22 Apr 2013 07:40:17 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A936C21E8063 for ; Mon, 22 Apr 2013 07:40:16 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u3so3473895wey.38 for ; Mon, 22 Apr 2013 07:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20110616; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wL71GEDqP0oq0BOsFHjH1Gl+Q6JSVr0TmBWZzC+4AQk=; b=eBJVEJCoGuTHH6OjzqYzc7sf1al/RF1fpyL/qLJ2tv21+uoyA8Ed8rhctSWLukbbkD ybyQEua8OKpaL3fbjLcZCl++HnORIClOYmGckVr7RjYPkyA4UTIhOCdSIlGog3oAiVfZ wSoRH4A0xqyArr3DHWBIvJ/hxNbtOX3g5ZHmY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.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 :x-gm-message-state; bh=wL71GEDqP0oq0BOsFHjH1Gl+Q6JSVr0TmBWZzC+4AQk=; b=Gboyy9y6Yrsf680sVAdxxrMR3n5WDS7bXrix8Sz33Nn0dCsk1aHbkXMUfZ1ewp35i3 Skb00CE0Do2IAY8AkqSWOCcWkCMqjhSjnhUyGoHXkQ3Tf1MlpPvJjcIankjgN9S2QuhF HlKypq0Vocy6OtqfWZ+NK/CPnQBheGBFykhzoAdEYm8oyHiXQRg3HEkoNMEGlvuoZlcP +5/+r4/+HXDyBk+SAiD/w8qHfwj6TMvXVI/Z5Uz/3NLHEfvGcqNXLhM0eF3ojisTtmIL iugvk/FyAUzhqUojasY17BkZ8tB0MiEE1XFhZ3j8mxKpDPPN9Fj4F+rGNRHgCz7OYIUV +Rsw== MIME-Version: 1.0 X-Received: by 10.194.11.70 with SMTP id o6mr53187624wjb.29.1366641615137; Mon, 22 Apr 2013 07:40:15 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.65.98 with HTTP; Mon, 22 Apr 2013 07:40:14 -0700 (PDT) In-Reply-To: <17085583.vi2SDUBAix@scott-latitude-e6320> References: <20130409062431.GK24624@mx1.yitter.info> <6.2.5.6.2.20130416214029.0c16f0b8@resistor.net> <517490A6.5020502@gathman.org> <17085583.vi2SDUBAix@scott-latitude-e6320> Date: Mon, 22 Apr 2013 07:40:14 -0700 X-Google-Sender-Auth: 9aOoqcoHPagybq6VHASqpTEBymM Message-ID: From: Kurt Andersen To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7b5d456c0184e304daf40cd7 X-Gm-Message-State: ALoCoQl9kVjVMvcTHVIpj80qPcVUXTNPXeAz10O6vH0lBEHfBLlXEQntKfZtXs0z6WvdX3e5TG2y Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 22 Apr 2013 14:40:18 -0000 --047d7b5d456c0184e304daf40cd7 Content-Type: text/plain; charset=ISO-8859-1 That leaves the ambiguity of handling -all in embedded (include:) records. What should be done if the sample foobar mechanism is being referenced in an included record? --Kurt On Mon, Apr 22, 2013 at 7:04 AM, Scott Kitterman wrote: > On Sunday, April 21, 2013 09:21:42 PM Stuart Gathman wrote: > > On 04/17/2013 12:50 AM, S Moonesamy wrote: > > > As Scott mentioned, things have been very quiet for this WGLC. It > > > helps if there are people who read the draft as you did above as I can > > > determine whether the working group reviewed the draft and is ok with > it. > > > > Minor nit: > > > > Section 5.1 > > > > Mechanisms listed after "all" MUST be ignored. > > > > Sure, section 4.6 says > > > > If there are any syntax errors > > anywhere in the record, check_host() returns immediately with the > > result "permerror", without further interpretation. > > > > But an implementer could misinterpret this as saying the following > > should get Fail rather than PermError: > > > > v=spf1 mx -all foobar > > > > Section 4.6 doesn't make it clear you have to parse everything > > (returning permerror on syntax errors), and only *then* interpret. The > > wording makes it sound like you could parse and interpret one term at a > > time, stopping when you get a match or syntax error. > > I would tend to favor the MUST be ignored over the returns immediately > with a > permerror (yielding the opposed view of the preferred result from yours). > I > think this confirms there's an ambiguity in the current draft. > > If I take your view that it's better to raise the error (unknown > mechanism), > the perhaps changing the 5.1 language would help. Adding the sentence > before > in, for more context: > > > Mechanisms after "all" will never be tested. Mechanisms listed after > "all" > > MUST be ignored. > > Perhaps if we combine those it helps: > > > Mechanisms after "all" MUST not be tested. Mechanisms listed after "all" > > will be ignored for all purposes except syntax error evaluation. > > Does that help? > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --047d7b5d456c0184e304daf40cd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That leaves the ambiguity of handling -all in embedde= d (include:) records.=A0 What should be done if the sample foobar mechanism= is being referenced in an included record?

--Kurt


On Mon, Apr 22, 2013 at 7:04 AM, Scott K= itterman <spf2@kitterman.com> wrote:
On Sunday, April 21, 2013 09:21:42 PM Stuart Gathman wrot= e:
> On 04/17/2013 12:50 AM, S Moonesamy wrote:
> > As Scott mentioned, things have been very quiet for this WGLC. = =A0It
> > helps if there are people who read the draft as you did above as = I can
> > determine whether the working group reviewed the draft and is ok = with it.
>
> Minor nit:
>
> Section 5.1
>
> Mechanisms listed after "all" MUST be ignored.
>
> Sure, section 4.6 says
>
> If there are any syntax errors
> =A0 =A0 anywhere in the record, check_host() returns immediately with = the
> =A0 =A0 result "permerror", without further interpretation.<= br> >
> But an implementer could misinterpret this as saying the following
> should get Fail rather than PermError:
>
> v=3Dspf1 mx -all foobar
>
> Section 4.6 doesn't make it clear you have to parse everything
> (returning permerror on syntax errors), and only *then* interpret. The=
> wording makes it sound like you could parse and interpret one term at = a
> time, stopping when you get a match or syntax error.

I would tend to favor the MUST be ignored over the returns immediatel= y with a
permerror (yielding the opposed view of the preferred result from yours). = =A0I
think this confirms there's an ambiguity in the current draft.

If I take your view that it's better to raise the error (unknown mechan= ism),
the perhaps changing the 5.1 language would help. =A0Adding the sentence be= fore
in, for more context:

> Mechanisms after "all" will never be tested. =A0Mechanisms l= isted after "all"
> MUST be ignored.

Perhaps if we combine those it helps:

> Mechanisms after "all" MUST not be tested. =A0Mechanisms lis= ted after "all"
> will be ignored for all purposes except syntax error evaluation.

Does that help?

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

--047d7b5d456c0184e304daf40cd7-- From spf2@kitterman.com Mon Apr 22 07:47: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 1BB4F21E8098 for ; Mon, 22 Apr 2013 07:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrZmEGbl1jkg for ; Mon, 22 Apr 2013 07:47:43 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B56BA21E8096 for ; Mon, 22 Apr 2013 07:47:43 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 44E7C20E410C; Mon, 22 Apr 2013 10:47:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366642063; bh=/7kxl4kbW8rO3SoI+MlHZaSAwdDH00IKKfkKuRz5Rtc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RnYMxVoy+00NGtF3CpWurM9zCWAuJPNr58cs8j6jRfh9dOO1HycQhg8ZL0sL/HS0E F32LLTdgwfbpfIgRy/f8yqBEvKv0LAKwfctfEgJmOoSAKTthuzzUavhwnTAXCAufzu of/ZQth1ERLV/mKeBSVywd3kYUAQVhoYXAc9hXBw= 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 3464A20E40CD; Mon, 22 Apr 2013 10:47:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 22 Apr 2013 10:47:42 -0400 Message-ID: <18983729.OXGN2viB33@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <20130409062431.GK24624@mx1.yitter.info> <17085583.vi2SDUBAix@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] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 22 Apr 2013 14:47:44 -0000 I don't think so. An included record only gets match/notmatch or some error. The qualifier for the 'all' mechanism in the included record doesn't enter into it. Scott K On Monday, April 22, 2013 07:40:14 AM Kurt Andersen wrote: > That leaves the ambiguity of handling -all in embedded (include:) records. > What should be done if the sample foobar mechanism is being referenced in > an included record? > > --Kurt > > On Mon, Apr 22, 2013 at 7:04 AM, Scott Kitterman wrote: > > On Sunday, April 21, 2013 09:21:42 PM Stuart Gathman wrote: > > > On 04/17/2013 12:50 AM, S Moonesamy wrote: > > > > As Scott mentioned, things have been very quiet for this WGLC. It > > > > helps if there are people who read the draft as you did above as I can > > > > determine whether the working group reviewed the draft and is ok with > > > > it. > > > > > Minor nit: > > > > > > Section 5.1 > > > > > > Mechanisms listed after "all" MUST be ignored. > > > > > > Sure, section 4.6 says > > > > > > If there are any syntax errors > > > > > > anywhere in the record, check_host() returns immediately with the > > > result "permerror", without further interpretation. > > > > > > But an implementer could misinterpret this as saying the following > > > should get Fail rather than PermError: > > > > > > v=spf1 mx -all foobar > > > > > > Section 4.6 doesn't make it clear you have to parse everything > > > (returning permerror on syntax errors), and only *then* interpret. The > > > wording makes it sound like you could parse and interpret one term at a > > > time, stopping when you get a match or syntax error. > > > > I would tend to favor the MUST be ignored over the returns immediately > > with a > > permerror (yielding the opposed view of the preferred result from yours). > > > > I > > > > think this confirms there's an ambiguity in the current draft. > > > > If I take your view that it's better to raise the error (unknown > > mechanism), > > the perhaps changing the 5.1 language would help. Adding the sentence > > before > > > > in, for more context: > > > Mechanisms after "all" will never be tested. Mechanisms listed after > > > > "all" > > > > > MUST be ignored. > > > > Perhaps if we combine those it helps: > > > Mechanisms after "all" MUST not be tested. Mechanisms listed after > > > "all" > > > will be ignored for all purposes except syntax error evaluation. > > > > Does that help? > > > > Scott K > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From johnl@iecc.com Mon Apr 22 07:54: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 840BF21F8BDE for ; Mon, 22 Apr 2013 07:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW5ZF4fZ29Gf for ; Mon, 22 Apr 2013 07:54:51 -0700 (PDT) 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 A62C421F8EE1 for ; Mon, 22 Apr 2013 07:54:50 -0700 (PDT) Received: (qmail 59406 invoked from network); 22 Apr 2013 14:56:31 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Apr 2013 14:56:31 -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; s=51754f37.xn--yuvv84g.k1304; i=johnl@user.iecc.com; bh=6/F7jXQcTdrWvMGAUxmDnqDrHSsm9kFLRiwZ9EIOZBY=; b=Ex3XQmi07YZKndlne67Mhm06AnCCV76qTqMWVK4Ffj6AC74nmoqbbPmPXc9lzA51EFm7XPSYW5ah80xLAvWKMuOBtXGHy8TwPBCQfI3jKDQZTObSxEtEeAPzxS3JyLERlko5vLlWdA+jo2h9MUQ7VaN9QaT0HDXNhkBBbcZFxuY= 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; s=51754f37.xn--yuvv84g.k1304; olt=johnl@user.iecc.com; bh=6/F7jXQcTdrWvMGAUxmDnqDrHSsm9kFLRiwZ9EIOZBY=; b=lvQvEAK/lOl+dz/HSq4UhotFtSTpcHaaWPlDtqIPrbaY2AXfg5B2snURxk6Fr6B6c0w9KsLRaWpZgTU+RWCYGFkCsrODL+EOVYzCDeZIlx1JcwdruQYIe+5Pd+jRjc/3p0r3AOlEYII1gjs+8xzesl+CZ/nTP+z5H7XvmxNvJjM= Date: 22 Apr 2013 14:54:25 -0000 Message-ID: <20130422145425.18526.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: kboth@drkurt.com Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 22 Apr 2013 14:54:51 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >That leaves the ambiguity of handling -all in embedded (include:) records. >What should be done if the sample foobar mechanism is being referenced in >an included record? At this point, I think we have to say that stuff like that is undefined, since in reality it does whatever the code does, and it happens so rarely that nobody cares. Remember that a standard needs to tell people what to do to interoperate, but it doesn't have to tell you want to do if someone else screws up. R's, John From vesely@tana.it Mon Apr 22 08:48: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 0D5F221F911E for ; Mon, 22 Apr 2013 08:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3wPht8HwPUa for ; Mon, 22 Apr 2013 08:48:35 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id EC6E221F9128 for ; Mon, 22 Apr 2013 08:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366645713; bh=dj5cNgtbh0MZFgdQ0xs5WNwR2BA2fCqCquKMkvEEznI=; l=974; h=Date:From:To:References:In-Reply-To; b=WiFYZTqXz/nfOjXssF7tRtc5fI6w0ZxYh+WB2Obe6vRdq9YTjc4YNFzGWmfjbngah LXDNABHO2fnwmx1dVCnwBbo7FwVDpreH2m6XCIq5mXcfnStc9FKU8E+Fl8RS2mm4Fe oXrm6gGcWs6Z7J/6A19eUYZaGi2hv3E4hfMSCIAI= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 22 Apr 2013 17:48:33 +0200 id 00000000005DC039.0000000051755BD1.000004CC Message-ID: <51755BD1.5080106@tana.it> Date: Mon, 22 Apr 2013 17:48:33 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130409062431.GK24624@mx1.yitter.info> <6.2.5.6.2.20130416214029.0c16f0b8@resistor.net> <517490A6.5020502@gathman.org> <17085583.vi2SDUBAix@scott-latitude-e6320> In-Reply-To: <17085583.vi2SDUBAix@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 22 Apr 2013 15:48:36 -0000 On Mon 22/Apr/2013 16:04:11 +0200 Scott Kitterman wrote: > > If I take your view that it's better to raise the error (unknown mechanism), > the perhaps changing the 5.1 language would help. Adding the sentence before > in, for more context: > >> Mechanisms after "all" will never be tested. Mechanisms listed after "all" >> MUST be ignored. > > Perhaps if we combine those it helps: > >> Mechanisms after "all" MUST not be tested. Mechanisms listed after "all" >> will be ignored for all purposes except syntax error evaluation. > > Does that help? Nope, IMHO it's better as is now. That is: CURRENT If there are any syntax errors EQUIVALENT-FROM-A-PRAGMATIC-POV If any syntax errors are found anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation. See also http://tools.ietf.org/wg/spfbis/trac/ticket/26 and http://www.ietf.org/mail-archive/web/spfbis/current/msg02765.html From spf2@kitterman.com Mon Apr 22 09:06: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 7F3CC21F90A1 for ; Mon, 22 Apr 2013 09:06:53 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0Qmp2aAbTVx for ; Mon, 22 Apr 2013 09:06:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 68F8521F9345 for ; Mon, 22 Apr 2013 09:06:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0298A20E410C; Mon, 22 Apr 2013 12:06:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366646803; bh=4pD+jNTuCTHEmaEWN3F7qX/te5YphJADjE0IwoY2k1Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=maR8knDB7Gu9R4nGQWHcJEAFhGy4uPCPC2MlAW4p3t0MM8fBtx8rU2Ar+MFmyT6kL 6K3XccR7XMV9il4xcttJKPbHSyh3N1FmlUXS6Lut9KkKpTADEELMvXbAACsd/cpSaC nK//obN9wKbzsHrNiwTPyxTIQKrFEy1dQbSHMGGo= 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 D949320E40CD; Mon, 22 Apr 2013 12:06:42 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 22 Apr 2013 12:06:41 -0400 Message-ID: <1890223.gRaPZiil6c@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <51755BD1.5080106@tana.it> References: <20130409062431.GK24624@mx1.yitter.info> <17085583.vi2SDUBAix@scott-latitude-e6320> <51755BD1.5080106@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] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 22 Apr 2013 16:06:53 -0000 On Monday, April 22, 2013 05:48:33 PM Alessandro Vesely wrote: > On Mon 22/Apr/2013 16:04:11 +0200 Scott Kitterman wrote: > > If I take your view that it's better to raise the error (unknown > > mechanism), the perhaps changing the 5.1 language would help. Adding the > > sentence before> > > in, for more context: > >> Mechanisms after "all" will never be tested. Mechanisms listed after > >> "all" > >> MUST be ignored. > > > > Perhaps if we combine those it helps: > >> Mechanisms after "all" MUST not be tested. Mechanisms listed after "all" > >> will be ignored for all purposes except syntax error evaluation. > > > > Does that help? > > Nope, IMHO it's better as is now. That is: > > CURRENT > If there are any syntax errors > EQUIVALENT-FROM-A-PRAGMATIC-POV > If any syntax errors are found > > anywhere in the record, check_host() returns immediately with the > result "permerror", without further interpretation. > > See also http://tools.ietf.org/wg/spfbis/trac/ticket/26 > and http://www.ietf.org/mail-archive/web/spfbis/current/msg02765.html Right, but how can you find a syntax error in something you MUST ignore? That's the conflict that we might want to resolve (and I view resolving a conflict within the document as very different than making novel changes to it). Scott K From vesely@tana.it Mon Apr 22 09:37: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 E0FD821F929E for ; Mon, 22 Apr 2013 09:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96oga9GOOVip for ; Mon, 22 Apr 2013 09:37:58 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0840C21F9283 for ; Mon, 22 Apr 2013 09:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366648677; bh=XPVpQYxTU4gPfKOUBB4tfePxxScxCKmWeZIELvYTPBk=; l=1139; h=Date:From:To:References:In-Reply-To; b=S+8eUDjeNxe3uNpcjhvjLIgnlJOFhww17HF32K4YH5VqZHpH9bPzTIH1vyo6j9Ij/ MMpRNUU6Z1wMzbgxvxnQv+wlZMx5aDY0KHUWVXMXuOFAY7HURcB42qnhm3ZxjiQO77 h/KFiS4T2toRfEEQrc7ddCDq7aCNoD/nOBdEFUf8= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 22 Apr 2013 18:37:56 +0200 id 00000000005DC02B.0000000051756764.00006AF4 Message-ID: <51756764.6030104@tana.it> Date: Mon, 22 Apr 2013 18:37:56 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130409062431.GK24624@mx1.yitter.info> <17085583.vi2SDUBAix@scott-latitude-e6320> <51755BD1.5080106@tana.it> <1890223.gRaPZiil6c@scott-latitude-e6320> In-Reply-To: <1890223.gRaPZiil6c@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 22 Apr 2013 16:37:59 -0000 On Mon 22/Apr/2013 18:06:41 +0200 Scott Kitterman wrote: > On Monday, April 22, 2013 05:48:33 PM Alessandro Vesely wrote: >> On Mon 22/Apr/2013 16:04:11 +0200 Scott Kitterman wrote: >>> >>>> Mechanisms after "all" will never be tested. Mechanisms listed after >>>> "all" >>>> MUST be ignored. >>> >>> Perhaps if we combine those it helps: >>>> Mechanisms after "all" MUST not be tested. Mechanisms listed after "all" >>>> will be ignored for all purposes except syntax error evaluation. >>> >>> Does that help? >> >> Nope, IMHO it's better as is now. That is: >> >> CURRENT >> If there are any syntax errors >> EQUIVALENT-FROM-A-PRAGMATIC-POV >> If any syntax errors are found >> >> anywhere in the record, check_host() returns immediately with the >> result "permerror", without further interpretation. >> >> See also http://tools.ietf.org/wg/spfbis/trac/ticket/26 >> and http://www.ietf.org/mail-archive/web/spfbis/current/msg02765.html > > Right, but how can you find a syntax error in something you MUST ignore? You have to parse it anyway, as it might be a modifier, e.g. "v=spf1 a -all ra=rfc6652" From spf2@kitterman.com Mon Apr 22 10:19: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 CB3DD21E809F for ; Mon, 22 Apr 2013 10:19:00 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkE7-dh6XCxN for ; Mon, 22 Apr 2013 10:19:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 384DE21E809B for ; Mon, 22 Apr 2013 10:19:00 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A2BF620E410C; Mon, 22 Apr 2013 13:18:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366651139; bh=2ap2X6wBDNp6BrmfZRfCxFRDGjltV645U8QaZhc6SmI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=D8HL3R/lv4YwcQXpTGhkRPnjAvkApi+Kk6ZzpohyryDCO1g5JsFm9wSlp+8tgWBnZ 2z/pL44EEf8oh1k2NIufQkpujj212jggQ+p3C5AZIGTFl24pHBZFVJDI4hfc04CQQi PEO+4RCA7hfc9PBacFQ7IG+6r04uiziaH3ocgNz0= 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 858C620E40CD; Mon, 22 Apr 2013 13:18:59 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 22 Apr 2013 13:18:58 -0400 Message-ID: <2528747.v4GPD3HTbD@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <51756764.6030104@tana.it> References: <20130409062431.GK24624@mx1.yitter.info> <1890223.gRaPZiil6c@scott-latitude-e6320> <51756764.6030104@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] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 22 Apr 2013 17:19:00 -0000 On Monday, April 22, 2013 06:37:56 PM Alessandro Vesely wrote: > On Mon 22/Apr/2013 18:06:41 +0200 Scott Kitterman wrote: > > On Monday, April 22, 2013 05:48:33 PM Alessandro Vesely wrote: > >> On Mon 22/Apr/2013 16:04:11 +0200 Scott Kitterman wrote: > >>>> Mechanisms after "all" will never be tested. Mechanisms listed after > >>>> "all" > >>>> MUST be ignored. > >>> > >>> Perhaps if we combine those it helps: > >>>> Mechanisms after "all" MUST not be tested. Mechanisms listed after > >>>> "all" > >>>> will be ignored for all purposes except syntax error evaluation. > >>> > >>> Does that help? > >> > >> Nope, IMHO it's better as is now. That is: > >> > >> CURRENT > >> > >> If there are any syntax errors > >> > >> EQUIVALENT-FROM-A-PRAGMATIC-POV > >> > >> If any syntax errors are found > >> > >> anywhere in the record, check_host() returns immediately with the > >> result "permerror", without further interpretation. > >> > >> See also http://tools.ietf.org/wg/spfbis/trac/ticket/26 > >> and http://www.ietf.org/mail-archive/web/spfbis/current/msg02765.html > > > > Right, but how can you find a syntax error in something you MUST ignore? > > You have to parse it anyway, as it might be a modifier, e.g. > > "v=spf1 a -all ra=rfc6652" That's true, but as soon as I determine it's a mechanism, I ignore it, so the ambiguity still exists. Scott K From superuser@gmail.com Mon Apr 22 11:20: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 C71D421F9254 for ; Mon, 22 Apr 2013 11:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzRAzD62VEaH for ; Mon, 22 Apr 2013 11:20:46 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9739021F90EB for ; Mon, 22 Apr 2013 11:20:45 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id c11so1131470wgh.10 for ; Mon, 22 Apr 2013 11:20:44 -0700 (PDT) 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=W+4ksLtD9s8dU4g2xQjn0mTOtVrTcG0k7SKgXhKC9Do=; b=O36xqVYn00CY6hOkuzSFrb/KMUrVOvssYDYXng4oveSInfUkY/FOhBvu72jKj/n1LE 04UkkrJk6s7p7JdfJmqoJ/Q6wR5BjaC7XidjARvGEdwUpsV5q35722dC1hQc5qEvayEc ObgE6rFExNCOy1JM3J89TjKvIkFnAy4373TUI/XyVn1EKBoC7yAYvM3YoKMeVDWV0m4U baF4xRPlxXQuqV+rjq99sCFJwkhytbfAf33djaged/4S1knXMq3llesNnpU9vPCb095m PuLXePRCCJvCKbHXWdCtPKhm/8Ql834bPesFrYzPZAqGaZp0753dMj4csQ3rKKjzAEz4 XfSw== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr55146169wjb.15.1366654844658; Mon, 22 Apr 2013 11:20:44 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Mon, 22 Apr 2013 11:20:44 -0700 (PDT) In-Reply-To: <5174F5ED.4080303@tana.it> References: <51726641.7070606@tana.it> <5173BEF0.10707@tana.it> <5174F5ED.4080303@tana.it> Date: Mon, 22 Apr 2013 11:20:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=089e010d85748bf02904daf72000 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 22 Apr 2013 18:20:47 -0000 --089e010d85748bf02904daf72000 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 22, 2013 at 1:33 AM, Alessandro Vesely wrote: > >> That's what I want to clarify. SPF does not separate algorithm from > >> policy in the same way that DKIM is separated from ADSP. How can DMARC > >> specify an interface to the SPF layer if SPF does not provide for one? > > > > RFC5451 is a perfectly good interface. It works fine for OpenDMARC, for > > example. > > Hm... RFC 5451 has phrases like 'if, for example, [SPF] returned as > "pass" result'. It is not clear whether that refers to the result of > the check_host() function rather than, considering Section 4.2 "Local > Policy Enforcement", the combined result of check_host() and local > policy up to that point in the processing. > That's a bit off topic here, I think. That draft (or the -bis version of it) is in discussion on apps-discuss if you want to open the topic there. However, I don't think you're comparing the same things. The SPF result is the result of check_host(). What local policy choice is made might be based on that and it might not, but that doesn't change what check_host() returned. As a further example, Section 7.3 of RFC 5518 is formally ambiguous > too, because SPF could produce a "pass" result by validating the > "HELO" identity, and then VBR would be checked against a possibly > spoofed . > RFC5451 includes a mechanism for the consumer to know which mode of SPF was used. Why does VBR itself have to care? --089e010d85748bf02904daf72000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 22, 2013 at 1:33 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
>= > That's what I want to clarify. =A0SPF does not separate algorithm = from
>> policy in the same way that DKIM is separated from ADSP. =A0How ca= n DMARC
>> specify an interface to the SPF layer if SPF does not provide for = one?
>
> RFC5451 is a perfectly good interface. =A0It works fine for OpenDMARC,= for
> example.

Hm... RFC 5451 has phrases like 'if, for example, [SPF] ret= urned as
"pass" result'. =A0It is not clear whether that refers to the= result of
the check_host() function rather than, considering Section 4.2 "Local<= br> Policy Enforcement", the combined result of check_host() and local
policy up to that point in the processing.

<= div>That's a bit off topic here, I think.=A0 That draft (or the -bis ve= rsion of it) is in discussion on apps-discuss if you want to open the topic= there.

However, I don't think you're comparing the same things.= =A0 The SPF result is the result of check_host().=A0 What local policy choi= ce is made might be based on that and it might not, but that doesn't ch= ange what check_host() returned.

As a further example, Section 7.3 of RFC 5518 is formally ambiguous
too, because SPF could produce a "pass" result by validating the<= br> "HELO" identity, and then VBR would be checked against a possibly=
spoofed <reverse-path>.

RFC5451 i= ncludes a mechanism for the consumer to know which mode of SPF was used.=A0= Why does VBR itself have to care?

--089e010d85748bf02904daf72000-- From superuser@gmail.com Mon Apr 22 11:22: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 E2F6921E8044 for ; Mon, 22 Apr 2013 11:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcgbKGrB-XIA for ; Mon, 22 Apr 2013 11:22:19 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C40DB21F90EB for ; Mon, 22 Apr 2013 11:22:18 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so1104981wgh.2 for ; Mon, 22 Apr 2013 11:22:18 -0700 (PDT) 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=xcGlUkkco6UcnUv9MLEDZSbfSRzPRegUcBX2cFiOBZc=; b=Fi0ITAh5xaM8KRcGIGbelBa/UYAGWSQbPB02Dqh05S2RKiMpVsckttFuc6Ys0CVe0g D/ka5SjzFhr2EhgzGh5FZxx0A6yL0B9sjLpAISkrqXIvHFAxaHY/HiRvW2uNuDr/PdPx BTXMB/eRwkwpJ0qNZTh/ocCoxq8absQm9SiHce6QeMtz9McqUqGhMkKR4CeJaauTA6ZI HcLZ15NELWn28hmL4nzXtXOuhPCYfXHCn6lv5C8fXpQo+SfcnJ7Mpgly+zsgeCPd3/vW RS5DZAFhhdSzltmnDOzOwFs+7UpPIvWtF9w+rEittkIBZwSm5Qnlfxhpv2t95huBYVXF vwzA== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr55159614wjb.15.1366654937976; Mon, 22 Apr 2013 11:22:17 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Mon, 22 Apr 2013 11:22:17 -0700 (PDT) In-Reply-To: <6835793.IxuTqepqcv@scott-latitude-e6320> References: <20130409062431.GK24624@mx1.yitter.info> <5174F0F4.2090805@tana.it> <6835793.IxuTqepqcv@scott-latitude-e6320> Date: Mon, 22 Apr 2013 11:22:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e010d85741bd5e404daf72655 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 22 Apr 2013 18:22:22 -0000 --089e010d85741bd5e404daf72655 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 22, 2013 at 7:26 AM, Scott Kitterman wrote: > > The hostname is generally the identity used in the 5321.HELO/.EHLO > > command. In the case of messages with a null 5321.MailFrom, this is > > used as the domain for 5321.MailFrom SPF checks, in addition to being > > used in 5321.HELO/.EHLO based SPF checks. The standard SPF record > > for an individual host that is involved in mail processing is: > > > > At least, for uniformity with the rest of the document, replacement of > > the terms defined in Sections 1.1.3 and 1.1.4 ought to be done. The > > term "hostname" is used once more in the I-D, and I propose a > > replacement it in order to make the text smoother in Section 10.1.2. > > > > Please do what you think is better. Thank you for editing. > > I think hostname is sufficiently standard that it's OK to use there and > appropriate because we're generally referring to the name of and individual > host and not a domain that may have multiple hosts. > > Any other opinions? > I'd like to see something in OLD vs NEW form before I could say for sure, but generally I think I agree. --089e010d85741bd5e404daf72655 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 22, 2013 at 7:26 AM, Scott Kitterman <spf2@k= itterman.com> wrote:
> =A0The hostname is generally the identi= ty used in the 5321.HELO/.EHLO
> =A0command. =A0In the case of messages with a null 5321.MailFrom, this= is
> =A0used as the domain for 5321.MailFrom SPF checks, in addition to bei= ng
> =A0used in 5321.HELO/.EHLO based SPF checks. =A0The standard SPF recor= d
> =A0for an individual host that is involved in mail processing is:
>
> At least, for uniformity with the rest of the document, replacement of=
> the terms defined in Sections 1.1.3 and 1.1.4 ought to be done. =A0The=
> term "hostname" is used once more in the I-D, and I propose = a
> replacement it in order to make the text smoother in Section 10.1.2. >
> Please do what you think is better. =A0Thank you for editing.

I think hostname is sufficiently standard that it's OK to use the= re and
appropriate because we're generally referring to the name of and indivi= dual
host and not a domain that may have multiple hosts.

Any other opinions?

I'd like to see= something in OLD vs NEW form before I could say for sure, but generally I = think I agree.
--089e010d85741bd5e404daf72655-- From vesely@tana.it Tue Apr 23 00:59: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 ECEA921F872E for ; Tue, 23 Apr 2013 00:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ND7vIKtteKY for ; Tue, 23 Apr 2013 00:59:15 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1E69F21F871C for ; Tue, 23 Apr 2013 00:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366703953; bh=0ANlda2K8FnUpao1YxbxFpkTvrpdwK5+7GpyKs9Iz8E=; l=3483; h=Date:From:To:References:In-Reply-To; b=kL846g6gu8DSQk1Cw4ynZGeJUMi8y2eCoWTYNmCPEpqFSyO8YQDu9uqoEJ9rXecNs qVaV7Hb3utdTa/ZDAbAPAQo084Vx7wlrp930lnRLklr0C/qO279lHoiypqGiQ5S6Mx UCPfDYJ04VK00aoeZ/3gwaAOUZ7KyGoXmYlKdqSU= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 23 Apr 2013 09:59:12 +0200 id 00000000005DC039.0000000051763F50.00002908 Message-ID: <51763F51.3020608@tana.it> Date: Tue, 23 Apr 2013 09:59:13 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <51726641.7070606@tana.it> <5173BEF0.10707@tana.it> <5174F5ED.4080303@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 23 Apr 2013 07:59:16 -0000 On Mon 22/Apr/2013 20:20:44 +0200 Murray S. Kucherawy wrote: > On Mon, Apr 22, 2013 at 1:33 AM, Alessandro Vesely wrote: > >>>> SPF does not separate algorithm from policy in the same way >>>> that DKIM is separated from ADSP. How can DMARC specify an >>>> interface to the SPF layer if SPF does not provide for one? >>> >>> RFC5451 is a perfectly good interface. It works fine for >>> OpenDMARC, for example. >> >> Hm... RFC 5451 has phrases like 'if, for example, [SPF] returned >> as "pass" result'. It is not clear whether that refers to the >> result of the check_host() function rather than, considering >> Section 4.2 "Local Policy Enforcement", the combined result of >> check_host() and local policy up to that point in the >> processing. > > That's a bit off topic here, I think. Not if we just aim at establishing whether such /kind/ of statements can be made in a well defined manner. > However, I don't think you're comparing the same things. The SPF result is > the result of check_host(). What local policy choice is made might be > based on that and it might not, but that doesn't change what check_host() > returned. Correct, it is possible to refer to the result of check_host() for a given identity. But none of RFC 5451, VBR and DMARC do so. Why? I think it would result in a too lengthy wording. Perhaps, the wording of Section 2.4 can be improved? Let me try: OLD: A mail receiver can perform a set of SPF checks for each mail message it receives. An SPF check tests the authorization of a client host to emit mail with a given identity. Typically, such checks are done by a receiving MTA, but can be performed elsewhere in the mail processing chain so long as the required information is available and reliable. At least the "MAIL FROM" identity MUST be checked, but it is RECOMMENDED that the "HELO" identity also be checked beforehand. NEW: A mail receiver can perform two SPF checks for each mail message it receives. Each SPF check tests the authorization of a client host for using either the "HELO" or the "MAIL FROM" identity. The possible results of each check are given in Section 2.6. The primary SPF result is the result of of the check associated with the "MAIL FROM" identity; this result MUST be obtained if possible. The secondary SPF result is the result of the check associated with the "HELO" identity; it is RECOMMENDED that this result be obtained beforehand, and it MUST be obtained if it is not possible to get the primary. _Note_ that I'm not proposing that change. I'm asking if a change like that would clear this issue. >> As a further example, Section 7.3 of RFC 5518 is formally ambiguous >> too, because SPF could produce a "pass" result by validating the >> "HELO" identity, and then VBR would be checked against a possibly >> spoofed . > > RFC5451 includes a mechanism for the consumer to know which mode of > SPF was used. Why does VBR itself have to care? VBR does not refer to RFC 5451. It just says: When SPF is the validation mechanism, VBR's md= MUST be the same value as the domain name in the address that is the first parameter to the SMTP MAIL command. A domain is valid for use with VBR only when the SPF process produces a "pass" result. Admittedly, it takes a bit of malice to misunderstand that. However, someone blindly developing the specs could overlook it. From vesely@tana.it Tue Apr 23 00:59: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 BC48821F8771 for ; Tue, 23 Apr 2013 00:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrBNBWHGJDd5 for ; Tue, 23 Apr 2013 00:59:26 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1897E21F871C for ; Tue, 23 Apr 2013 00:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366703965; bh=/XSghUWbRIYcbHeM7eWYY3/WBNU9C1uxDU2ZWRApq+0=; l=1512; h=Date:From:To:References:In-Reply-To; b=a5kRX0r1PLX51G4NTLsQeIRG4f7rjsi75W8YrrTZfa+ubVyNV5AypuQc1RWjqSrZF UvbI34jTD1aNmXOr+lfXT0wk1hoqoNHMWDocet6a/wu7a+tuIPgY3gj0r4rDUx5wDV Bs9BPmC+MD+otcPN26lQyE3je/7FZHYHsUt47e6Q= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 23 Apr 2013 09:59:25 +0200 id 00000000005DC039.0000000051763F5D.00002926 Message-ID: <51763F5D.3080004@tana.it> Date: Tue, 23 Apr 2013 09:59:25 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130409062431.GK24624@mx1.yitter.info> <1890223.gRaPZiil6c@scott-latitude-e6320> <51756764.6030104@tana.it> <2528747.v4GPD3HTbD@scott-latitude-e6320> In-Reply-To: <2528747.v4GPD3HTbD@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 23 Apr 2013 07:59:26 -0000 On Mon 22/Apr/2013 19:18:58 +0200 Scott Kitterman wrote: > On Monday, April 22, 2013 06:37:56 PM Alessandro Vesely wrote: >> On Mon 22/Apr/2013 18:06:41 +0200 Scott Kitterman wrote: >>> On Monday, April 22, 2013 05:48:33 PM Alessandro Vesely wrote: >>>> On Mon 22/Apr/2013 16:04:11 +0200 Scott Kitterman wrote: >>>>>> Mechanisms after "all" will never be tested. Mechanisms listed after >>>>>> "all" MUST be ignored. >>>>> >>>>> Perhaps if we combine those it helps: >>>>>> Mechanisms after "all" MUST not be tested. Mechanisms listed after >>>>>> "all" will be ignored for all purposes except syntax error evaluation. >>>>> >>>>> Does that help? >>>> >>>> Nope, IMHO it's better as is now. That is: >>>> >>>> CURRENT >>>> >>>> If there are any syntax errors >>>> >>>> EQUIVALENT-FROM-A-PRAGMATIC-POV >>>> >>>> If any syntax errors are found >>>> >>>> anywhere in the record, check_host() returns immediately with the >>>> result "permerror", without further interpretation. >>>> >>>> See also http://tools.ietf.org/wg/spfbis/trac/ticket/26 >>>> and http://www.ietf.org/mail-archive/web/spfbis/current/msg02765.html >>> >>> Right, but how can you find a syntax error in something you MUST ignore? >> >> You have to parse it anyway, as it might be a modifier, e.g. >> >> "v=spf1 a -all ra=rfc6652" > > That's true, but as soon as I determine it's a mechanism, I ignore it, so the > ambiguity still exists. If you determine it's a valid something, there's no syntax error. From spf2@kitterman.com Tue Apr 23 02:52: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 2B69821F9658 for ; Tue, 23 Apr 2013 02:52:45 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoqCqKHw3yvD for ; Tue, 23 Apr 2013 02:52:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 349D121F9654 for ; Tue, 23 Apr 2013 02:52:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 597A720E410C; Tue, 23 Apr 2013 05:52:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366710763; bh=QZUFxvQEDwmKSAkbDnKhF38uUbyk+R2WkqRUvyFW5L4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YMg1H3ReEYtI67AWTgs5aQ+X095vgLFUk+HvkReHc3ND4uWV4nO8eSRZBk4qCGjVQ cfRvjb5vTcY1fDsZ6dAgkxrM9VBtSYDH70ej9mXBDU5xkIS89Aea1T/vCUMugEd93+ 1GHv4tkt/VhuNoE3Kacf8I9stPSj8V82OIoC5vx8= 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 3C4B920E40CD; Tue, 23 Apr 2013 05:52:42 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 23 Apr 2013 05:52:42 -0400 Message-ID: <1478526.K9TjTEXC2I@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <51763F51.3020608@tana.it> References: <51726641.7070606@tana.it> <51763F51.3020608@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] New issue: 8.4. Fail: rejection is not described explicitly 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, 23 Apr 2013 09:52:45 -0000 On Tuesday, April 23, 2013 09:59:13 AM Alessandro Vesely wrote: > On Mon 22/Apr/2013 20:20:44 +0200 Murray S. Kucherawy wrote: > > On Mon, Apr 22, 2013 at 1:33 AM, Alessandro Vesely wrote: > >>>> SPF does not separate algorithm from policy in the same way > >>>> that DKIM is separated from ADSP. How can DMARC specify an > >>>> interface to the SPF layer if SPF does not provide for one? > >>> > >>> RFC5451 is a perfectly good interface. It works fine for > >>> OpenDMARC, for example. > >> > >> Hm... RFC 5451 has phrases like 'if, for example, [SPF] returned > >> as "pass" result'. It is not clear whether that refers to the > >> result of the check_host() function rather than, considering > >> Section 4.2 "Local Policy Enforcement", the combined result of > >> check_host() and local policy up to that point in the > >> processing. > > > > That's a bit off topic here, I think. > > Not if we just aim at establishing whether such /kind/ of statements > can be made in a well defined manner. > > > However, I don't think you're comparing the same things. The SPF result > > is > > the result of check_host(). What local policy choice is made might be > > based on that and it might not, but that doesn't change what check_host() > > returned. > > Correct, it is possible to refer to the result of check_host() for a > given identity. But none of RFC 5451, VBR and DMARC do so. Why? I > think it would result in a too lengthy wording. Perhaps, the wording > of Section 2.4 can be improved? Let me try: > > OLD: > A mail receiver can perform a set of SPF checks for each mail message > it receives. An SPF check tests the authorization of a client host > to emit mail with a given identity. Typically, such checks are done > by a receiving MTA, but can be performed elsewhere in the mail > processing chain so long as the required information is available and > reliable. At least the "MAIL FROM" identity MUST be checked, but it > is RECOMMENDED that the "HELO" identity also be checked beforehand. > > NEW: > A mail receiver can perform two SPF checks for each mail message it > receives. Each SPF check tests the authorization of a client host > for using either the "HELO" or the "MAIL FROM" identity. The > possible results of each check are given in Section 2.6. The > primary SPF result is the result of of the check associated with the > "MAIL FROM" identity; this result MUST be obtained if possible. The > secondary SPF result is the result of the check associated with the > "HELO" identity; it is RECOMMENDED that this result be obtained > beforehand, and it MUST be obtained if it is not possible to get the > primary. > > _Note_ that I'm not proposing that change. I'm asking if a change > like that would clear this issue. I don't see where it helps and it loses the point about doing the check in the MTA being better than post-processing, which I think is important, so -1 from me. Scott K > >> As a further example, Section 7.3 of RFC 5518 is formally ambiguous > >> too, because SPF could produce a "pass" result by validating the > >> "HELO" identity, and then VBR would be checked against a possibly > >> spoofed . > > > > RFC5451 includes a mechanism for the consumer to know which mode of > > SPF was used. Why does VBR itself have to care? > > VBR does not refer to RFC 5451. It just says: > > When SPF is the validation mechanism, VBR's md= MUST be the same > value as the domain name in the address that is the > first parameter to the SMTP MAIL command. > > A domain is valid for use with VBR only when the SPF process > produces a "pass" result. > > Admittedly, it takes a bit of malice to misunderstand that. However, > someone blindly developing the specs could overlook it. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Tue Apr 23 02:55: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 E648B21F9609 for ; Tue, 23 Apr 2013 02:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a1UnbbMMD3w for ; Tue, 23 Apr 2013 02:55:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 382BF21F95F3 for ; Tue, 23 Apr 2013 02:55:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B935F20E410C; Tue, 23 Apr 2013 05:55:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366710913; bh=y5ma1pFzbwq613/ueXy2k2U9b5iwevKcLM84dfbGXXA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DPX6NUmwxPeVur/zeR25V4NlRYcYu05QoJm2JoWZXMR9vmeVeIKfiofcYPkTJtcC7 3A8ZLdjxAMPxhsFs+4qnGD2pMLLSt8gAEE3neA7AcPEloVuh2zeCJblfAUZaF2+d27 ZPVCaiK/eVlVUtBJYd17zmiDgMGanPlEwcwfvOls= 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 A3AEC20E40CD; Tue, 23 Apr 2013 05:55:13 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 23 Apr 2013 05:55:12 -0400 Message-ID: <2417280.JQpPtHczhD@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <51763F5D.3080004@tana.it> References: <20130409062431.GK24624@mx1.yitter.info> <2528747.v4GPD3HTbD@scott-latitude-e6320> <51763F5D.3080004@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] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 23 Apr 2013 09:55:15 -0000 On Tuesday, April 23, 2013 09:59:25 AM Alessandro Vesely wrote: > On Mon 22/Apr/2013 19:18:58 +0200 Scott Kitterman wrote: > > On Monday, April 22, 2013 06:37:56 PM Alessandro Vesely wrote: > >> On Mon 22/Apr/2013 18:06:41 +0200 Scott Kitterman wrote: > >>> On Monday, April 22, 2013 05:48:33 PM Alessandro Vesely wrote: > >>>> On Mon 22/Apr/2013 16:04:11 +0200 Scott Kitterman wrote: > >>>>>> Mechanisms after "all" will never be tested. Mechanisms listed after > >>>>>> "all" MUST be ignored. > >>>>> > >>>>> Perhaps if we combine those it helps: > >>>>>> Mechanisms after "all" MUST not be tested. Mechanisms listed after > >>>>>> "all" will be ignored for all purposes except syntax error > >>>>>> evaluation. > >>>>> > >>>>> Does that help? > >>>> > >>>> Nope, IMHO it's better as is now. That is: > >>>> > >>>> CURRENT > >>>> > >>>> If there are any syntax errors > >>>> > >>>> EQUIVALENT-FROM-A-PRAGMATIC-POV > >>>> > >>>> If any syntax errors are found > >>>> > >>>> anywhere in the record, check_host() returns immediately with the > >>>> result "permerror", without further interpretation. > >>>> > >>>> See also http://tools.ietf.org/wg/spfbis/trac/ticket/26 > >>>> and http://www.ietf.org/mail-archive/web/spfbis/current/msg02765.html > >>> > >>> Right, but how can you find a syntax error in something you MUST ignore? > >> > >> You have to parse it anyway, as it might be a modifier, e.g. > >> > >> "v=spf1 a -all ra=rfc6652" > > > > That's true, but as soon as I determine it's a mechanism, I ignore it, so > > the ambiguity still exists. > > If you determine it's a valid something, there's no syntax error. Anyone else? I still think Stuart's point is valid, but I'm not sure the best way to fix it. I also think it would only matter in rare cases, but not so rare we can just say "Meh, corner case." and move on. Scott K From vesely@tana.it Tue Apr 23 09:17: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 C82FA21F96F1 for ; Tue, 23 Apr 2013 09:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQXOMB9DKaSV for ; Tue, 23 Apr 2013 09:17:10 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0774F21F96F4 for ; Tue, 23 Apr 2013 09:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366733829; bh=t4JaKq+vi6pLAHONKtq4s7KXPE+uXQQPnl7XrkIK+tE=; l=1110; h=Date:From:To:References:In-Reply-To; b=N/9IgA62H8SnDoDM7PCuwf/FNz3l+xZ//Gog86jnc7RrTD881soM0kt5mP1uV10/J MAM0duEeoKeBd9QdqrvWpGxigW8/9/3O0TBF+4Pz/rwFe/FU4emfSzjhVPAwmGDz3W bhH3QqCAnD0BbXuHCmAoj1VdEwsqqiy7ss8S+i0Q= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 23 Apr 2013 18:17:08 +0200 id 00000000005DC039.000000005176B404.00003501 Message-ID: <5176B405.3010109@tana.it> Date: Tue, 23 Apr 2013 18:17:09 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <51726641.7070606@tana.it> <51763F51.3020608@tana.it> <1478526.K9TjTEXC2I@scott-latitude-e6320> In-Reply-To: <1478526.K9TjTEXC2I@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 23 Apr 2013 16:17:10 -0000 On Tue 23/Apr/2013 11:52:42 +0200 Scott Kitterman wrote: > On Tuesday, April 23, 2013 09:59:13 AM Alessandro Vesely wrote: >> >> OLD: >> [...] Typically, such checks are done by a receiving MTA, >> but can be performed elsewhere in the mail processing chain >> so long as the required information is available and reliable. >> [...] >> >> _Note_ that I'm not proposing that change. I'm asking if a change >> like that would clear this issue. > > I don't see where it helps and it loses the point about doing the check in the > MTA being better than post-processing, which I think is important, so -1 from > me. Yes, I left it off because it has nothing to do with the rest of the definitions. I agree it is an important point, but it is covered in Section 2.5 "Location of Checks", not Section 2.4. The issue here is that it is not crystal clear what are the SPF results. The introduction of the terms primary/secondary is probably bad. However, where do we say that the following line is wrong: Authentication-Result: spf=pass smtp.mailfrom=postmaster@helo-name.example.com; ? From superuser@gmail.com Tue Apr 23 11:03: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 C2F0121F96EF for ; Tue, 23 Apr 2013 11:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgBrFBMAdp4q for ; Tue, 23 Apr 2013 11:03:39 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 17A7E21F96EE for ; Tue, 23 Apr 2013 11:03:38 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a12so426332wgh.11 for ; Tue, 23 Apr 2013 11:03:38 -0700 (PDT) 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=oTICJ4ydINBLu5LVFqgOjfnjpZUlG5d8RG6TNdwBWKE=; b=u/TscuGiGJSFYRjkuzGu9y03Zw+M0J57O5qEP1qE/wiialem685e5FOcQ6zuKCjixI j1zWMRB5BMrhwgDt9xkJSKmsfImI1ntIYkGT+7kLSI4qZ9kAc4HvX+AVJwN3KSn5yYMH qMv/cqzYCVsQZg9/vcBowFbP4WcGQJBOSSTiqSYqi2aBhEawVZZiXNPlEq5I6aJ3f1B2 A6j3EsjhSgqpKQQhkpgLVyhHimxIGOt4NTgzfD+dGxLqqObNjCrGpY/IEM7gkATGKXzh uIgJBA7gq3723LZ2zaRVdI8W37Hxht5FyAYKwqd5I67NWHizozLcqmqSWVlf9FDG9i4d 7W7A== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr40143021wix.14.1366740218155; Tue, 23 Apr 2013 11:03:38 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Tue, 23 Apr 2013 11:03:37 -0700 (PDT) In-Reply-To: <20130409062431.GK24624@mx1.yitter.info> References: <20130409062431.GK24624@mx1.yitter.info> Date: Tue, 23 Apr 2013 11:03:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=f46d043c062e341ab104db0b01bb Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 23 Apr 2013 18:03:40 -0000 --f46d043c062e341ab104db0b01bb Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 8, 2013 at 11:24 PM, Andrew Sullivan wrote: > Dear colleagues, > > This message initiates a two-week working group last call on > draft-ietf-spfbis-4408bis-14, our only work item. > > The draft has been through 14 revisions, and all open issues in the > tracker are closed. Please review the document and indicate any > comments you have by sending a note to the mailing list. If you have > no comments, it is valuable nevertheless to learn that you have read > the document and support its publication. > > WGLC will close at 2014-04-24 00:00 UTC. > > SM will be the shepherd for this document. > Most of this is nits; except as noted, you could ignore it all and I'd be happy. Nevertheless: Section 1: The last paragraph makes the claim that domain reputation is likely to be more accurate than IP reputation. Is it worthwhile to add a sentence or two explaining why this is true? Section 1.1.2: Suggest replacing the first sentence with "ABNF is defined in [RFC5234], as are the tokens ALPHA, ..." As it is now, "ABNF" is not expanded on first use. Section 1.1.3: Replace the last sentence with: "Note that other terms that might superficially look like the common terms, such as 'reverse-path', are used only as they are specified in their defining documents." Section 2.1: I think someone else already mentioned this, but how does encouraging a second check decrease DNS resource use? Also, suggest replacing the first sentence of the second paragraph with "Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF verifiers MUST be prepared for is identity to be an IP address literal, or simply be malformed." We might even reference the IP address literal ABNF in RFC5321 here. Section 2.2: Add to the first paragraph "...or no HELO check was done." or something of that ilk. Section 2.3: The second paragraph is loaded with negatives "no... neither... nor." Suggest: "ADMDs can publish SPF records that authorize no hosts to use their DNS domain names in HELO or MAIL FROM commands during SMTP sessions." Section 2.4: Isn't the fourth paragraph implicit in any standards specification? That is, do we really need it? Section 2.5: I can't remember if I suggested it previously, but an appendix of RFC5451 gives a pretty thorough treatment of the notion of doing mail authentication checks during the SMTP session versus later. It might be helpful as an informative reference here. Section 2.6.7: Does "permerror" also result when permanent DNS errors occur? Section 3.1: s/alternate/alternative/ Section 4.1: The list of check_host() inputs have been repeated here as in Section 2.4. Do we need both lists? Section 4.4: s/suggests on an algorithm/suggests an algorithm/ Section 4.6.4: I imagine you're going to say that 10 is the limit imposed by most implementations, but shouldn't we say that there should be a finite, perhaps configurable limit, and operational experience has shown that 10 is a reasonable default? Why 20 seconds for the overall run time? Section 4.8: In the third paragraph, a couple of sentences start with "Domain" when you actually mean it as a literal parameter name. I suggest using "domain" (including the quotes) instead. The "Some implementations ..." sentence seems to be malformed. I can't parse it. Section 5.2: s/Check_host/check_host/ (it's not a word that starts sentences and thus needs capitalization) Missing end-quote at the end of bullet 3. The second-last paragraph is weirdly wrapped. Is the XML ok there? Section 5.4: Should the limits stuff in here be removed, and simply reference Section 4.6.4 instead? Section 5.5: The SHOULD NOT in here is puzzling. Does it interfere with interoperability to use it? It was my impression that it's possible to get the same functionality some other way, but not that using "ptr" actually was a bad idea for interoperability reasons. Again with the limits stuff, redundant to Section 4.6.4. Section 5.6: For IPv4, shouldn't the CIDR be 1*2DIGIT? For IPv6, shouldn't the CIDR be 1*3DIGIT? Section 6.2: It just occurred to me that in the earlier sections (2 or 4, in particular), it's clear that check_host() returns one of the enumerated result, but it's never made explicit that it also outputs an explanation string. We might want to mention this earlier than we do now so it's not a surprise later. The SHOULD in the fifth paragraph is questionable: How does it describe an aspect of interoperability? Last paragraph, s/exp=/exp/ 2x. Section 7.1: ABNF rules say literal strings in productions are case-insensitive. That means the macro-letter set actually implicitly includes all of the capital letter equivalents. If we want to constrain it to lowercase only, we need to use hex notation. Section 7.3: "This macro SHOULD NOT be used...." should be in its own paragraph. Also the second sentence should be "See Section xxx for discussion." At the end of this section, there are three paragraphs that all start "Note:". I don't think those tags add anything and suggest they be removed. Section 8: Second paragraph, s/, and where/ and, where/ Section 8.7: Don't the last two sentences say the same thing? Section 9.1: Same point about the case-insensitivity of ABNF here. The "SPF verifiers MUST make sure..." doesn't seem actionable to me. Do we really expect Received-SPF generators to be able to identify and exclude malicious data? Section 10: s/document/protocol/ (or specification) x3 Section 10.1.1: s/required/necessary/ Section 10.1.2: Add "at the cost of a DNS query per receiver" to the end of the first sentence. Section 10.1.3: s/to hostname/to the hostname/, s/of domain/of the domain/ Section 10.2: Missing close parenthesis in the first paragraph. Section 10.3: Errant period in the first sentence. s/Address/address/ Section 11.1: Aren't the first and third bullets describing the same attack? Missing parenthesis at the end of the fourth bullet. Section 11.3: Clobbering the DNS at a receiver could also result in delivery of malicious mail if the receiver is configured to pass on "tempfail" and just add a header field. Is that second bullet true? It appears to claim that IP address spoofing is effectively impossible. Section 11.5: This appears to be an incomplete thought. At a minimum, it doesn't flow nicely into the next subsection. Maybe add a sentence to indicate that SMTP itself doesn't do anything to validate those parameters? Section 11.5.2: Remove commas around the section reference. Appendix A: Any changes made to ABNF above need to be reflected down here. Appendix B.3: Suggest a reference to RFC5782. Appendix C: s/implmentation/implementation/ Appendix G: Fourth paragraph: As I mentioned above, RFC5451 has an appendix that talks at length about why you want to do things like SPF checks at the border rather than inside. Appendix I: The second paragraph claims we're documenting extensions since 4408. Were there any? -MSK --f46d043c062e341ab104db0b01bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 8, 2013 at 11:24 PM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
Dear colleagues,

This message initiates a two-week working group last call on
draft-ietf-spfbis-4408bis-14, our only work item.

The draft has been through 14 revisions, and all open issues in the
tracker are closed. =A0Please review the document and indicate any
comments you have by sending a note to the mailing list. =A0If you have
no comments, it is valuable nevertheless to learn that you have read
the document and support its publication.

WGLC will close at 2014-04-24 00:00 UTC.

SM will be the shepherd for this document.

<= div>Most of this is nits; except as noted, you could ignore it all and I= 9;d be happy.=A0 Nevertheless:

Section 1:

The last= paragraph makes the claim that domain reputation is likely to be more accu= rate than IP reputation.=A0 Is it worthwhile to add a sentence or two expla= ining why this is true?

Section 1.1.2:

Suggest replacing the first= sentence with "ABNF is defined in [RFC5234], as are the tokens ALPHA,= ..."=A0 As it is now, "ABNF" is not expanded on first use.<= br>
Section 1.1.3:

Replace the last sentence w= ith: "Note that other terms that might superficially look like the com= mon terms, such as 'reverse-path', are used only as they are specif= ied in their defining documents."

Section 2.1:

I think someone else already mentioned t= his, but how does encouraging a second check decrease DNS resource use?
=
Also, suggest replacing the first sentence of the second par= agraph with "Note that requirements for the domain presented in the EH= LO or HELO command are not always clear to the sending party, and SPF verif= iers MUST be prepared for is identity to be an IP address literal, or simpl= y be malformed."=A0=A0 We might even reference the IP address literal = ABNF in RFC5321 here.

Section 2.2:

Add to the first paragraph &q= uot;...or no HELO check was done." or something of that ilk.

Section 2.3:

The second paragraph is loaded with negatives = "no... neither... nor."=A0 Suggest: "ADMDs can publish SPF r= ecords that authorize no hosts to use their DNS domain names in HELO or MAI= L FROM commands during SMTP sessions."

Section 2.4:

Isn't the four= th paragraph implicit in any standards specification?=A0 That is, do we rea= lly need it?

Section 2.5:

I can't remember if = I suggested it previously, but an appendix of RFC5451 gives a pretty thorou= gh treatment of the notion of doing mail authentication checks during the S= MTP session versus later.=A0 It might be helpful as an informative referenc= e here.

Section 2.6.7:

Does "permerror" = also result when permanent DNS errors occur?

Section 3.1:=

s/alternate/alternative/

Section 4.1:<= br>
The list of check_host() inputs have been repeated here as i= n Section 2.4.=A0 Do we need both lists?

Section 4.4:
=
s/suggests on an algorithm/suggests an algorithm/

Section 4.6.4:

I imagine you're going to say tha= t 10 is the limit imposed by most implementations, but shouldn't we say= that there should be a finite, perhaps configurable limit, and operational= experience has shown that 10 is a reasonable default?

Why 20 seconds for the overall run time?

S= ection 4.8:

In the third paragraph, a couple of sentences start with= "Domain" when you actually mean it as a literal parameter name.= =A0 I suggest using "domain" (including the quotes) instead.

The "Some implementations ..." sentence seems to b= e malformed.=A0 I can't parse it.

Section 5.2:
s/Check_host/check_host/ (it's not a word that starts sentences and th= us needs capitalization)

Missing end-quote at the end of bullet 3.

= The second-last paragraph is weirdly wrapped.=A0 Is the XML ok there?
Section 5.4:

Should the limits stuff in here be removed= , and simply reference Section 4.6.4 instead?

Section 5.5:

The SHOULD NOT in here is puz= zling.=A0 Does it interfere with interoperability to use it?=A0 It was my i= mpression that it's possible to get the same functionality some other w= ay, but not that using "ptr" actually was a bad idea for interope= rability reasons.

Again with the limits stuff, redundant to Section 4.6.4.
=
Section 5.6:

For IPv4, shouldn't the C= IDR be 1*2DIGIT?=A0 For IPv6, shouldn't the CIDR be 1*3DIGIT?

Section 6.2:

It just occurred to me that in th= e earlier sections (2 or 4, in particular), it's clear that check_host(= ) returns one of the enumerated result, but it's never made explicit th= at it also outputs an explanation string.=A0 We might want to mention this = earlier than we do now so it's not a surprise later.

The SHOULD in the fifth paragraph is questionable: How does = it describe an aspect of interoperability?

Last paragraph= , s/exp=3D/exp/ 2x.

Section 7.1:

ABNF r= ules say literal strings in productions are case-insensitive.=A0 That means= the macro-letter set actually implicitly includes all of the capital lette= r equivalents.=A0 If we want to constrain it to lowercase only, we need to = use hex notation.

Section 7.3:

"This macro SHOULD NOT b= e used...." should be in its own paragraph.=A0 Also the second sentenc= e should be "See Section xxx for discussion."

At the end of this section, there are three paragraphs that all start "= ;Note:".=A0 I don't think those tags add anything and suggest they= be removed.

Section 8:

Second paragrap= h, s/, and where/ and, where/

Section 8.7:

Don't the last two sentences say the= same thing?

Section 9.1:

Same point ab= out the case-insensitivity of ABNF here.

The "SPF ve= rifiers MUST make sure..." doesn't seem actionable to me.=A0 Do we= really expect Received-SPF generators to be able to identify and exclude m= alicious data?

Section 10:

s/document/protocol/ (or speci= fication) x3

Section 10.1.1:

s/required/necessary/=

Section 10.1.2:

Add "at the cost = of a DNS query per receiver" to the end of the first sentence.

Section 10.1.3:

s/to hostname/t= o the hostname/, s/of domain/of the domain/

Section 10.2:=

Missing close parenthesis in the first paragraph.

Section 10.3:

Errant period in the first sentence.
s/Address/address/

Section 11.1:

A= ren't the first and third bullets describing the same attack?

Missing parenthesis at the end of the fourth bullet.

Section 11.3:

Clobbering the DNS at a receiver cou= ld also result in delivery of malicious mail if the receiver is configured = to pass on "tempfail" and just add a header field.

Is that second bullet true?=A0 It appears to claim that IP a= ddress spoofing is effectively impossible.

Section 11.5:<= br>
This appears to be an incomplete thought.=A0 At a minimum= , it doesn't flow nicely into the next subsection.=A0 Maybe add a sente= nce to indicate that SMTP itself doesn't do anything to validate those = parameters?

Section 11.5.2:

Remove commas around the s= ection reference.

Appendix A:

Any changes made to = ABNF above need to be reflected down here.

Appendix B.3:

Suggest a reference to RFC5782.

Appendix C:

s/impl= mentation/implementation/

Appendix G:

Fourth parag= raph: As I mentioned above, RFC5451 has an appendix that talks at length ab= out why you want to do things like SPF checks at the border rather than ins= ide.

Appendix I:

The second paragraph claims we're doc= umenting extensions since 4408.=A0 Were there any?

-MSK
--f46d043c062e341ab104db0b01bb-- From superuser@gmail.com Tue Apr 23 11:21: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 42AC221F9600 for ; Tue, 23 Apr 2013 11:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIMIxjrhhLIq for ; Tue, 23 Apr 2013 11:21:16 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1A38B21F95EE for ; Tue, 23 Apr 2013 11:21:15 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id m6so6470910wiv.1 for ; Tue, 23 Apr 2013 11:21:15 -0700 (PDT) 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=93VdU9FvEUP36t8FQ9swDbQYbZe5oN5saikZulzxMeY=; b=0P+HFAlDds6ABJCxExsNjST7rbRIzg2lAJL9Vp9NrNeKGRSY34ggvVpS9NQS/N/lRI 7PnMZFP+RXKNq7H8fZ4Q1Lq9JLuDm2z+PEcGMusoCVOwqgraS5yvpqSzHgz7bXTlXkOr ZFmQ2XB2Ss7VzNbf3y7V1cIP7JS56Cgz47qzNrPVR4IGMRa2UjPB47XgPpIbM+zGgkwI 9OTGRdbvMotCziT5msV3dYEI8MNHSKOS9ZBofeW3vA292UYCzXCAvROs/4eFTqrgukZX CJg0nn1P32r8X7tvt21u2Bq0L38EzgWR3V7Bwqm7KOgNzKjsfHwSTR7rnfDTB4FQPBg4 SLcA== MIME-Version: 1.0 X-Received: by 10.180.92.229 with SMTP id cp5mr112576wib.20.1366741275249; Tue, 23 Apr 2013 11:21:15 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Tue, 23 Apr 2013 11:21:15 -0700 (PDT) In-Reply-To: <2417280.JQpPtHczhD@scott-latitude-e6320> References: <20130409062431.GK24624@mx1.yitter.info> <2528747.v4GPD3HTbD@scott-latitude-e6320> <51763F5D.3080004@tana.it> <2417280.JQpPtHczhD@scott-latitude-e6320> Date: Tue, 23 Apr 2013 11:21:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043c094e36118a04db0b407d Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 23 Apr 2013 18:21:17 -0000 --f46d043c094e36118a04db0b407d Content-Type: text/plain; charset=ISO-8859-1 "v=spf1 -all foobar" is syntactically invalid. I agree with Stuart that it should result in "permerror" and not "fail". Thus, I think 4.6 has it right as-is. Adding text to say anything after "all" MUST be ignored is a good idea as well, though they have to be syntactically valid anyway. Mentally to me, this is the same as C and C++ in how they define the short-circuit logic of "if" statements. For example, in "if (foo || bar)", if "foo" is true, C and C++ specify that "bar" will not be evaluated. But if the expression at "bar" is actually a syntax error, the whole thing won't compile even if everything up to there is fine. -MSK On Tue, Apr 23, 2013 at 2:55 AM, Scott Kitterman wrote: > On Tuesday, April 23, 2013 09:59:25 AM Alessandro Vesely wrote: > > On Mon 22/Apr/2013 19:18:58 +0200 Scott Kitterman wrote: > > > On Monday, April 22, 2013 06:37:56 PM Alessandro Vesely wrote: > > >> On Mon 22/Apr/2013 18:06:41 +0200 Scott Kitterman wrote: > > >>> On Monday, April 22, 2013 05:48:33 PM Alessandro Vesely wrote: > > >>>> On Mon 22/Apr/2013 16:04:11 +0200 Scott Kitterman wrote: > > >>>>>> Mechanisms after "all" will never be tested. Mechanisms listed > after > > >>>>>> "all" MUST be ignored. > > >>>>> > > >>>>> Perhaps if we combine those it helps: > > >>>>>> Mechanisms after "all" MUST not be tested. Mechanisms listed > after > > >>>>>> "all" will be ignored for all purposes except syntax error > > >>>>>> evaluation. > > >>>>> > > >>>>> Does that help? > > >>>> > > >>>> Nope, IMHO it's better as is now. That is: > > >>>> > > >>>> CURRENT > > >>>> > > >>>> If there are any syntax errors > > >>>> > > >>>> EQUIVALENT-FROM-A-PRAGMATIC-POV > > >>>> > > >>>> If any syntax errors are found > > >>>> > > >>>> anywhere in the record, check_host() returns immediately with the > > >>>> result "permerror", without further interpretation. > > >>>> > > >>>> See also http://tools.ietf.org/wg/spfbis/trac/ticket/26 > > >>>> and > http://www.ietf.org/mail-archive/web/spfbis/current/msg02765.html > > >>> > > >>> Right, but how can you find a syntax error in something you MUST > ignore? > > >> > > >> You have to parse it anyway, as it might be a modifier, e.g. > > >> > > >> "v=spf1 a -all ra=rfc6652" > > > > > > That's true, but as soon as I determine it's a mechanism, I ignore it, > so > > > the ambiguity still exists. > > > > If you determine it's a valid something, there's no syntax error. > > Anyone else? > > I still think Stuart's point is valid, but I'm not sure the best way to > fix it. > I also think it would only matter in rare cases, but not so rare we can > just > say "Meh, corner case." and move on. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d043c094e36118a04db0b407d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
"v=3Dspf1 -all foobar" is syntacticall= y invalid.=A0 I agree with Stuart that it should result in "permerror&= quot; and not "fail".=A0 Thus, I think 4.6 has it right as-is.
Adding text to say anything after "all" MUST be ignored is = a good idea as well, though they have to be syntactically valid anyway.=A0 = Mentally to me, this is the same as C and C++ in how they define the short-= circuit logic of "if" statements.=A0 For example, in "if (fo= o || bar)", if "foo" is true, C and C++ specify that "b= ar" will not be evaluated.=A0 But if the expression at "bar"= is actually a syntax error, the whole thing won't compile even if ever= ything up to there is fine.

-MSK



On Tue, Apr 23, 2013 at 2:5= 5 AM, Scott Kitterman <spf2@kitterman.com> wrote:
On T= uesday, April 23, 2013 09:59:25 AM Alessandro Vesely wrote:
> On Mon 22/Apr/2013 19:18:58 +0200 Scott Kitterman wrote:
> > On Monday, April 22, 2013 06:37:56 PM Alessandro Vesely wrote: > >> On Mon 22/Apr/2013 18:06:41 +0200 Scott Kitterman wrote:
> >>> On Monday, April 22, 2013 05:48:33 PM Alessandro Vesely w= rote:
> >>>> On Mon 22/Apr/2013 16:04:11 +0200 Scott Kitterman wro= te:
> >>>>>> Mechanisms after "all" will never b= e tested. =A0Mechanisms listed after
> >>>>>> "all" MUST be ignored.
> >>>>>
> >>>>> Perhaps if we combine those it helps:
> >>>>>> Mechanisms after "all" MUST not be = tested. =A0Mechanisms listed after
> >>>>>> "all" will be ignored for all purpo= ses except syntax error
> >>>>>> evaluation.
> >>>>>
> >>>>> Does that help?
> >>>>
> >>>> Nope, IMHO it's better as is now. =A0That is:
> >>>>
> >>>> CURRENT
> >>>>
> >>>> =A0 =A0If there are any syntax errors
> >>>>
> >>>> EQUIVALENT-FROM-A-PRAGMATIC-POV
> >>>>
> >>>> =A0 =A0If any syntax errors are found
> >>>>
> >>>> =A0 =A0anywhere in the record, check_host() returns i= mmediately with the
> >>>> =A0 =A0result "permerror", without further = interpretation.
> >>>>
> >>>> See also http://tools.ietf.org/wg/spfbis/trac/ticke= t/26
> >>>> and http://www.ietf.org/mail-arc= hive/web/spfbis/current/msg02765.html
> >>>
> >>> Right, but how can you find a syntax error in something y= ou MUST ignore?
> >>
> >> You have to parse it anyway, as it might be a modifier, e.g.<= br> > >>
> >> =A0 =A0"v=3Dspf1 a -all ra=3Drfc6652"
> >
> > That's true, but as soon as I determine it's a mechanism,= I ignore it, so
> > the ambiguity still exists.
>
> If you determine it's a valid something, there's no syntax err= or.

Anyone else?

I still think Stuart's point is valid, but I'm not sure the best wa= y to fix it.
I also think it would only matter in rare cases, but not so rare we can jus= t
say "Meh, corner case." and move on.

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

--f46d043c094e36118a04db0b407d-- From superuser@gmail.com Tue Apr 23 11:29: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 35BB821F9712 for ; Tue, 23 Apr 2013 11:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkkj9AUHLcAq for ; Tue, 23 Apr 2013 11:29:02 -0700 (PDT) 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 65B6721F9711 for ; Tue, 23 Apr 2013 11:29:02 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id s10so918058wey.35 for ; Tue, 23 Apr 2013 11:29:01 -0700 (PDT) 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=K9PrZWjN5XEVEnpjVhncLPpZ7UP6IIvBu4rVjc92wYg=; b=ISn9L0D0rFZiKaugfnfW2PxJZ0l7Eof6MufGvR1tM2GtUCjJWdSHBPmNJXEg72aGzO AjZ66vbA9WEyrEA8B7uzWmCJk1ju/X+eGsgcdUQhDrX4oLv1G0EwpjoSz8DsaDvTn6AC iIiBZjPyKdgReYBE6oO7gBQyXPOWzRNeBbib1j7PaacBxiaYj/Jsw8/RTZvsyxUGZ10r S0AE2nwM4fDCpE9ksQoW1u7ksxQKZLjjVLWgXgBhxzkiNQrZr5uQNkZQ2OjIs47vgCov RgZtG3XXIpq0rkAjGUE1qAvkSlw2M5S2J6De/ITLp54xwgYX4LErcshkF+u6lxEkSINA jA1A== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr6958238wic.32.1366741741503; Tue, 23 Apr 2013 11:29:01 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Tue, 23 Apr 2013 11:29:01 -0700 (PDT) In-Reply-To: <5176B405.3010109@tana.it> References: <51726641.7070606@tana.it> <51763F51.3020608@tana.it> <1478526.K9TjTEXC2I@scott-latitude-e6320> <5176B405.3010109@tana.it> Date: Tue, 23 Apr 2013 11:29:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a11c34830008ea804db0b5c33 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 23 Apr 2013 18:29:03 -0000 --001a11c34830008ea804db0b5c33 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 23, 2013 at 9:17 AM, Alessandro Vesely wrote: > > I don't see where it helps and it loses the point about doing the check > in the > > MTA being better than post-processing, which I think is important, so -1 > from > > me. > > Yes, I left it off because it has nothing to do with the rest of the > definitions. I agree it is an important point, but it is covered in > Section 2.5 "Location of Checks", not Section 2.4. > > The issue here is that it is not crystal clear what are the SPF > results. The introduction of the terms primary/secondary is probably > bad. However, where do we say that the following line is wrong: > > Authentication-Result: spf=pass > smtp.mailfrom=postmaster@helo-name.example.com; > ? > > I don't even understand what problem we're trying to fix here. I also don't see what's "wrong" with that example. Are you saying you want the consumer of this to be able to tell which mode SPF was in (MAIL FROM vs. HELO) when it reached its conclusion? If so, I would expect that's obvious from the result spec; "smtp.mailfrom" means it evaluated the MAIL FROM command parameter. What would you think a client would want to do with that information? If I'm to take your example as indicating the SPF verifier produced mangled output, then I guess it shouldn't do that. But again, this is a topic for apps-discuss, not spfbis. -MSK --001a11c34830008ea804db0b5c33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 23, 2013 at 9:17 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
> I don't see where it helps and it l= oses the point about doing the check in the
> MTA being better than post-processing, which I think is important, so = -1 from
> me.

Yes, I left it off because it has nothing to do with the rest of the<= br> definitions. =A0I agree it is an important point, but it is covered in
Section 2.5 "Location of Checks", not Section 2.4.

The issue here is that it is not crystal clear what are the SPF
results. =A0The introduction of the terms primary/secondary is probably
bad. =A0However, where do we say that the following line is wrong:

=A0 =A0Authentication-Result: spf=3Dpass
=A0 =A0 =A0 smtp.mailfrom=3Dpostmaster@helo-name.example.com;
?
=A0

I don't even understand what problem we'= ;re trying to fix here.

I also don&= #39;t see what's "wrong" with that example.=A0 Are you saying= you want the consumer of this to be able to tell which mode SPF was in (MA= IL FROM vs. HELO) when it reached its conclusion?=A0 If so, I would expect = that's obvious from the result spec; "smtp.mailfrom" means it= evaluated the MAIL FROM command parameter.

What would you think a client would wa= nt to do with that information?

If = I'm to take your example as indicating the SPF verifier produced mangle= d output, then I guess it shouldn't do that.=A0 But again, this is a to= pic for apps-discuss, not spfbis.

-MSK
--001a11c34830008ea804db0b5c33-- From hsantos@isdg.net Tue Apr 23 14:26: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 9E5D521F93B9 for ; Tue, 23 Apr 2013 14:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.907 X-Spam-Level: X-Spam-Status: No, score=-101.907 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSclEv1EXIr9 for ; Tue, 23 Apr 2013 14:26:28 -0700 (PDT) Received: from catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A924321F937D for ; Tue, 23 Apr 2013 14:26:28 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3745; t=1366752383; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=O5pJDY+ CIOJIEfUzk2+Fsg6WM5g=; b=XV5eF1j/H8uuzEVYH1vnMP6WJ8hy79etk5cuWj7 zxTQ59QlPtZQs4XCQX2za0BPKtJe9MGyMFSLLab9wK2OOpKOirAySavW1sKA8URq kw430j//d9uJY3nX/UQtqKcDGHi4GVQ13XvkUnqqqrBcEnWCrvfU4f9epTHEYtKj EE+Q= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 23 Apr 2013 17:26:22 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1251106679.5955.2972; Tue, 23 Apr 2013 17:26:22 -0400 Message-ID: <5176FC31.3070801@isdg.net> Date: Tue, 23 Apr 2013 17:25:05 -0400 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: "Murray S. Kucherawy" References: <20130409062431.GK24624@mx1.yitter.info> <2528747.v4GPD3HTbD@scott-latitude-e6320> <51763F5D.3080004@tana.it> <2417280.JQpPtHczhD@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 23 Apr 2013 21:26:29 -0000 I believe that would be a FAIL on our left to right natural string parser, -ALL would terminate the processing, never see foobar. I think its correct logic to expect of all. Don't assume processing would be a two-pass parser: Pass One: Check Validity of entire line Pass Two: Process each string word as its extracted from the line. I would think the easiest, fastest is just a one pass parser. Now if the junk is before the EOL (end of line), that is a different situation - permerror. I don't think it would be correct to assume all will read this as a permerror when there is a terminator before foobar/junk. On 4/23/2013 2:21 PM, Murray S. Kucherawy wrote: > "v=spf1 -all foobar" is syntactically invalid. I agree with Stuart that it > should result in "permerror" and not "fail". Thus, I think 4.6 has it > right as-is. > > Adding text to say anything after "all" MUST be ignored is a good idea as > well, though they have to be syntactically valid anyway. Mentally to me, > this is the same as C and C++ in how they define the short-circuit logic of > "if" statements. For example, in "if (foo || bar)", if "foo" is true, C > and C++ specify that "bar" will not be evaluated. But if the expression at > "bar" is actually a syntax error, the whole thing won't compile even if > everything up to there is fine. > > -MSK > > > > On Tue, Apr 23, 2013 at 2:55 AM, Scott Kitterman wrote: > >> On Tuesday, April 23, 2013 09:59:25 AM Alessandro Vesely wrote: >>> On Mon 22/Apr/2013 19:18:58 +0200 Scott Kitterman wrote: >>>> On Monday, April 22, 2013 06:37:56 PM Alessandro Vesely wrote: >>>>> On Mon 22/Apr/2013 18:06:41 +0200 Scott Kitterman wrote: >>>>>> On Monday, April 22, 2013 05:48:33 PM Alessandro Vesely wrote: >>>>>>> On Mon 22/Apr/2013 16:04:11 +0200 Scott Kitterman wrote: >>>>>>>>> Mechanisms after "all" will never be tested. Mechanisms listed >> after >>>>>>>>> "all" MUST be ignored. >>>>>>>> >>>>>>>> Perhaps if we combine those it helps: >>>>>>>>> Mechanisms after "all" MUST not be tested. Mechanisms listed >> after >>>>>>>>> "all" will be ignored for all purposes except syntax error >>>>>>>>> evaluation. >>>>>>>> >>>>>>>> Does that help? >>>>>>> >>>>>>> Nope, IMHO it's better as is now. That is: >>>>>>> >>>>>>> CURRENT >>>>>>> >>>>>>> If there are any syntax errors >>>>>>> >>>>>>> EQUIVALENT-FROM-A-PRAGMATIC-POV >>>>>>> >>>>>>> If any syntax errors are found >>>>>>> >>>>>>> anywhere in the record, check_host() returns immediately with the >>>>>>> result "permerror", without further interpretation. >>>>>>> >>>>>>> See also http://tools.ietf.org/wg/spfbis/trac/ticket/26 >>>>>>> and >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02765.html >>>>>> >>>>>> Right, but how can you find a syntax error in something you MUST >> ignore? >>>>> >>>>> You have to parse it anyway, as it might be a modifier, e.g. >>>>> >>>>> "v=spf1 a -all ra=rfc6652" >>>> >>>> That's true, but as soon as I determine it's a mechanism, I ignore it, >> so >>>> the ambiguity still exists. >>> >>> If you determine it's a valid something, there's no syntax error. >> >> Anyone else? >> >> I still think Stuart's point is valid, but I'm not sure the best way to >> fix it. >> I also think it would only matter in rare cases, but not so rare we can >> just >> say "Meh, corner case." and move on. >> >> 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 sm@elandsys.com Tue Apr 23 14:53: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 CC22121F9696 for ; Tue, 23 Apr 2013 14:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-lUeMFTBWwB for ; Tue, 23 Apr 2013 14:53:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6A621F9699 for ; Tue, 23 Apr 2013 14:53:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.186]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3NLrCiR016588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Apr 2013 14:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366754004; bh=m40m98lIM2P0AhbFQxa0YDotnWVREEuEKBs43XzDvoQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HwXVkuBONaPEt0sU6BEKmRbZJCwouZkDPN743nFKCIRADwGs4qQGIFpq9uRqdlz2t wWYbp3zAsdAP5ErBZAonYrAhoCjrLLAYALAKNZWy4iRAlQ/qekXfseYcxA1s72Zh0m MS9H9Mkz76MUuuo7bhQxLnHqjzLAVWGi/RF8NwYQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366754004; i=@elandsys.com; bh=m40m98lIM2P0AhbFQxa0YDotnWVREEuEKBs43XzDvoQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kav5GGb2P57WchA0C98+Y2+5CSicuo4Y3iM8hfo3Rktwag+qh+4Sr00Z8MyfYXeZ4 Vvm+zFPrGPuDV5bOS5Qa+LI2NIaDAudse88LAjcQjtQ+6XOBPnJA92ywOzTq34HkFW Mu88YkxmbMIVTv403gNNanHBjCRnsLg1MXq/nwtA= Message-Id: <6.2.5.6.2.20130423145013.0c307ec0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 23 Apr 2013 14:52:52 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <5166F870.30700@isdg.net> References: <6.2.5.6.2.20130411030449.0ce5be80@elandnews.com> <5166F870.30700@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Hector Santos Subject: Re: [spfbis] Implementation status of 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, 23 Apr 2013 21:53:30 -0000 Hi Scott, I did not see any response to the comments posted at http://www.ietf.org/mail-archive/web/spfbis/current/msg03350.html and http://www.ietf.org/mail-archive/web/spfbis/current/msg03351.html Could you please review the messages and comment? Thanks, S. Moonesamy (as document shepherd) From sm@elandsys.com Tue Apr 23 15:13: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 E00CF21F95F0; Tue, 23 Apr 2013 15:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKcNAsPj1YfF; Tue, 23 Apr 2013 15:13:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8F621F95EF; Tue, 23 Apr 2013 15:13:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.186]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3NMDitk000685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Apr 2013 15:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366755236; bh=ERwTH1BDUoIwteito5UjHnWnKq8R0tt7UbjWvIG8DME=; h=Date:To:From:Subject:Cc; b=sEO/9UCyByAdGiifx27EhOfcsubOc4NJRGV1111rqaXw3IWbjGThmDI77RM4TlD9R bviA2IKnsUYEDn0BU1pBmTeSfvrUlpjggRunpBcF67KOL2baJWINtOM8ZWEdgzoVIW 95ywRudMOdM3tQLNPPIRUyalFi3u9PJnzSAwTSp8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366755236; i=@elandsys.com; bh=ERwTH1BDUoIwteito5UjHnWnKq8R0tt7UbjWvIG8DME=; h=Date:To:From:Subject:Cc; b=OpokPEwc0KhO3dOnAYeFG+rC4OZLM4iEjidw8rHgUcGXRA4SGwEkCG8L+nqrHNABR Wn8yLv6u/XNG+Lic0YJX7F+vjhLyHQsbVgLO3GmHlZZWjSoxKyBpHWr5YZOHvGXlvZ lpJFyLMdimsndSn1X6qqIjkRMNYzFyYOSmI1D1/Q= Message-Id: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 23 Apr 2013 14:59:58 -0700 To: ipv6@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] IPv4 mapped IPv6 addresses 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, 23 Apr 2013 22:13:58 -0000 Hello, Section 5 of draft-ietf-spfbis-4408bis-14 has the following text: 'When any mechanism fetches host addresses to compare with , when is an IPv4, "A" records are fetched; when 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 [RFC4291]. IPv4 addresses are only listed in an SPF record using the "ip4" mechanism.' Is the text about "IPv4 mapped IPv6 addresses" correct? Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Tue Apr 23 15:14: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 E162B21F9603; Tue, 23 Apr 2013 15:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNGy0belbBkj; Tue, 23 Apr 2013 15:14:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F023121F95FD; Tue, 23 Apr 2013 15:14:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.186]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3NMDitm000685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Apr 2013 15:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366755240; bh=EParNmEN1TE6CBdYRcY2umSS2BtDMmAHhgCq3DxR2Os=; h=Date:To:From:Subject:Cc; b=qyI7+gg2F/GiKWagsQlM9EtOL7kjyGi19En+RBND0RMmpH7r5vvkDedlLDICf4vl+ MlrBXhN2LvlhaMfB0t14hTDjVCzyqVQ3c/te8w1kosh+2kCx8EOYjDDQmVVydgCHVg Fq4fBlGmJ6X0YuWQ/bRispF0pkMlWHE3QUidIJAM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366755240; i=@elandsys.com; bh=EParNmEN1TE6CBdYRcY2umSS2BtDMmAHhgCq3DxR2Os=; h=Date:To:From:Subject:Cc; b=1eX5jA7a7W33hcthr19xfkUiUT6s9o4OsoJz7XkFMsarw6GUNAzxBHcs+yI66lNOr TtxbJvU/pR2lu7ntfJbfCjqDfodBljHrW99Lh66vynnhwS0YNuUmESDr8pxd1vcbE0 aALFFy+aWzNkeSXPxZf/0lxbtBirbB/l6z4lINjY= Message-Id: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 23 Apr 2013 15:03:45 -0700 To: dnsext@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] Obsoleting SPF RRTYPE 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, 23 Apr 2013 22:14:02 -0000 Hello, Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: 'IANA is requested to add an annotation to the SPF RRTYPE saying "(OBSOLETE - use TXT)" in the DNS Parameters registry.' Is the annotation in the DNS Parameters registry correct? Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Tue Apr 23 15:14: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 9EAF121F89B0 for ; Tue, 23 Apr 2013 15:14:05 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsv-EaDHNGpg for ; Tue, 23 Apr 2013 15:14:05 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F8121F854D for ; Tue, 23 Apr 2013 15:14:05 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.186]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3NMDito000685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Apr 2013 15:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366755244; bh=QklZ4kjHlMqiCvl7p46WMOD8Z37B3oyoY0vlFExhPiU=; h=Date:To:From:Subject:Cc; b=mpqWYqGt72o4fJSj0KWYi5sewfhRkpNKhLcmq+rnTzLXhgI/mL+fD0+R6MQl7kyQZ Cnf6lEZCQLAoHvf1wF1u4SePnxXV6IEyIvqECTTWfk963lJMcWBU2AXrBYyUcZofe/ N+iEyMzCjJ8YCmSP4ivqvKx3xHEVMjlHz45ocoGw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366755244; i=@elandsys.com; bh=QklZ4kjHlMqiCvl7p46WMOD8Z37B3oyoY0vlFExhPiU=; h=Date:To:From:Subject:Cc; b=rZjrVyLYysde3ITNBclCDxaGGqjBsc8MSwhgHpEA5giu06iJSdQ89HMm0okp3TncQ URK0stpV6DbJGhN6roV73K1quz71tq4onaFD+9/h4IkDwBQYKMUtX55sD8nXouPfAq kyLzzWuZUf3Jb+MQjGkYpUgMPA1Edp8Rnub3EI5E= Message-Id: <6.2.5.6.2.20130423150556.0c2c07e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 23 Apr 2013 15:13:22 -0700 To: ietf-message-headers@lists.ietf.org, Graham Klyne From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] Received-SPF header 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, 23 Apr 2013 22:14:05 -0000 Hi Graham, As a FYI, draft-ietf-spfbis-4408bis intends to register the "Received-SPF:" header field in the Permanent Message Header Field Registry. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Tue Apr 23 16:30: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 716EE21F9401 for ; Tue, 23 Apr 2013 16:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaDnHal+CLYD for ; Tue, 23 Apr 2013 16:30:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id F330F21F938F for ; Tue, 23 Apr 2013 16:30:56 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.186]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3NNUcME016235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Apr 2013 16:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366759853; bh=u6tk00fbHqy9/O5gphRPL0QkKEM0ZPCHhKY1WMdF2Mk=; h=Date:To:From:Subject; b=DTTwzcpGOehcYmbteMxI9SHfmaYaiU+NQSErZjyPzZ0FeGZjWnK8zJamPKLSn5O/Y 0VcI8SBE3jzsdOPACVcYO9Q+5fOAPV64OK75vqnxqPYK+4Sadq2X7buuOPEhHRpzBB ggadZcVKEEs2W1S+2xf9qPRQgJymwnG9VCRnzUW4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366759853; i=@elandsys.com; bh=u6tk00fbHqy9/O5gphRPL0QkKEM0ZPCHhKY1WMdF2Mk=; h=Date:To:From:Subject; b=bRmHF3v4WZVjwpr5p7pR7W7TIHt+MYMxwoUd36yrFoKC1XSYlebWbh6mFIHEIIa/U QzIfPjvV8d/BeM5VQI8/VlhUN1wdewHHNfpF6Ap4XCJh3yjLZZGynsg7Y3kmgp7HVu +BQ7Y2ooxXsmLFbCduDJGfNGA5xK11ERwEA0uUJA= Message-Id: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 23 Apr 2013 16:08:39 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 23 Apr 2013 23:30:59 -0000 Hello, Here's my review as Document Shepherd. draft-ietf-spfbis-4408bis is nearly ready for publication as a Proposed Standard. I took into consideration the restrictions in the SPFBIS Charter and the controversial working group discussions in making this assessment. In the Abstract: "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." ADMD should be expanded in the above. This was pointed out in a review posted on August 26, 2012 [1]. In Section 2.1: 'It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" identity, but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the .' As a note this "RECOMMENDED" is also in RFC 4408. 'Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF verifiers MUST be prepared for the "HELO" identity to be malformed or an IP address literal.' This RFC 2119 "MUST" is not in RFC 4408. It is a substantive change in my opinion. "This SPF check can only be performed when the "HELO" string is a valid fully qualified domain." What is a valid fully qualified domain? In Section 2.2: 'SPF verifiers MUST check the ""MAIL FROM" identity if a completed "HELO" check has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the .' As a note this RFC 2119 MUST is already in RFC 4408. In Section 2.3: "An SPF-compliant domain MUST have valid SPF records as described in Section 3." As a note the RFC 4408 text is: "An SPF-compliant domain MUST publish a valid SPF record as described in Section 3." The RFC 2119 MUST is redundant. 'If domain owners choose to publish SPF records and want to support receivers making negative authorization determinations, then they MUST publish records that end in "-all", or redirect to other records that do, otherwise, no definitive determination of authorization can be made.' The document uses ADMD while there is "domain owners" in the above. I suggest reviewing that. The RFC 2119 MUST is a substantive change. Why is this a MUST? In Section 2.4: 'At least the "MAIL FROM" identity MUST be checked, but it is RECOMMENDED that the "HELO" identity also be checked beforehand.' There is already a RFC 2119 MUST in Section 2.2. There is also a RFC 2119 RECOMMENDED in Section 2.1. The above text restates existing RFC 2119 requirements or recommendations. 'Without explicit approval of the domain owner, checking other identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results.' How should this explicit approval be sought? This recommendation does not make sense. In Section 2.4: 'When a mail receiver decides to perform an SPF check, it MUST use a correctly-implemented check_host() function (Section 4) evaluated with the correct parameters.' This RFC 2119 requirement states the obvious. It basically says that there is a requirement in draft-ietf-spfbis-4408bis-14 to use a correct implementation of draft-ietf-spfbis-4408bis-14. 'Although invalid, malformed, or non-existent domains cause SPF checks to return "none" because no SPF record can be found, it has long been the policy of many MTAs to reject email from such domains, especially in the case of invalid "MAIL FROM". Rejecting email will prevent one method of circumventing of SPF records.' This text is already in RFC 4408. "Implementations have to take care to correctly extract the from the data given with the SMTP MAIL FROM command as many MTAs will still accept such things as source routes ..." The definition of is: 'the domain portion of the "MAIL FROM" or "HELO" identity.' I am not sure whether it is even a definition. From an implementation perspective the last paragraph of Section 2.4 is unclear. In Section 2.5: "The authorization check SHOULD be performed during the processing of the SMTP transaction that sends the mail." This RFC 2119 SHOULD is already in RFC 4408. 'Performing the authorization other than using the return-path and client address at the time of the MAIL command during the SMTP transaction can cause problems, ..' Shouldn't that be "authorization check"? 'Generating non-delivery notifications to forged identities that have failed the authorization check is a source of backscatter and SHOULD be avoided.' This RFC 2119 SHOULD is not in RFC 4408. The above does not have anything to do with Sender Policy Framework. It was mentioned during WG discussions that "SPF can help the backscatter problem" [2]. This text may have been introduced in response to a review [3]. Is this an enhancement or a clarification? In Section 2.6: "An SPF verifier implements something semantically identical to the function defined there." John Levine commented about this during the WGLC [4]. I am listing this as a reminder for myself. In Section 2.6.1: 'A result of "none" means either (a) no syntactically valid DNS domain name was extracted from the SMTP session that could be used as the one to be authorized, or (b) no TXT records were retrieved from the DNS that appeared to be intended for use by SPF verifiers.' I suggest "DNS TXT records". What is a syntactically valid DNS domain name? The definition of "none" in RFC 4408 is clear (to me). In Section 2.6.2: 'The domain owner has explicitly stated that it is not asserting whether the IP address is authorized. This result MUST be treated exactly like the "none" result; the distinction exists only for informational purposes.' As a note, the RFC 2119 MUST is in RFC 4408. The Introduction Section mentions "ADMDs can authorize hosts to use their domain names". The above uses "domain owner". In Section 2.6.7: 'A "permerror" result means the domain's published records could not be correctly interpreted. This signals an error condition that definitely requires manual intervention to be resolved.' What is "manual intervention" in the above? In Section 3: 'An SPF record is a DNS record that declares which hosts are, and are not, authorized to use a domain name for the "HELO" and "MAIL FROM" identities.' How are hosts which are not authorized to use a domain name listed in a SPF record? "The SPF record is a single string of text." What is a single string of text? It may be easier to state this in terms of record format. 'ADMDs publishing SPF records SHOULD try to keep the number of "include" mechanisms and chained "redirect" modifiers to a minimum.' What is the minimum? Note that this RFC 2119 SHOULD is in RFC 4408. 'ADMDs SHOULD also try to minimize the amount of other DNS information needed to evaluate a record.' This RFC 2119 SHOULD is also in RFC 4408. There are two RFC 2119 SHOULDs in the last paragraph of Section 3. This usage of RFC 2119 key words does not help the SPF "publisher". In my opinion the "SHOULD try" in this context uses the RFC 2119 key word in unorthodox ways. In Section 3.1: 'SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only.' I would ask why "MUST be published ... only". By the way, Section 3 has a reference to Section 4 for record format instead of Section 3.1. Is that correct? In Section 3.2: "A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record." This RFC 2119 MUST NOT was in RFC 4408. Is this to help the SPF "publisher" and if so, how does it help? In Section 3.3: "As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS record can be composed of more than one string." See previous comment about " a single string". "If a published record contains multiple character-strings, then the record MUST be treated as if those strings are concatenated together without adding spaces." This RFC 2119 MUST is also in RFC 4408. I suggest removing the "MUST" in the example. "TXT records containing multiple strings are useful in constructing records that would exceed the 255-byte maximum length of a character- string within a single TXT record." I suggest using "octet" instead of "byte". I'll point the working group to CVE-2008-2469 in case it might wish to consider that issue. In Section 4: "A compliant SPF implementation MUST do something semantically equivalent to this description." It's unusual to see a "do something" RFC 2119 requirement in a specification. Is the SPFBIS WG working on compliance for SPF implementations? "Mail receivers that perform this check MUST correctly evaluate the check_host() function as described here." Where does "mail receivers" fit in the Sender Policy Framework? The "MUST correctly evaluate" is stating the obvious. "Implementations MAY use a different algorithm than the canonical algorithm defined here, so long as the results are the same in all cases." Why is this a RFC 2119 MAY? I am aware that the text is in RFC 4408. In Section 4.1: ' - the domain that provides the sought-after authorization information; initially, the domain portion of the "MAIL FROM" or "HELO" identity.' The above text is different from the text in Section 2.4. In Section 4.3: "If the is malformed (e.g. label longer than 63 characters, zero-length label not at the end, etc.)" That should be "octets". "Properly formed domains are fully qualified email domains as described in [RFC5321] Section 2.3.5." What are "properly qualified email domains"? "Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]." I'm listing the above and leave it to Area Director guidance. Please note that it is a new RFC 2119 requirement. In Section 4.4: "In accordance with how the records are published (see Section 3 above), a DNS query needs to be made for the name, querying for type TXT only." I don't understand the sentence. 'Alternatively, for a server failure (RCODE 2) result, check_host() MAY track failures and treat multiple failures within 24 hours for the same domain as "permerror".' This text is not in RFC 4408. I found a note in Issue #1 [5] and in a message [6]. In Section 4.6.2: "If there are no more mechanisms, the result is specified in Section 4.7." This sentence does not make sense. In Section 4.6.4: "SPF implementations MUST limit the total number of mechanisms and modifiers ("terms") that cause any DNS query to at most 10 during SPF evaluation." This was discussed on the mailing list [7]. "If this number is exceeded during a check, a permerror MUST be returned." I read this as if an implementation-specific limit is reached a permerror is returned. There are two RFC 2119 MUST in the above. That can be reduced to one MUST. I read the first paragraph of Section 4.6.4. I am not sure how the absolute requirement will be interpreted by the reader. 'MTAs or other processors SHOULD impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be "temperror".' There are three RFC 2119 SHOULDs in the above. I suggest rewriting the text to reduce that. 'SPF implementations SHOULD limit "void lookups" to two.' What are void lookups? "In this case, a default of two is RECOMMENDED." Why is "two" recommended? 'Note that records SHOULD always use either a "redirect" modifier or an "all" mechanism to explicitly terminate processing.' Why is there a RFC 2119 key word in a note? In Section 4.8: 'e.g., "foo..example.com") or overlong labels (more than 63 characters).' I suggest octets. in Section 5: 'SPF implementations on IPv6 servers need to handle both "AAAA" and "A" secords, for clients on IPv4 mapped IPv6 addresses [RFC4291].' There is a typo, "records". I'll flag the above for review by people with IPv6 expertise. In Section 5.3: 'a = "a" [ ":" domain-spec ] [ dual-cidr-length ]' "dual-cidr-length" is introduced in this sub-section. I had to search through the draft to find out what it means. In Section 5.4: 'Note regarding implicit MXs: If the has no MX records, check_host() MUST NOT pretend the target is its single MX, and MUST NOT default to an A or AAAA lookup on the directly.' There are two RFC 2119 MUSTs in the above. This is over-usage of RFC 2119 key words. This text was in RFC 4408. This is not a divergence from RFC 5321, it is a contrary to Section 5 of RFC 5321. In Section 5.5: "This mechanism SHOULD NOT be used." I suggest providing a reason for this. "To prevent DoS attacks, more than 10 PTR names MUST NOT be looked up during the evaluation of a "ptr" mechanism (see Section 4.6.4)." The above restates a previous RFC 2119 MUST. "If used, proper PTR records MUST be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked." Those RFC 2119 key words are not in RFC 4408. I don't see how this RFC 2119 change qualifies as a clarification or explanation. "It is, however, still in use and part of the SPF protocol, so compliant check_host() implementations MUST support it." What is a compliant check_host() implementation? In Section 5.6: "ip6-network = " I suggest that the above reference be verified for correctness. In Section 5.7: 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all' I'll flag this for review by DNS folks. In Section 6: 'The modifiers defined in this document ("redirect" and "exp") MAY appear anywhere in the record, but SHOULD appear at the end, after all mechanisms.' This text is in RFC 4408. I would label the RFC 2119 usage as defective. In Section 6.2: "Since the explanation string is intended for an SMTP response and [RFC5321] Section 2.4 says that responses are in [US-ASCII], the explanation string MUST be limited to US-ASCII.' It would be easier to defer to RFC 5321 instead of setting a RFC 2119 requirement in this draft. I note that this requirement was not in RFC 4408. "Software SHOULD make it clear that the explanation string comes from a third party." I could not understand what that means in RFC 2119 terms. The draft uses RFC 2119 key words by example instead of providing an explanation. In Section 7.1: 'The "toplabel" construction is subject to the LDH rule plus additional top-level domain (TLD) restrictions.' Where can I find these restrictions? Please note that I have read the Informational RFC. In Section 7.3: "-exists:%(ir).sbl.spamhaus.example.org" I commented about vendor-neutral previously [8]. The above is a way to get around the objection [9]. I suggest cleaning this up. "so trailing dots SHOULD NOT be published by domain owners" Why is it "domain owners"? "This macro SHOULD NOT be used. See Section 5.5 for the discussion about why not." This comes out as a flippant explanation for the RFC 2119 SHOULD. "This SHOULD be a fully qualified domain name, but if one does not exist (as when the checking is done by a MUA) or if policy restrictions dictate otherwise, the word "unknown" SHOULD be substituted." The RFC 2119 key words are in RFC 2119. I don't know what to say. "When the result of macro expansion is used in a domain name query, if the expanded domain name exceeds 253 characters (the maximum length of a domain name), the left side is truncated to fit, by removing successive domain labels (and their following dots) until the total length does not exceed 253 characters." Where is it specified that the maximum length of a domain name is 253 characters? "Care has to be taken by the sending ADMD so that macro expansion for legitimate email does not exceed the 63-character limit on DNS labels." Where is that 63-character limit specified? It is odd to have RFC 2119 requirements under a "Notes" heading. In Section 8.2: 'A "neutral" result MUST be treated exactly like the "none" result; the distinction exists only for informational purposes.' Why is an existing RFC 2119 restated? In Section 8.5: "The domain owner believes the host is not authorized but is not willing to make a strong policy statement." Why is it domain owner? In Section 9: "An operator could choose to use both to serve different downstream agents. In such cases, care needs to be taken to ensure both fields are conveying the same details, or unexpected results can occur." This has been discussed on the mailing list. I don't think that it encourages interoperability but the working group decided otherwise [10]. In Section 9.1: "The Received-SPF header field is a trace field (see [RFC5322] Section 3.6.7) and SHOULD be prepended to the existing header, above the Received: field that is generated by the SMTP receiver." "prepended to the existing header" does not sound right. "It MUST appear above all other Received-SPF fields in the message." How does this fit into the previous RFC 2119 SHOULD? in Section 10: "This section is not a "how-to" manual, or a "best practices" document, and it is not a comprehensive list of what such entities SHOULD do in light of this document." What is the meaning of the RFC 2119 SHOULD in the above? In Section 10.1.1: There was a comment from Authur Thisell about the table [11] in this sub-section. In Section 10.1.2: "Publishing SPF records for domains that send no mail is a well established best practice." I am not aware of that best practice. I did a few DNS queries: ;; QUESTION SECTION: ;bing.com. IN TXT ;; ANSWER SECTION: bing.com. 3600 IN TXT "v=msv1 t=6097A7EA-53F7-4028-BA76-6869CB284C54" ;; QUESTION SECTION: ;com.com. IN TXT ;; ANSWER SECTION: com.com. 293 IN TXT "google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k" In Section 10.1.3: "SPF functionality is enhanced by administrators ensuring this identity is set correctly and has an appropriate SPF record." How is SPF functionality enhanced? In Section 10.2: "As stated elsewhere in this document, there is no normative requirement for specific handling of a message based on any SPF result." The "as stated elsewhere" is vague. 'The primary considerations are that SPF might return "pass" for mail that is ultimately harmful (e.g., spammers that arrange for SPF to pass using nonsense domain names' What are "nonsense" domain names? In Section 10.3: "The mediator can make the newly-posted message be as similar or as different from the original message as they wish." The sentence seems incomplete, i.e. similar to what. "For the operation of SPF, the essential concern is the email address in the 5321.MailFrom command for the new message." What does this mean? 'Because SPF evaluation is based on the IP Address of the "last" sending SMTP server, the address of the mediator will be used, rather than the address of the SMTP server that sent the message to the mediator.' I'll note that this is a mix of RFC 5321 and RFC 5598. The result is clear or unclear depending on the background of the reader. In Section 11.5: "An SPF compliant receiver gathers information from the SMTP commands it receives and from the published DNS records of the sending domain holder" I suggest explaining the untrusted part. In Section 11.6: "Checking SPF records causes DNS queries to be sent to the domain owner." How are DNS queries sent to domain owners? Section 12: I note that Murray S. Kucherawy has contributed significantly to draft-ietf-spfbis-4408bis. If I am not mistaken it is IETF practice to acknowledge such contributions. I don't recall who sent text at the moment. If you did, please send an (off-list) email to the SPFBIS WG Chairs. In Section 13.1: "The format of this type is identical to the TXT RR [RFC1035]" The format is not identical, i.e. it's a different RR. I suggest keeping the IANA Considerations Section simple, i.e. clearly explain to IANA what action is requested. In Section 13.2: "Per [RFC3864], the "Received-SPF:" header field is added to the IANA Permanent Message Header Field Registry." Note to self: request removal from the provisional message header field registry. The "status:" should be "standard" In Section 13.3: "Their status should not be changed." I suggest "Their status is unchanged". BTW, it should be "SPF Modifier Registry". I suggest following RFC 6652 Section 5.1. An "Updates:" for RFC 6652 may be needed. References: Why is RFC 1123 a normative reference? Why is RFC 3864 a normative reference? Where can I find "Designated Mailers Protocol"? Where can I find "Domain-Authorized SMTP Mail"? ABNF: Did anyone verify the ABNF? In Appendix C: In Section E.1: 'This would cause a lookup on an DNS white list (DNSWL) and cause a result of "fail" only for email not either coming from the domain's mx host(s) (SPF pass) or white listed sources (SPF neutral).' I didn't find any discussion about this on the SPFBIS mailing list. is there an explanation for this change between RFC 4408 and this draft? I note that there are 48 pages in RFC 4408. There are 78 pages in this draft. A significant amount of text has been added in the Appendix (over 20 pages). I doubt that the text has been carefully reviewed. I may be asked for an explanation about all that once the draft leaves this working group. In Appendix I: Appendix I is about "Protocol Status". This draft is intended as a Proposed Standard. From an IETF perspective that is what it will be. Describing it as something different can be misleading. "[RFC4408] was designed to clearly document the protocol defined by earlier draft specifications of SPF as used in existing implementations. This updated specification is intended to clarify identified ambiguities in [RFC4408], resolve techincal issues identified in post-RFC 4408 deplyment experience, and document widely deployed extensions to SPF that have been developed since [RFC4408] was published." Extensions to the SPF protocol are clearly mentioned in the charter as being out of scope. The "document widely deployed extensions" is problematic. "This document updates and replaces RFC 4408 that was part of a group of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the community observe the success or failure of the two approaches documented in these RFCs during the two years following publication, in order that a community consensus could be reached in the future." Why is this needed? The SPFBIS WG produced RFC 6686 to resolve the experiment. "SPF is widely deployed by large and small email providers alike. There are multiple, interoperable implementations." Someone might point out that this is marketing instead of text relevant to a protocol. I'll mention that one or more significant issues (e.g. Issue #9) was identified during the WG discussions. Issue #9 was not listed as the errata. I suggest removing the section as it will be less text and there is already two informative references to help the reader find background information. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00928.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg01810.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg03378.html 5. http://trac.tools.ietf.org/wg/spfbis/trac/ticket/1 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00630.html 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg00199.html 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02279.html 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02308.html 10. http://www.ietf.org/mail-archive/web/spfbis/current/msg02526.html 11. http://www.ietf.org/mail-archive/web/spfbis/current/msg02763.html From johnl@iecc.com Tue Apr 23 17:26: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 06CA521F9418 for ; Tue, 23 Apr 2013 17:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qKm26m83LrM for ; Tue, 23 Apr 2013 17:26:53 -0700 (PDT) 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 28BCF21F93DA for ; Tue, 23 Apr 2013 17:26:52 -0700 (PDT) Received: (qmail 89526 invoked from network); 24 Apr 2013 00:26:52 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Apr 2013 00:26:52 -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; s=517726cc.xn--hew.k1304; i=johnl@user.iecc.com; bh=EQEThnH91xKW+vwfzXY+EFo0VfVDXAjoWQop5U9UIOw=; b=ThlmpWd9pvADbKH+6MZeqKFsbDkb73Wg4GHX85O6URVtC5mPFeomqIdm8ZoxCkmGEP+7hcl5x53WLZKW/Ka8HwhQSXx1nuhKLa89OYUqAxEOqe/U3XhvjcODoKmZBN4EN3Dah4MzyMUevRQ8QyevkvBfZF4yIE57+FL1JZ+Il5g= 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; s=517726cc.xn--hew.k1304; olt=johnl@user.iecc.com; bh=EQEThnH91xKW+vwfzXY+EFo0VfVDXAjoWQop5U9UIOw=; b=CfCnJS+9Qk6LjzMEv9OXUXxe8WAPDGMwjo5CzFbQon1Ujc7dNv1fu4OWUygrfvv7QZIr61Ap+zyZfZg+L6+C4jPiFEMn/z72no9vBpr56BVU80B65US1H58t3AFMCznT2c3yF8OU5m6Re/RJTGTCG8ZaqCD+k9xsyzIJ3e7Y8ew= Date: 24 Apr 2013 00:26:29 -0000 Message-ID: <20130424002629.13505.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] WGLC: draft-ietf-spfbis-4408bis-14 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, 24 Apr 2013 00:26:54 -0000 >Section 4.6.4: > >I imagine you're going to say that 10 is the limit imposed by most >implementations, but shouldn't we say that there should be a finite, >perhaps configurable limit, and operational experience has shown that 10 is >a reasonable default? If everyone doesn't have the same limit, an SPF check might fail at a site with a lower limit and the identical check would succeed at one with a higher limit. The limit has been 10 for a long time and I don't see any reason to change it now. >The "Some implementations ..." sentence seems to be malformed. I can't >parse it. That whole paragraph could be replaced by "the result of evaluating check_host() with a syntactically invalid domain is undefined." >Section 5.6: > >For IPv4, shouldn't the CIDR be 1*2DIGIT? For IPv6, shouldn't the CIDR be >1*3DIGIT? What's wrong with 10.1.0.0/016 ? >Section 11.3: >Is that second bullet true? It appears to claim that IP address spoofing >is effectively impossible. Ever since TCP stacks started randomizing sequence numbers in the mid-1990s, spoofing a TCP session has been implausibly hard. Spoofing UDP is all too easy, but that's not what we're talking about here. R's, John From superuser@gmail.com Tue Apr 23 21:10: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 146D221F93AB for ; Tue, 23 Apr 2013 21:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jgPaPZvoXyQ for ; Tue, 23 Apr 2013 21:10:17 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7EE21F8738 for ; Tue, 23 Apr 2013 21:10:16 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id l13so6906175wie.16 for ; Tue, 23 Apr 2013 21:10:15 -0700 (PDT) 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=PB0WcXksFd41zluTOyipydPZpkphsnhwmTka6hxKGyo=; b=jeYhMqzrzJp2//gd4wyVQatpRc7qF20NjevKIguXDzXOjhJheqCNTthIu+cnxAzQVk xzVYX9G7sURI/p+L+xqxWld2axsAT3dhtOhmzke4kX5yE5sMBDfGXDBAlVqQjvZ++x16 VW2xZZxgXoAP7agoEkw2hWf6HORSMumDjM62khSdvLD+yy1fS/mSdwVq1mtaCDp15kAt ZUwSTDMsEfvuH6dw22fFjno84KNTW4I77R3SVWxykByYanYJ+G0AbtEQhGdsRJ9wTK3a KPHZYqXx/4mfIX3Py2R96mxJW631B8j9fpR0LV9hSOdt28G+/Hicpwx8uifVD8rU/np1 ZV1A== MIME-Version: 1.0 X-Received: by 10.180.92.229 with SMTP id cp5mr2079044wib.20.1366776615340; Tue, 23 Apr 2013 21:10:15 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Tue, 23 Apr 2013 21:10:15 -0700 (PDT) In-Reply-To: <20130424002629.13505.qmail@joyce.lan> References: <20130424002629.13505.qmail@joyce.lan> Date: Tue, 23 Apr 2013 21:10:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=f46d043c094ea5140c04db137a16 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 24 Apr 2013 04:10:18 -0000 --f46d043c094ea5140c04db137a16 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 23, 2013 at 5:26 PM, John Levine wrote: > >I imagine you're going to say that 10 is the limit imposed by most > >implementations, but shouldn't we say that there should be a finite, > >perhaps configurable limit, and operational experience has shown that 10 > is > >a reasonable default? > > If everyone doesn't have the same limit, an SPF check might fail at a > site with a lower limit and the identical check would succeed at one > with a higher limit. The limit has been 10 for a long time and I > don't see any reason to change it now. > I'd rather we say something like this. Otherwise some neophyte will read this and think "What's so special about 10?" -MSK --f46d043c094ea5140c04db137a16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 23, 2013 at 5:26 PM, John Levine <johnl@taugh.c= om> wrote:
>I imagine you're going to say that 10 is the limi= t imposed by most
>implementations, but shouldn't we say that there should be a finite= ,
>perhaps configurable limit, and operational experience has shown that 1= 0 is
>a reasonable default?

If everyone doesn't have the same limit, an SPF check might fail = at a
site with a lower limit and the identical check would succeed at one
with a higher limit. =A0The limit has been 10 for a long time and I
don't see any reason to change it now.

<= div>I'd rather we say something like this.=A0 Otherwise some neophyte w= ill read this and think "What's so special about 10?"
=A0<= br>
-MSK
--f46d043c094ea5140c04db137a16-- From spf2@kitterman.com Tue Apr 23 21:33: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 0FF6821F93AB for ; Tue, 23 Apr 2013 21:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMek55ffRzwq for ; Tue, 23 Apr 2013 21:33:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5794E21F9380 for ; Tue, 23 Apr 2013 21:33:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8B4DA20E40FE; Wed, 24 Apr 2013 00:33:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366778036; bh=lZaKwbtxiESceDDpASipKP4K/uB5ANmp1IpfTG1r4oM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Wjb6LQWQDbViB1zCOtmlxMbYckLf96FN0xt08BoLtMc+3CQHKABtmG5abnwN688De gbwnHvTs12XtD6o5QOnq+sRuJD5HUB8F9nrX6r/7lp2SVx8GjXYi11UqRN+8/fRyL0 h8gZJoPdgke3T+R2GuCLlTw0HKv7LH2MrhF21bpg= 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 6EA4620E4085; Wed, 24 Apr 2013 00:33:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 24 Apr 2013 00:33:51 -0400 Message-ID: <1460222.e6VXMsC181@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <20130424002629.13505.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] WGLC: draft-ietf-spfbis-4408bis-14 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, 24 Apr 2013 04:33:58 -0000 On Tuesday, April 23, 2013 09:10:15 PM Murray S. Kucherawy wrote: > On Tue, Apr 23, 2013 at 5:26 PM, John Levine wrote: > > >I imagine you're going to say that 10 is the limit imposed by most > > >implementations, but shouldn't we say that there should be a finite, > > >perhaps configurable limit, and operational experience has shown that 10 > > > > is > > > > >a reasonable default? > > > > If everyone doesn't have the same limit, an SPF check might fail at a > > site with a lower limit and the identical check would succeed at one > > with a higher limit. The limit has been 10 for a long time and I > > don't see any reason to change it now. > > I'd rather we say something like this. Otherwise some neophyte will read > this and think "What's so special about 10?" OK. Would you please propose text? Scott K From superuser@gmail.com Tue Apr 23 22:21: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 355B221F93B3 for ; Tue, 23 Apr 2013 22:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D44Lqn-6gGay for ; Tue, 23 Apr 2013 22:21:23 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id A88E121F944C for ; Tue, 23 Apr 2013 22:21:22 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so1647436wiv.15 for ; Tue, 23 Apr 2013 22:21:21 -0700 (PDT) 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=tjXraM72S6bWHQcRHwo43CaU0zmYJvIiK3lymzR0pFU=; b=kUf7CPBMiLge2OtUZrDeB87c3E6cFFkqWoSAIzfEWQDkHdHptkqwhSQM8rkULF0UPW TQ9QMbEiB49V7UL8IdZCHaU/T6ggRmQ7v80NLE6h4zD15sFANu5kXlbakFD7BQpiTR8N sWcelQgttgeihS/CK5p17QGRFZP1MlVSCpAElhJ6F8hplVHa3YugxrvKr3Qw4di9vDQV XnBgyhyxlHXgKGLpjBNcbRzGfPRqK9lqzSMxqpWxW7kTVq9z7gcaBqNQBcM4I6gdxYdw SYBOJF3SUw+esK23PK8F33OHhLonGL+0KQJfgZnVUNfz8y3G6Bsvv7Rjwr3+25yMsCrm 40OQ== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr42452534wix.14.1366780881793; Tue, 23 Apr 2013 22:21:21 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Tue, 23 Apr 2013 22:21:21 -0700 (PDT) In-Reply-To: <1460222.e6VXMsC181@scott-latitude-e6320> References: <20130424002629.13505.qmail@joyce.lan> <1460222.e6VXMsC181@scott-latitude-e6320> Date: Tue, 23 Apr 2013 22:21:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043c062ef1fb3704db1478d0 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 24 Apr 2013 05:21:26 -0000 --f46d043c062ef1fb3704db1478d0 Content-Type: text/plain; charset=ISO-8859-1 Sure, add to the end of 4.6.4: The number 10 used as the limit above was chosen during early implementations and has shown to produce reasonable results both in terms of giving complete answers when used properly and preventing abuse otherwise. The choice was largely arbitrary, but it is now used as the mandatory limit so that SPF results are consistent across implementations. (I'm guessing that history is correct; feel free to make corrections as needed.) On Tue, Apr 23, 2013 at 9:33 PM, Scott Kitterman wrote: > On Tuesday, April 23, 2013 09:10:15 PM Murray S. Kucherawy wrote: > > On Tue, Apr 23, 2013 at 5:26 PM, John Levine wrote: > > > >I imagine you're going to say that 10 is the limit imposed by most > > > >implementations, but shouldn't we say that there should be a finite, > > > >perhaps configurable limit, and operational experience has shown that > 10 > > > > > > is > > > > > > >a reasonable default? > > > > > > If everyone doesn't have the same limit, an SPF check might fail at a > > > site with a lower limit and the identical check would succeed at one > > > with a higher limit. The limit has been 10 for a long time and I > > > don't see any reason to change it now. > > > > I'd rather we say something like this. Otherwise some neophyte will read > > this and think "What's so special about 10?" > > OK. Would you please propose text? > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d043c062ef1fb3704db1478d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sure, add to the end of 4.6.4:

The number 10 u= sed as the limit above was chosen during early implementations and has show= n to produce reasonable results both in terms of giving complete answers wh= en used properly and preventing abuse otherwise.=A0 The choice was largely = arbitrary, but it is now used as the mandatory limit so that SPF results ar= e consistent across implementations.

(I'm guessing that history is correct; feel free to make corr= ections as needed.)


On Tue, Apr 23, 2013 at 9:33 PM, Scott Kitterman <spf2@k= itterman.com> wrote:
On T= uesday, April 23, 2013 09:10:15 PM Murray S. Kucherawy wrote:
> On Tue, Apr 23, 2013 at 5:26 PM, John Levine <johnl@taugh.com> wrote:
> > >I imagine you're going to say that 10 is the limit impose= d by most
> > >implementations, but shouldn't we say that there should b= e a finite,
> > >perhaps configurable limit, and operational experience has sh= own that 10
> >
> > is
> >
> > >a reasonable default?
> >
> > If everyone doesn't have the same limit, an SPF check might f= ail at a
> > site with a lower limit and the identical check would succeed at = one
> > with a higher limit. =A0The limit has been 10 for a long time and= I
> > don't see any reason to change it now.
>
> I'd rather we say something like this. =A0Otherwise some neophyte = will read
> this and think "What's so special about 10?"

OK. =A0Would you please propose text?

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

--f46d043c062ef1fb3704db1478d0-- From vesely@tana.it Wed Apr 24 01:25: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 D1CDF21F8CEC for ; Wed, 24 Apr 2013 01:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.381 X-Spam-Level: X-Spam-Status: No, score=-4.381 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B+lzZfbriyN for ; Wed, 24 Apr 2013 01:25:00 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D0CDD21F8D00 for ; Wed, 24 Apr 2013 01:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366791896; bh=13oLbLZ2aTyWBQGUgp8ukh1OI/1FTsPTqjMpxPO6+II=; l=2036; h=Date:From:To:References:In-Reply-To; b=Ddji8g94YH6/NOly3G6mj0Da36GnsI/KmhA4yR/jLhUJVEQm6yh1O+rbpYMq1r4dH kxnruQLoeV0/6aX3JFJgHfiyM28DTpN1sAx/rFIaSN6cyqpK+DBMxMKP4qNVkxtYxC BplGyGjK7q1yfcswFBFjTTB4R9Ip+NCqWxLp3o/8= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 24 Apr 2013 10:24:56 +0200 id 00000000005DC039.00000000517796D8.00003B1E Message-ID: <517796D9.9050303@tana.it> Date: Wed, 24 Apr 2013 10:24:57 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <51726641.7070606@tana.it> <51763F51.3020608@tana.it> <1478526.K9TjTEXC2I@scott-latitude-e6320> <5176B405.3010109@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 24 Apr 2013 08:25:00 -0000 On Tue 23/Apr/2013 20:29:01 +0200 Murray S. Kucherawy wrote: > On Tue, Apr 23, 2013 at 9:17 AM, Alessandro Vesely wrote: > >> The issue here is that it is not crystal clear what are the SPF >> results. The introduction of the terms primary/secondary is probably >> bad. However, where do we say that the following line is wrong: >> >> Authentication-Result: spf=pass >> smtp.mailfrom=postmaster@helo-name.example.com; >> ? > > I don't even understand what problem we're trying to fix here. That the spec doesn't lend itself well to being used as a building block for other specs willing to refer to SPF results. > I also don't see what's "wrong" with that example. Sorry, I should have said I assumed the client did something like: HELO helo-name.example.com MAIL FROM:<> > Are you saying you want the consumer of this to be able to tell > which mode SPF was in (MAIL FROM vs. HELO) when it reached its > conclusion? Yes. > If so, I would expect that's obvious from the result spec; > "smtp.mailfrom" means it evaluated the MAIL FROM command > parameter. Right, but since that parameter was null, the verifier synthesized a mailbox composed of the local-part "postmaster" and the "HELO" identity, as per Section 2.2. > What would you think a client would want to do with that information? VBR, for example, is interested in authenticating a mail domain rather than a host name, because of the granularity it standardizes. > If I'm to take your example as indicating the SPF verifier produced > mangled output, then I guess it shouldn't do that. But again, this > is a topic for apps-discuss, not spfbis. Perhaps, 5451bis could word something clever in terms of check_host() so that other specs can refer to it instead of SPF. However, if a message is going to be rejected, the border MTA SHOULD issue an [SMTP] rejection response to the message rather than adding this header field with the failure result. Which brings us back to this thread's subject. From simon.perreault@viagenie.ca Wed Apr 24 01:31: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 7032621F8F0F; Wed, 24 Apr 2013 01:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHf5dI+-F79g; Wed, 24 Apr 2013 01:31:06 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id F033221F8E9A; Wed, 24 Apr 2013 01:31:05 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2346E40432; Wed, 24 Apr 2013 04:31:05 -0400 (EDT) Message-ID: <51779847.6060608@viagenie.ca> Date: Wed, 24 Apr 2013 10:31:03 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> In-Reply-To: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 24 Apr 2013 02:57:06 -0700 Cc: spfbis@ietf.org, ipv6@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 08:31:06 -0000 Le 2013-04-23 23:59, S Moonesamy a écrit : > Section 5 of draft-ietf-spfbis-4408bis-14 has the following text: > > 'When any mechanism fetches host addresses to compare with , when > is an IPv4, "A" records are fetched; when 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 [RFC4291]. IPv4 addresses are only > listed in an SPF record using the "ip4" mechanism.' > > Is the text about "IPv4 mapped IPv6 addresses" correct? I, for one, have no idea what a "client on IPv4-mapped IPv6 address" might be. So the text doesn't look correct to me. If you describe in a little bit more detail what the intent is, we can help you reformulate. Simon From sm@elandsys.com Wed Apr 24 02:58: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 D45AF21F8EB2; Wed, 24 Apr 2013 02:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pgkWqHHkwh5; Wed, 24 Apr 2013 02:58:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 344AF21F8EB1; Wed, 24 Apr 2013 02:58:29 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.221]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3O9wFmw024324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Apr 2013 02:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366797508; bh=DK/yUX072NwD7REUE6MXD09gEWPLq7M8DyAD4lPIV54=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VCucx4icCnHACFqIjLrFKFdJzA7ym8STWrUnrhzcA/Ee1uh3Y50JT2gTK5Fvh3jRW d1LUCpjTkQSewSWD4WnY0rWH+pSV6Qo4i0BRRWlCdKfLLMzSBUir5LOl5M/PajTwDV c2s8k5XYC/Od/AbIsnQvbQg7uNOH9p5d3E0QL6bQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366797508; i=@elandsys.com; bh=DK/yUX072NwD7REUE6MXD09gEWPLq7M8DyAD4lPIV54=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=t7oSpLtuCw5bKlrYaBiYY6wI9B+qdUupWPkEHFj+v2m6iUwcxE0tRiLvnX9R5EJtM oBDhQesVd12wHVwDEr/7yLE+noYY6bv6ofU9ihl8rZhf+0CtsDKmLH75pJYj1AqSwa WbP+xnZUmaZBBCjT27jh4rZKNVNjZmhOJIaEx3bw= Message-Id: <6.2.5.6.2.20130424020229.0bef18a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 02:54:03 -0700 To: Simon Perreault From: S Moonesamy In-Reply-To: <51779847.6060608@viagenie.ca> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <51779847.6060608@viagenie.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, ipv6@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 09:58:29 -0000 Hi Simon, At 01:31 24-04-2013, Simon Perreault wrote: >I, for one, have no idea what a "client on IPv4-mapped IPv6 address" >might be. So the text doesn't look correct to me. > >If you describe in a little bit more detail what the intent is, we >can help you reformulate. Thanks for feedback. For context the text is in the ninth paragraph of Section 5 of draft-ietf-spfbis-4408bis-14. I'll rewrite the text as follows: SPF implementations on IPv6 servers need to handle both "AAAA" and "A" DNS records, for SMTP clients on IPv4 mapped IPv6 addresses [RFC4291]. The intent seems to be about an IPv4 host (client) connecting to an IPv6 host (server). The IPv6 host matches the source IP address of the TCP connection against a list which may contain IPv4 mapped IPv6 addresses. Does that make sense or it is easier to forget about "IPv4 mapped IPv6 addresses"? Regards, S. Moonesamy (as document shepherd) From simon.perreault@viagenie.ca Wed Apr 24 04:33: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 2DF7521F8EF2; Wed, 24 Apr 2013 04:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCi4F3UE9JBq; Wed, 24 Apr 2013 04:33:24 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9B721F8EEB; Wed, 24 Apr 2013 04:33:24 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A67D040432; Wed, 24 Apr 2013 07:33:23 -0400 (EDT) Message-ID: <5177C301.1090605@viagenie.ca> Date: Wed, 24 Apr 2013 13:33:21 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <51779847.6060608@viagenie.ca> <6.2.5.6.2.20130424020229.0bef18a8@elandnews.com> In-Reply-To: <6.2.5.6.2.20130424020229.0bef18a8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 24 Apr 2013 05:50:36 -0700 Cc: spfbis@ietf.org, ipv6@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 11:33:25 -0000 Le 2013-04-24 11:54, S Moonesamy a écrit : > Hi Simon, > At 01:31 24-04-2013, Simon Perreault wrote: >> I, for one, have no idea what a "client on IPv4-mapped IPv6 address" >> might be. So the text doesn't look correct to me. >> >> If you describe in a little bit more detail what the intent is, we can >> help you reformulate. > > Thanks for feedback. > > For context the text is in the ninth paragraph of Section 5 of > draft-ietf-spfbis-4408bis-14. I'll rewrite the text as follows: > > SPF implementations on IPv6 servers need to handle both "AAAA" and > "A" DNS records, for SMTP clients on IPv4 mapped IPv6 addresses > [RFC4291]. I'm sorry, I've read section 5 and that still doesn't make sense to me. > The intent seems to be about an IPv4 host (client) connecting to an IPv6 > host (server). How does that work? Is there a NAT46 in between? > The IPv6 host matches the source IP address of the TCP > connection against a list which may contain IPv4 mapped IPv6 addresses. > Does that make sense or it is easier to forget about "IPv4 mapped IPv6 > addresses"? As IPv4-mapped IPv6 addresses do not go on the wire, this still doesn't make sense to me! IPv4-mapped IPv6 addresses have two uses: 1) They are used internally on a single host, between a userland app and the kernel, to represent IPv4 addresses using an IPv6-only socket. The address never leaves the host. It can be considered an implementation detail. They are most useful when porting an IPv4-only app to dual-stack. Newer applications should never use IPv4-mapped IPv6 addresses, and it is good practice to disable them explicitly. 2) In various signalling protocols, to represent an IPv4 address in an IPv6 address field. This is protocol-specific. It is used only for signalling, never as actual addresses in IPv6 packet headers. At this point, I'm guessing that it would be better to forget about IPv4-mapped IPv6 addresses, although I still don't understand exactly what your intent is. Simon From sm@elandsys.com Wed Apr 24 07:12: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 39A6221F931E; Wed, 24 Apr 2013 07:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93y8yvLKv82E; Wed, 24 Apr 2013 07:12:17 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DF021F930C; Wed, 24 Apr 2013 07:12:17 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.221]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3OEC4EM006081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Apr 2013 07:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366812736; bh=kul8m3yeaAYVHbM+Uil0SXukBuZczkd772D54CPddUc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1huPtUqBmCU4Ika10ML9IcO8I7E4yqZN+zn00LQeb3zROnsKgEa7+QDpiWgXE8VUg dz8qLHz676ruH5sdbfGgCCf7u0eHPjhIMeUIjM2Lpdoave/MO++Ta3X2VITK47zJz6 1PhCfCa5mh9AactC+77nQFWjcqWc1yQccCZIEzKc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366812736; i=@elandsys.com; bh=kul8m3yeaAYVHbM+Uil0SXukBuZczkd772D54CPddUc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jWRVJWpiB8tsB5v0o8lpFyz9lv1aCwGZHEzhgbipeuinI1EsxxwUxyFZPq1SJkjER vcQwW6P0unToe1yw+J4+nYYCn4o0lMkMafmhbSPAzS9TXAvQqJEyMXDzaH+JF2HuPZ FRsfTlBR0/HYUDA+pDUB3UkQXZ9tPE6GFSKaaaOA= Message-Id: <6.2.5.6.2.20130424061825.0673ee08@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 07:04:55 -0700 To: Simon Perreault From: S Moonesamy In-Reply-To: <5177C301.1090605@viagenie.ca> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <51779847.6060608@viagenie.ca> <6.2.5.6.2.20130424020229.0bef18a8@elandnews.com> <5177C301.1090605@viagenie.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, ipv6@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 14:12:18 -0000 Hi Simon, At 04:33 24-04-2013, Simon Perreault wrote: >I'm sorry, I've read section 5 and that still doesn't make sense to me. I share your opinion. >How does that work? Is there a NAT46 in between? That question was never discussed within the working group. My guess is that there would have to be a transition mechanism in between for that to work. >As IPv4-mapped IPv6 addresses do not go on the wire, this still >doesn't make sense to me! I should have explained it better; the IPv4-mapped IPv6 address does not go over the wire. >IPv4-mapped IPv6 addresses have two uses: > >1) They are used internally on a single host, between a userland app >and the kernel, to represent IPv4 addresses using an IPv6-only >socket. The address never leaves the host. It can be considered an >implementation detail. They are most useful when porting an >IPv4-only app to dual-stack. Newer applications should never use >IPv4-mapped IPv6 addresses, and it is good practice to disable them explicitly. > >2) In various signalling protocols, to represent an IPv4 address in >an IPv6 address field. This is protocol-specific. It is used only >for signalling, never as actual addresses in IPv6 packet headers. > >At this point, I'm guessing that it would be better to forget about >IPv4-mapped IPv6 addresses, although I still don't understand >exactly what your intent is. Thanks for the explanation. The intent was to ask the IPv6 Maintenance working group to review the text. I'll follow your guess as it makes sense to me. By the way you will be credited in the document shepherd write-up for your feedback. Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Wed Apr 24 07:27: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 1672C21F9195; Wed, 24 Apr 2013 07:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTTuA11jEYxn; Wed, 24 Apr 2013 07:26:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 93AFC21F90EB; Wed, 24 Apr 2013 07:26:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 52A9120E40FD; Wed, 24 Apr 2013 10:26:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366813617; bh=Rl4HLG+bzP6Pn1vCDO/2KPZFFC8ZVDasMipdndTcHUw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g/KNqeO9oOXq3tpbOtoWoHu19ICE9X6wiSEkQa015hJk8ZGi4PBszbexOxysV7xYB lu5lLtb6nsARv6q3jGQZqRdxRT8nIVhCheL8iwuuUxBjVUQNhVbb4DhybXXGzzN6cj J00IybM4d4UBpKRXIZwxlOUnxXdtYBz+eaYWyPhY= 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 3701420E4076; Wed, 24 Apr 2013 10:26:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org, Simon Perreault Date: Wed, 24 Apr 2013 10:26:54 -0400 Message-ID: <1806292.8gPQCWSlJz@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130424061825.0673ee08@elandnews.com> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <5177C301.1090605@viagenie.ca> <6.2.5.6.2.20130424061825.0673ee08@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: ipv6@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 14:27:00 -0000 On Wednesday, April 24, 2013 07:04:55 AM S Moonesamy wrote: > Hi Simon, > > At 04:33 24-04-2013, Simon Perreault wrote: > >I'm sorry, I've read section 5 and that still doesn't make sense to me. > > I share your opinion. > > >How does that work? Is there a NAT46 in between? > > That question was never discussed within the working group. My guess > is that there would have to be a transition mechanism in between for > that to work. > > >As IPv4-mapped IPv6 addresses do not go on the wire, this still > >doesn't make sense to me! > > I should have explained it better; the IPv4-mapped IPv6 address does > not go over the wire. > > >IPv4-mapped IPv6 addresses have two uses: > > > >1) They are used internally on a single host, between a userland app > >and the kernel, to represent IPv4 addresses using an IPv6-only > >socket. The address never leaves the host. It can be considered an > >implementation detail. They are most useful when porting an > >IPv4-only app to dual-stack. Newer applications should never use > >IPv4-mapped IPv6 addresses, and it is good practice to disable them > >explicitly. > > > >2) In various signalling protocols, to represent an IPv4 address in > >an IPv6 address field. This is protocol-specific. It is used only > >for signalling, never as actual addresses in IPv6 packet headers. > > > >At this point, I'm guessing that it would be better to forget about > >IPv4-mapped IPv6 addresses, although I still don't understand > >exactly what your intent is. > > Thanks for the explanation. The intent was to ask the IPv6 > Maintenance working group to review the text. I'll follow your guess > as it makes sense to me. By the way you will be credited in the > document shepherd write-up for your feedback. It was discussed. The case here is #2. In SPF there are various mechanisms that can be used in an SPF record to identify sources from which mail is authorized. Two of these mechanisms directly specify IP addresses. "ip4" is used to specify IPv4 addresses and "ip6" is used to specify IPv6 addresses (that's a design decision that was made in 2003, so it is what it is). The intent of the text was to communicate that if the SPF verification process (which could possibly be running in any internet networking environment you might think of) were presented with an IPv4-mapped IPv6 address, the correct way to check if that address is authorized is using the IPv4 part of the address to check against an "ip4" mechanism. I hope that clarifies the intent. If that makes sense, I would really appreciate suggestions as a better way to word it. Scott K (4408bis editor) From spf2@kitterman.com Wed Apr 24 08:09: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 DA5A921F89B2; Wed, 24 Apr 2013 08:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi5r41EhLfkc; Wed, 24 Apr 2013 08:09:28 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC5721F8793; Wed, 24 Apr 2013 08:09:27 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6726120E40FD; Wed, 24 Apr 2013 11:09:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366816167; bh=ZKhVP4U3Z+bijTcZ8vTxeRR7hdG5N2q5LEN1eev+LxE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZluOPRibcA0cABRzGF8/DuRRZHCPABfZmfX2L/TapsV/3rLU9A5SlCMhheH3RuLKv uKiZrk9qMdO2koPriiM/7medGP+UlnyZoHRYzn51TTnnwPAyjv+3BqlMc0zJyxFwxg 8J71MROHKO2/M3XGo05CEIsMt7kLnQN+M15NOYlk= 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 4C3C520E4076; Wed, 24 Apr 2013 11:09:26 -0400 (EDT) From: Scott Kitterman To: Simon Perreault , spfbis@ietf.org Date: Wed, 24 Apr 2013 11:09:26 -0400 Message-ID: <1607352.HJyrPRpzgN@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <5177F2A1.304@viagenie.ca> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1806292.8gPQCWSlJz@scott-latitude-e6320> <5177F2A1.304@viagenie.ca> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Cc: ipv6@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 15:09:29 -0000 On Wednesday, April 24, 2013 04:56:33 PM Simon Perreault wrote: > Le 2013-04-24 16:26, Scott Kitterman a =E9crit : > > The case here is #2. In SPF there are various mechanisms that can = be used > > in an SPF record to identify sources from which mail is authorized.= Two > > of these mechanisms directly specify IP addresses. "ip4" is used t= o > > specify IPv4 addresses and "ip6" is used to specify IPv6 addresses > > (that's a design decision that was made in 2003, so it is what it i= s). > >=20 > > The intent of the text was to communicate that if the SPF verificat= ion > > process (which could possibly be running in any internet networking= > > environment you might think of) were presented with an IPv4-mapped = IPv6 > > address, the correct way to check if that address is authorized is = using > > the IPv4 part of the address to check against an "ip4" mechanism. > >=20 > > I hope that clarifies the intent. >=20 > Very clear. >=20 > One problem I can think of: >=20 > What is the effect of specifying IPv4-mapped IPv6 addresses in "ip6" = SPF > data? Or through a AAAA DNS record that the SPF "ip6" process looks u= p? > If an SPF process that checks an IPv4-mapped IPv6 address uses > exclusively the "ip4" SPF data, then IPv4-mapped IPv6 addresses in "i= p6" > data would be ignored. I would consider that surprising. For example,= I > would expect an SPF rule producing ::ffff:0.0.0.0/96 to apply to all > IPv4-mapped IPv6 addresses, but it would simply get ignored. >=20 > Generally you want to treat IPv4-mapped IPv6 addresses like regular, > opaque IPv6 addresses unless you have good and specific reasons not t= o > do so. My initial thought is you should have put that in an "ip4" mechanism. = Other=20 way around (which is the concern that caused the text to be added) if t= he=20 IPv4-mapped addresses are treated as IPv6 addresses, then senders who o= nly=20 used IPv4 might have to dual publish any IPv4 addresses in both "ip4" a= nd=20 "ip6" mechanisms. That's bad in many ways. The goal was to try and cover this case in a way that it was clear that= this=20 was the reciever's problem to sort out and the sender didn't have to do= uble=20 publish, just in case (I've seen people do this). Suggestions? Scott K From simon.perreault@viagenie.ca Wed Apr 24 07:56: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 6B76B21F91BC; Wed, 24 Apr 2013 07:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sk8g+eVAeIen; Wed, 24 Apr 2013 07:56:53 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D51021F9380; Wed, 24 Apr 2013 07:56:37 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 971A0469F3; Wed, 24 Apr 2013 10:56:34 -0400 (EDT) Message-ID: <5177F2A1.304@viagenie.ca> Date: Wed, 24 Apr 2013 16:56:33 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <5177C301.1090605@viagenie.ca> <6.2.5.6.2.20130424061825.0673ee08@elandnews.com> <1806292.8gPQCWSlJz@scott-latitude-e6320> In-Reply-To: <1806292.8gPQCWSlJz@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 24 Apr 2013 08:43:52 -0700 Cc: spfbis@ietf.org, ipv6@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 14:56:57 -0000 Le 2013-04-24 16:26, Scott Kitterman a écrit : > The case here is #2. In SPF there are various mechanisms that can be used in > an SPF record to identify sources from which mail is authorized. Two of these > mechanisms directly specify IP addresses. "ip4" is used to specify IPv4 > addresses and "ip6" is used to specify IPv6 addresses (that's a design > decision that was made in 2003, so it is what it is). > > The intent of the text was to communicate that if the SPF verification process > (which could possibly be running in any internet networking environment you > might think of) were presented with an IPv4-mapped IPv6 address, the correct > way to check if that address is authorized is using the IPv4 part of the > address to check against an "ip4" mechanism. > > I hope that clarifies the intent. Very clear. One problem I can think of: What is the effect of specifying IPv4-mapped IPv6 addresses in "ip6" SPF data? Or through a AAAA DNS record that the SPF "ip6" process looks up? If an SPF process that checks an IPv4-mapped IPv6 address uses exclusively the "ip4" SPF data, then IPv4-mapped IPv6 addresses in "ip6" data would be ignored. I would consider that surprising. For example, I would expect an SPF rule producing ::ffff:0.0.0.0/96 to apply to all IPv4-mapped IPv6 addresses, but it would simply get ignored. Generally you want to treat IPv4-mapped IPv6 addresses like regular, opaque IPv6 addresses unless you have good and specific reasons not to do so. Simon From simon.perreault@viagenie.ca Wed Apr 24 08:15: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 9BEF721F8FA4; Wed, 24 Apr 2013 08:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us2l38P-kygQ; Wed, 24 Apr 2013 08:15:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8721F8EB9; Wed, 24 Apr 2013 08:15:39 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5D05E4044A; Wed, 24 Apr 2013 11:15:38 -0400 (EDT) Message-ID: <5177F719.3050209@viagenie.ca> Date: Wed, 24 Apr 2013 17:15:37 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1806292.8gPQCWSlJz@scott-latitude-e6320> <5177F2A1.304@viagenie.ca> <1607352.HJyrPRpzgN@scott-latitude-e6320> In-Reply-To: <1607352.HJyrPRpzgN@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 24 Apr 2013 08:44:00 -0700 Cc: spfbis@ietf.org, ipv6@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 15:15:39 -0000 Le 2013-04-24 17:09, Scott Kitterman a écrit : > On Wednesday, April 24, 2013 04:56:33 PM Simon Perreault wrote: > My initial thought is you should have put that in an "ip4" mechanism. Other > way around (which is the concern that caused the text to be added) if the > IPv4-mapped addresses are treated as IPv6 addresses, then senders who only > used IPv4 might have to dual publish any IPv4 addresses in both "ip4" and > "ip6" mechanisms. That's bad in many ways. I guess I just don't understand where those IPv4-mapped IPv6 addresses that the SPF process needs to check are coming from. An example would be very helpful. > The goal was to try and cover this case in a way that it was clear that this > was the reciever's problem to sort out and the sender didn't have to double > publish, just in case (I've seen people do this). Yeah, this is bad. Variants arise in many situations. Usually it is solved by treating IPv6 addresses as opaque and not giving any special meaning to the IPv4-mapped prefix. Simon From pkern@simplex.0x539.de Wed Apr 24 09:10: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 919A621F84A6; Wed, 24 Apr 2013 09:10:09 -0700 (PDT) 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_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3egbCmZxf7h0; Wed, 24 Apr 2013 09:10:09 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 027DD21F8DCF; Wed, 24 Apr 2013 09:10:08 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UV2GZ-0002it-Ll; Wed, 24 Apr 2013 18:09:55 +0200 Received: from [2001:470:720c:0:793a:99a:aedc:c0c3] (helo=simplex.lan.home.philkern.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UV2Ga-0007yu-Tk; Wed, 24 Apr 2013 18:09:57 +0200 Received: from pkern by simplex.lan.home.philkern.de with local (Exim 4.80) (envelope-from ) id 1UV2GY-0000LV-Er; Wed, 24 Apr 2013 18:09:54 +0200 Date: Wed, 24 Apr 2013 18:09:54 +0200 From: Philipp Kern To: Simon Perreault Message-ID: <20130424160954.GA31835@simplex.0x539.de> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1806292.8gPQCWSlJz@scott-latitude-e6320> <5177F2A1.304@viagenie.ca> <1607352.HJyrPRpzgN@scott-latitude-e6320> <5177F719.3050209@viagenie.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <5177F719.3050209@viagenie.ca> Organization: Fachschaft Mathematik / Informatik am Karlsruher Institut fuer Technologie (KIT) User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 24 Apr 2013 09:13:28 -0700 Cc: spfbis@ietf.org, ipv6@ietf.org, Scott Kitterman Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 16:10:09 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Simon, am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrieben: > I guess I just don't understand where those IPv4-mapped IPv6 > addresses that the SPF process needs to check are coming from. An > example would be very helpful. on Linux, if you set bindv6only to 0 and set up a socket listening on AF_INET6 you are able to receive IPv4 connections to that IPv6 socket. The source IPs will be mapped into IPv4-mapped IPv6 space. This means that you only need to setup one socket instead of one for v4 and one for v6. > Yeah, this is bad. Variants arise in many situations. Usually it is > solved by treating IPv6 addresses as opaque and not giving any > special meaning to the IPv4-mapped prefix. As above that does not help. If your SPF process is operating in the setup above, IPv4-mapped IPv6 space needs to be treated with the IPv4 ruleset. Kind regards Philipp Kern --jRHKVT23PllUwdXP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJReAPSAAoJEERuJUU10FbskDUH/08k/NZMl7bqrZR7RVpfISkB BZrCriX5lqVgibCmo3Z08iKp+AeCbRTFEkKDqjiirpgCF68fbSlY8mDEzyh3FeFM d6yz9f60SAJolEaQ4d19UKrJdeqHYo1jSwluq1COS8bEYmZLoC1k2bimZdtbaRzM pHm40WRgVsfpyKRkyYlGKlbieVZT8r6EzuRG0TOBdu70zBF9B+BdL9uDAz4nffBN sT+m43f2vVY7wzSCKA/wRdr7UYmPx3asla6C6hxXNT18K5sixARKAFK7aIHu0S3F wTVwH+Vbs5XBLklrxvsb+EdC6hakBr5y0kuWaRCpSctkWSI0RU06KH39U4/L6Jo= =l+vw -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From spf2@kitterman.com Wed Apr 24 09:22: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 149B621F9418; Wed, 24 Apr 2013 09:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4vO93AbkLd9; Wed, 24 Apr 2013 09:22:55 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E6E3721F93D8; Wed, 24 Apr 2013 09:22:54 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1624D20E40FD; Wed, 24 Apr 2013 12:22:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366820574; bh=Qu79qW+IurEfJ/yJSsvP9lWWoTK78drJIme8wIaEb+M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ITsE9Zwn3qe23KEhaltzpSNexEZvLMJAg+tqdhFD6UtF1uYelPnR11oeagjLVFSyS rAIR25xxH57K43roEPVaqmuYruqFgCCmwDhOirhs63Dva/FWWG0/7zwoBVZfVd7vAb oAr/N/tGj+O5BpBa8P4Tb4Kfcxy36vG/etciB6W8= 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 F285420E4076; Wed, 24 Apr 2013 12:22:53 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org, ipv6@ietf.org Date: Wed, 24 Apr 2013 12:22:52 -0400 Message-ID: <11888504.3H8g9Q4rip@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130424160954.GA31835@simplex.0x539.de> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <5177F719.3050209@viagenie.ca> <20130424160954.GA31835@simplex.0x539.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: Philipp Kern Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 16:22:56 -0000 On Wednesday, April 24, 2013 06:09:54 PM Philipp Kern wrote: > Simon, > > am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrieben: > > I guess I just don't understand where those IPv4-mapped IPv6 > > addresses that the SPF process needs to check are coming from. An > > example would be very helpful. > > on Linux, if you set bindv6only to 0 and set up a socket listening on > AF_INET6 you are able to receive IPv4 connections to that IPv6 socket. The > source IPs will be mapped into IPv4-mapped IPv6 space. This means that you > only need to setup one socket instead of one for v4 and one for v6. > > > Yeah, this is bad. Variants arise in many situations. Usually it is > > solved by treating IPv6 addresses as opaque and not giving any > > special meaning to the IPv4-mapped prefix. > > As above that does not help. If your SPF process is operating in the > setup above, IPv4-mapped IPv6 space needs to be treated with the IPv4 > ruleset. That sounds right. Apparently I fail at describing it though. Going back to the current text in the document: Section 5 of draft-ietf-spfbis-4408bis-14: 'When any mechanism fetches host addresses to compare with , when is an IPv4, "A" records are fetched; when 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 [RFC4291]. IPv4 addresses are only listed in an SPF record using the "ip4" mechanism.' I'd appreciate suggestions on making it clearer. Thanks, Scott K From SRS0=xZs3m=OL==stuart@gathman.org Wed Apr 24 09:21: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 3C5B421F9434 for ; Wed, 24 Apr 2013 09:21:56 -0700 (PDT) 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_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVDoaU+6CbLK for ; Wed, 24 Apr 2013 09:21:55 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 5489521F9427 for ; Wed, 24 Apr 2013 09:21:55 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1366820530; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=uZKkrcA3lcOmvKH5WC+pbXm+xT9vyziVlK393gsluZA=; b=HDavEPnuOZ0IDcF6JJ6FUtOZDooyRNf4hl/O4LRj00+vaGY9iCRniO7lmRdd2pVKYK9Vpe gNsfCT3BtmeT8r7qy2ONJYYSK5uUhR/bUMvhzdvQBMxdIHC0PuHi/8Rj5EF0gnlA6aQOVp4J RypvfPuyELavYT+Ctk1sJwW0nxnc8= Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3OGM9qR019561 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 24 Apr 2013 12:22:10 -0400 Message-ID: <517806A1.7070508@gathman.org> Date: Wed, 24 Apr 2013 12:21:53 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1806292.8gPQCWSlJz@scott-latitude-e6320> <5177F2A1.304@viagenie.ca> <1607352.HJyrPRpzgN@scott-latitude-e6320> <5177F719.3050209@viagenie.ca> <20130424160954.GA31835@simplex.0x539.de> In-Reply-To: <20130424160954.GA31835@simplex.0x539.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 16:31:24 -0000 Long ago, Nostradamus foresaw that on 04/24/2013 12:09 PM, Philipp Kern would write: > am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrieben: >> I guess I just don't understand where those IPv4-mapped IPv6 >> addresses that the SPF process needs to check are coming from. An >> example would be very helpful. > on Linux, if you set bindv6only to 0 and set up a socket listening on > AF_INET6 you are able to receive IPv4 connections to that IPv6 socket. The > source IPs will be mapped into IPv4-mapped IPv6 space. This means that you > only need to setup one socket instead of one for v4 and one for v6. As an example, if you want sendmail-8.14 to handle IP6, you configure it for IP6, and IP4 connections are IP4 mapped. I'm not sure where the translation takes place (maybe even in the kernel), but the sender socket address for IP4 mapped connections has address family IP4, and milters and logs get the IP4 address. So IP4 mapped IP6 connections MUST be treated exactly like an IP4 connection. From SRS0=xZs3m=OL==stuart@gathman.org Wed Apr 24 09:24: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 B753721F896B for ; Wed, 24 Apr 2013 09:24:08 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0rCkUkEdkcY for ; Wed, 24 Apr 2013 09:24:06 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 086A921F93D8 for ; Wed, 24 Apr 2013 09:23:52 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1366820646; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=ncw/Z7BafSHg2EejSMWf0e4/Qo4wEHncSaNJahESOc8=; b=lgIv7Ee6IyRtNTWgxUb01iVnSO3MqeA0c7VbpRHENOUZB+yoi+4QsWA2wv4rpHfrE8jzq5 FEcY0ZX+HoCByhLgXCLvokhCmy0oZvmjOSMD42cs9Lgb1GCFwBYhyrOPPh7SUkL/B1Ew55WK JW8PM4SfysYe/L+8zYLmItt+48+rI= Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3OGO5lm019580 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 24 Apr 2013 12:24:06 -0400 Message-ID: <51780716.7020406@gathman.org> Date: Wed, 24 Apr 2013 12:23:50 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> In-Reply-To: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 16:31:34 -0000 Long ago, Nostradamus foresaw that on 04/23/2013 06:03 PM, S Moonesamy would write: > Hello, > > Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: > > 'IANA is requested to add an annotation to the SPF RRTYPE saying > "(OBSOLETE - use TXT)" in the DNS Parameters registry.' > > Is the annotation in the DNS Parameters registry correct? And, more importantly (to me anyway), does that still ensure that the RR is available for any future v=spf3? The dual publishing as a transition may have failed, but the separate RR type is still a good idea for the next version. From SRS0=xZs3m=OL==stuart@gathman.org Wed Apr 24 09:28: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 B9C0A21F9425 for ; Wed, 24 Apr 2013 09:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhBIY+xtKBW9 for ; Wed, 24 Apr 2013 09:28:33 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 0223821F9199 for ; Wed, 24 Apr 2013 09:28:32 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1366820928; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=MNKvSCUHD9ukq7QGXzVS3KpS8c1hBmwE9X9K+YhT5N0=; b=Md09E2BeCO+3x+LeBS8HtpdhTFcRksSlSb5pNDuOW6yXauMWByjb0Z2cP+pWFV2Q/8KFoW PleCYZJto2ItG15UorGVRAvWoaAmemSesjd5szs3lpg/U/XVyOkr1x5Tw4XCIwgC1JLLGRbo LjS+qSSeUhdPsfiBn/KrQIPSap1yk= Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3OGSlYA019606 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 24 Apr 2013 12:28:48 -0400 Message-ID: <5178082F.7070601@gathman.org> Date: Wed, 24 Apr 2013 12:28:31 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130422145425.18526.qmail@joyce.lan> In-Reply-To: <20130422145425.18526.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 24 Apr 2013 16:31:40 -0000 Long ago, Nostradamus foresaw that on 04/22/2013 10:54 AM, John Levine would write: > In article you write: >> -=-=-=-=-=- >> -=-=-=-=-=- >> >> That leaves the ambiguity of handling -all in embedded (include:) records. >> What should be done if the sample foobar mechanism is being referenced in >> an included record? > At this point, I think we have to say that stuff like that is > undefined, since in reality it does whatever the code does, and it > happens so rarely that nobody cares. > > Remember that a standard needs to tell people what to do to interoperate, but > it doesn't have to tell you want to do if someone else screws up. > It wasn't undefined for rfc4408, and is in the test suite. It isn't undefined for rfc4408bis either - I'm just trying to prevent a few boneheaded implementations. From simon.perreault@viagenie.ca Wed Apr 24 09:27: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 5419F21F92C4; Wed, 24 Apr 2013 09:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwlvsMMnENFD; Wed, 24 Apr 2013 09:27:21 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A3AAB21F9199; Wed, 24 Apr 2013 09:27:21 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B591A403E5; Wed, 24 Apr 2013 12:27:20 -0400 (EDT) Message-ID: <517807E7.2050005@viagenie.ca> Date: Wed, 24 Apr 2013 18:27:19 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Philipp Kern References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1806292.8gPQCWSlJz@scott-latitude-e6320> <5177F2A1.304@viagenie.ca> <1607352.HJyrPRpzgN@scott-latitude-e6320> <5177F719.3050209@viagenie.ca> <20130424160954.GA31835@simplex.0x539.de> In-Reply-To: <20130424160954.GA31835@simplex.0x539.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 24 Apr 2013 09:34:02 -0700 Cc: spfbis@ietf.org, ipv6@ietf.org, Scott Kitterman Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 16:27:22 -0000 Le 2013-04-24 18:09, Philipp Kern a écrit : > Simon, > > am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrieben: >> I guess I just don't understand where those IPv4-mapped IPv6 >> addresses that the SPF process needs to check are coming from. An >> example would be very helpful. > > on Linux, if you set bindv6only to 0 and set up a socket listening on > AF_INET6 you are able to receive IPv4 connections to that IPv6 socket. The > source IPs will be mapped into IPv4-mapped IPv6 space. This means that you > only need to setup one socket instead of one for v4 and one for v6. I know what an IPv4-mapped IPv6 address is. In that case, you should convert IPv4-mapped IPv6 addresses to IPv4 addresses before feeding them to the SPF checker. Just like with any other protocol. >> Yeah, this is bad. Variants arise in many situations. Usually it is >> solved by treating IPv6 addresses as opaque and not giving any >> special meaning to the IPv4-mapped prefix. > > As above that does not help. If your SPF process is operating in the > setup above, IPv4-mapped IPv6 space needs to be treated with the IPv4 > ruleset. The SPF process should never see IPv4-mapped IPv6 addresses since the underlying layer needs to convert them to IPv4 addresses. There is nothing specific to the SPF protocol here. Simon From ogud@ogud.com Wed Apr 24 09:34: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 EAF9221F8D92 for ; Wed, 24 Apr 2013 09:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrBIuAw1VizD for ; Wed, 24 Apr 2013 09:34:23 -0700 (PDT) Received: from smtp112.dfw.emailsrvr.com (smtp112.dfw.emailsrvr.com [67.192.241.112]) by ietfa.amsl.com (Postfix) with ESMTP id 6F74221F8CDD for ; Wed, 24 Apr 2013 09:34:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 069D9240681; Wed, 24 Apr 2013 12:34:23 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp21.relay.dfw1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id D04C8240426; Wed, 24 Apr 2013 12:34:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olafur Gudmundsson In-Reply-To: <51780716.7020406@gathman.org> Date: Wed, 24 Apr 2013 12:34:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <51780716.7020406@gathman.org> To: Stuart Gathman X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 16:34:24 -0000 On Apr 24, 2013, at 12:23 PM, Stuart Gathman wrote: > Long ago, Nostradamus foresaw that on 04/23/2013 06:03 PM, S Moonesamy > would write: >> Hello, >>=20 >> Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF = RRTYPE: >>=20 >> 'IANA is requested to add an annotation to the SPF RRTYPE saying >> "(OBSOLETE - use TXT)" in the DNS Parameters registry.' >>=20 >> Is the annotation in the DNS Parameters registry correct? > And, more importantly (to me anyway), does that still ensure that the = RR > is available for any future v=3Dspf3? The dual publishing as a = transition > may have failed, but the separate RR type is still a good idea for the > next version. That will not work as the "client" will not know the format the SPF = record "target" is publishing=20 you need to pick one and only one option as much as I hate that SPF is = using TXT that boat has sailed=20 and forcing the SPF type usage will not work.=20 Olafur From spf2@kitterman.com Wed Apr 24 09: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 7E49321F87C5 for ; Wed, 24 Apr 2013 09:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cMLffPB5f6R for ; Wed, 24 Apr 2013 09:42:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CBD5721F86F4 for ; Wed, 24 Apr 2013 09:42:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5976820E40FD; Wed, 24 Apr 2013 12:42:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366821750; bh=Nb2Vf3nEFRaSWGXzQgZG3s6GCOrPkZVifgOF/pXd/vI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C+uwz9G+RqY5CkzZIAzqXadxZ/2BuufqM472BYuz4R4ejGZM2rcZoluqM3xqNbS24 t2wkZzgDm7U8zZFO/Z9Jt+3AcZrAR4alw8YPHkfK0cHAt0sUZQU78pH4xx3PU0GhvR ac7CK/MO1kCAopC+OfidxLdzR5UuI30a0Eur7dJ4= 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 3C4DB20E4076; Wed, 24 Apr 2013 12:42:29 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 24 Apr 2013 12:42:29 -0400 Message-ID: <9766120.devxyZIjod@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <51780716.7020406@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] Obsoleting SPF RRTYPE 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, 24 Apr 2013 16:42:31 -0000 On Wednesday, April 24, 2013 12:34:21 PM Olafur Gudmundsson wrote: > On Apr 24, 2013, at 12:23 PM, Stuart Gathman wrote: > > Long ago, Nostradamus foresaw that on 04/23/2013 06:03 PM, S Moonesamy > > > > would write: > >> Hello, > >> > >> Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: > >> 'IANA is requested to add an annotation to the SPF RRTYPE saying > >> > >> "(OBSOLETE - use TXT)" in the DNS Parameters registry.' > >> > >> Is the annotation in the DNS Parameters registry correct? > > > > And, more importantly (to me anyway), does that still ensure that the RR > > is available for any future v=spf3? The dual publishing as a transition > > may have failed, but the separate RR type is still a good idea for the > > next version. > > That will not work as the "client" will not know the format the SPF record > "target" is publishing you need to pick one and only one option as much as > I hate that SPF is using TXT that boat has sailed and forcing the SPF type > usage will not work. The case Stuart is concerned about is some hypothetical future incompatible upgrade to SPF that might use type SPF (and only type SPF) from the beginning. The RR type is still assigned and the DNS parameters registry could be changed again in the future, so if it comes up, I think the answer to Stuart's question is "Yes". Scott K From spf2@kitterman.com Wed Apr 24 09:46: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 47E3721F8F4F; Wed, 24 Apr 2013 09:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzMCC8QNodtJ; Wed, 24 Apr 2013 09:46:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BF9B821F8F12; Wed, 24 Apr 2013 09:46:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4DCB620E40FD; Wed, 24 Apr 2013 12:46:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366821990; bh=TmeCz1PzH6Ek36ldCvqRu4ZPNrf2eUVDjkh2d4zeD5I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qE0+hgi1x3lSCkAD0O5QY6rgGcc74o8V8fTtcIeDN+v6QnrnH1fzMd04Z6DJfC+rc +NCuJCxUZ2sHZ1jHct3yXzi4Obbtm8kJO3+BbMXstjfBJtxKoUXNUa/woWkGY/ERIC MtTModMm+/qkuU3R7I5nwWAFuQPVqikDeI29dEyo= 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 3801620E4076; Wed, 24 Apr 2013 12:46:29 -0400 (EDT) From: Scott Kitterman To: Simon Perreault Date: Wed, 24 Apr 2013 12:46:28 -0400 Message-ID: <1620648.vNPTWAe3vH@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <517807E7.2050005@viagenie.ca> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <20130424160954.GA31835@simplex.0x539.de> <517807E7.2050005@viagenie.ca> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis@ietf.org, ipv6@ietf.org, Philipp Kern Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 16:46:31 -0000 On Wednesday, April 24, 2013 06:27:19 PM Simon Perreault wrote: > Le 2013-04-24 18:09, Philipp Kern a =E9crit : > > Simon, > >=20 > > am Wed, Apr 24, 2013 at 05:15:37PM +0200 hast du folgendes geschrie= ben: > >> I guess I just don't understand where those IPv4-mapped IPv6 > >> addresses that the SPF process needs to check are coming from. An > >> example would be very helpful. > >=20 > > on Linux, if you set bindv6only to 0 and set up a socket listening = on > > AF_INET6 you are able to receive IPv4 connections to that IPv6 sock= et. The > > source IPs will be mapped into IPv4-mapped IPv6 space. This means t= hat you > > only need to setup one socket instead of one for v4 and one for v6.= >=20 > I know what an IPv4-mapped IPv6 address is. >=20 > In that case, you should convert IPv4-mapped IPv6 addresses to IPv4 > addresses before feeding them to the SPF checker. Just like with any > other protocol. >=20 > >> Yeah, this is bad. Variants arise in many situations. Usually it i= s > >> solved by treating IPv6 addresses as opaque and not giving any > >> special meaning to the IPv4-mapped prefix. > >=20 > > As above that does not help. If your SPF process is operating in th= e > > setup above, IPv4-mapped IPv6 space needs to be treated with the IP= v4 > > ruleset. >=20 > The SPF process should never see IPv4-mapped IPv6 addresses since the= > underlying layer needs to convert them to IPv4 addresses. There is > nothing specific to the SPF protocol here. So from your perspective, we could remove that guidance and replace it = with=20 something along the lines of: Check_host() [that's our generic SPF validation function name we use in= the=20 document] should never see IPv4-mapped IPv6 addresses. The underlying = layer=20 needs to convert them to IPv4 addresses. Is that about right? Phil? Scott K From spf2@kitterman.com Wed Apr 24 09:55: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 2832421F8B07; Wed, 24 Apr 2013 09:55:23 -0700 (PDT) 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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysfJaB-1-myv; Wed, 24 Apr 2013 09:55:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9C33B21F8793; Wed, 24 Apr 2013 09:55:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8A45720E40FD; Wed, 24 Apr 2013 12:55:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366822520; bh=EZovo0k3YZc2bzC4lnc1l2QWXKtM/n7YmWgvsxFtY3s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GeJMnLhXWDJIjY/tXjuRZsfG3ePLkJ0RRPTgl0qbNAKL8P3QxfaXPNg+xuRfNHadz n5kW9/7m8GK2+Knzby3HK1eyC54bnIwCBJ4aeDfn/pH9la7yIrdTUUyqtWZ27vu9FR 5Yf+41GCo4SCdlarfcCdzsi7FtDVBBpePSf+gwoQ= 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 7912920E4076; Wed, 24 Apr 2013 12:55:20 -0400 (EDT) From: Scott Kitterman To: Simon Perreault , spfbis@ietf.org Date: Wed, 24 Apr 2013 12:55:19 -0400 Message-ID: <3088486.LRMBpqBOZF@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <51780DCC.7020802@viagenie.ca> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1620648.vNPTWAe3vH@scott-latitude-e6320> <51780DCC.7020802@viagenie.ca> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Cc: ipv6@ietf.org, Philipp Kern Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 16:55:23 -0000 On Wednesday, April 24, 2013 06:52:28 PM Simon Perreault wrote: > Le 2013-04-24 18:46, Scott Kitterman a =E9crit : > > So from your perspective, we could remove that guidance and replace= it > > with > > something along the lines of: > >=20 > > Check_host() [that's our generic SPF validation function name we us= e in > > the > > document] should never see IPv4-mapped IPv6 addresses. The underly= ing > > layer needs to convert them to IPv4 addresses. > >=20 > > Is that about right? >=20 > Yes, that's perfect. >=20 > Now, there's nothing specific to SPF here, but I don't know of any > general guidelines that you could reference, so feel free to go ahead= > with that. Thanks. I'll use that unless Phil responds and it turns out you two ne= ed to=20 argue some more. Scott K From superuser@gmail.com Wed Apr 24 09:56: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 3B5AB21F8F2C for ; Wed, 24 Apr 2013 09:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.712 X-Spam-Level: X-Spam-Status: No, score=-2.712 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71VxZFaSEnGS for ; Wed, 24 Apr 2013 09:56:49 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2832121F8B07 for ; Wed, 24 Apr 2013 09:56:49 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id c10so2329974wiw.8 for ; Wed, 24 Apr 2013 09:56:48 -0700 (PDT) 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=0tFMROcn0z19DkC6f0ZE8dhjoyb+N1zYeEbiM0tueko=; b=EyrUzZX0rxyf6jlt+62fcBoDJEjcrdc2eOfsVMWEnEbluXabCCcfjAEycF8owg7t+J VxKPa0tNLTbL6LYwhtM4DMdU/XyZMhGnWGesYLiK86B0g2pFczIBx8VTxLm8PglHJ1jv MdYzWrpSRaQ7u5mbmSVAkWGK21rQEmXCj5Mpc6aWG6ee0KfNjdNQvWL6wNGHrbPc6Of5 cEZSF/OuSXS1FDQfE7d5IB6f920XSad3gtJfluPZYd+XmtP4mEl/fSj2cdnDmLeM4KYD 6fsNjrre7ExtS46hZq+J3mfk3tsmRb7ys3WdR1Jf6tu/J4VvDRKVpwu77iD9qp1Q4Pdl uY4g== MIME-Version: 1.0 X-Received: by 10.194.222.100 with SMTP id ql4mr26084281wjc.59.1366822608285; Wed, 24 Apr 2013 09:56:48 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 24 Apr 2013 09:56:48 -0700 (PDT) In-Reply-To: <517796D9.9050303@tana.it> References: <51726641.7070606@tana.it> <51763F51.3020608@tana.it> <1478526.K9TjTEXC2I@scott-latitude-e6320> <5176B405.3010109@tana.it> <517796D9.9050303@tana.it> Date: Wed, 24 Apr 2013 09:56:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a11c1b94209b5c304db1e3075 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 24 Apr 2013 16:56:50 -0000 --001a11c1b94209b5c304db1e3075 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 24, 2013 at 1:24 AM, Alessandro Vesely wrote: > > I don't even understand what problem we're trying to fix here. > > That the spec doesn't lend itself well to being used as a building > block for other specs willing to refer to SPF results. > DMARC, for example, hasn't found that to be the case. > > Are you saying you want the consumer of this to be able to tell > > which mode SPF was in (MAIL FROM vs. HELO) when it reached its > > conclusion? > > Yes. > > > If so, I would expect that's obvious from the result spec; > > "smtp.mailfrom" means it evaluated the MAIL FROM command > > parameter. > > Right, but since that parameter was null, the verifier synthesized a > mailbox composed of the local-part "postmaster" and the "HELO" > identity, as per Section 2.2. > Such synthesis is meant for internal use by the SPF module only. If that value is exposed via A-R or some other method, then the module is distributing false information. If we're going to anything here, I think a sentence or two in Section 9 is the right solution. > > > What would you think a client would want to do with that information? > > VBR, for example, is interested in authenticating a mail domain rather > than a host name, because of the granularity it standardizes. > But an A-R field would use one or the other (whichever one it verified), which gives the VBR module the information it needs. > > > If I'm to take your example as indicating the SPF verifier produced > > mangled output, then I guess it shouldn't do that. But again, this > > is a topic for apps-discuss, not spfbis. > > Perhaps, 5451bis could word something clever in terms of check_host() > so that other specs can refer to it instead of SPF. However, if a > message is going to be rejected, the border MTA SHOULD issue an [SMTP] > rejection response to the message rather than adding this header field > with the failure result. Which brings us back to this thread's subject. > But doesn't the bis draft already say that? -MSK --001a11c1b94209b5c304db1e3075 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2013 at 1:24 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
> I don't even understand what proble= m we're trying to fix here.

That the spec doesn't lend itself well to being used as a buildin= g
block for other specs willing to refer to SPF results.

DMARC, for example, hasn't found that to be the case.=A0
> Are you saying you want the consumer of this to be a= ble to tell
> which mode SPF was in (MAIL FROM vs. HELO) when it reached its
> conclusion?

Yes.

> If so, I would expect that's obvious from the result spec;
> "smtp.mailfrom" means it evaluated the MAIL FROM command
> parameter.

Right, but since that parameter was null, the verifier synthesized a<= br> mailbox composed of the local-part "postmaster" and the "HEL= O"
identity, as per Section 2.2.

Such synt= hesis is meant for internal use by the SPF module only.=A0 If that value is= exposed via A-R or some other method, then the module is distributing fals= e information.=A0 If we're going to anything here, I think a sentence o= r two in Section 9 is the right solution.
=A0

> What would you think a client would want to do with that information?<= br>
VBR, for example, is interested in authenticating a mail domain rathe= r
than a host name, because of the granularity it standardizes.

But an A-R field would use one or the other (whichev= er one it verified), which gives the VBR module the information it needs. =A0

> If I'm to take your example as indicating the SPF verifier produce= d
> mangled output, then I guess it shouldn't do that. =A0But again, t= his
> is a topic for apps-discuss, not spfbis.

Perhaps, 5451bis could word something clever in terms of check_host()=
so that other specs can refer to it instead of SPF. =A0However, if a
message is going to be rejected, the border MTA SHOULD issue an [SMTP]
rejection response to the message rather than adding this header field
with the failure result. =A0Which brings us back to this thread's subje= ct.

But doesn't the bis draft alrea= dy say that?

-MSK
--001a11c1b94209b5c304db1e3075-- From simon.perreault@viagenie.ca Wed Apr 24 09:52:42 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 21BE621F9425; Wed, 24 Apr 2013 09:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK6pQ3o2fdDO; Wed, 24 Apr 2013 09:52:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A5D2A21F9424; Wed, 24 Apr 2013 09:52:34 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1A2B2403E5; Wed, 24 Apr 2013 12:52:28 -0400 (EDT) Message-ID: <51780DCC.7020802@viagenie.ca> Date: Wed, 24 Apr 2013 18:52:28 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <20130424160954.GA31835@simplex.0x539.de> <517807E7.2050005@viagenie.ca> <1620648.vNPTWAe3vH@scott-latitude-e6320> In-Reply-To: <1620648.vNPTWAe3vH@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 24 Apr 2013 10:05:50 -0700 Cc: spfbis@ietf.org, ipv6@ietf.org, Philipp Kern Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 16:52:42 -0000 Le 2013-04-24 18:46, Scott Kitterman a écrit : > So from your perspective, we could remove that guidance and replace it with > something along the lines of: > > Check_host() [that's our generic SPF validation function name we use in the > document] should never see IPv4-mapped IPv6 addresses. The underlying layer > needs to convert them to IPv4 addresses. > > Is that about right? Yes, that's perfect. Now, there's nothing specific to SPF here, but I don't know of any general guidelines that you could reference, so feel free to go ahead with that. Simon From tom.taylor.stds@gmail.com Wed Apr 24 09:57: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 1C79B21F8B07; Wed, 24 Apr 2013 09:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxq-vcQ244+a; Wed, 24 Apr 2013 09:57:17 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4C85221F95A0; Wed, 24 Apr 2013 09:57:17 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so1727907obq.31 for ; Wed, 24 Apr 2013 09:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QGHvGaWytNMn/6zT5Vh7YpQUvXuOrpM+SV7SaeBSX4M=; b=fLbLccgxEuXUV1Ytqi+yhQVyRx/34oICpTpOtmtQ4MeqZXH8AALPWfsc5NGWJRQHgY Re1QdNvjdYxpj3+QlJRw8TOFQwrVlJl91HHcmF/hgUBdjRdI1wOFLY1ZjjWdcoNtiUVU eXR+wB2jpzr77k4L4hv0jheWZynDKZnlvCnumAelWS3odIw2X3MDC15GBspG6BX/cEwT jUOpFY2E5HtuElvT3+TBL1PXM50YD/MWxDab+r90Tw8sL+Suf25WkdafVnJ4CXKAJCI6 YkMFQ+YkGwoL/c0BfTjMJyGRZ7Te2ybxl6HrmwpwdrXGiwqcINdoQ3805KJiB0fSJ2kv Ba5w== X-Received: by 10.60.160.165 with SMTP id xl5mr7430895oeb.61.1366822636861; Wed, 24 Apr 2013 09:57:16 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPSA id do4sm1553627oeb.0.2013.04.24.09.57.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 09:57:16 -0700 (PDT) Message-ID: <51780EEC.4000205@gmail.com> Date: Wed, 24 Apr 2013 12:57:16 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <5177F719.3050209@viagenie.ca> <20130424160954.GA31835@simplex.0x539.de> <11888504.3H8g9Q4rip@scott-latitude-e6320> In-Reply-To: <11888504.3H8g9Q4rip@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 24 Apr 2013 10:05:50 -0700 Cc: spfbis@ietf.org, ipv6@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 16:57:18 -0000 Could I suggest the following: - Keep the first sentence unchanged. - Then: SPF implementations on IPv6 servers need to handle both "AAAA" and "A" records. This is because clients on IPv4 mapped IPv6 addresses [RFC4291] will appear to the SPF implementation as IPv4 clients. Complementarily to this, SPF records for such clients must contain only IPv4 addresses. On 24/04/2013 12:22 PM, Scott Kitterman wrote: > On Wednesday, April 24, 2013 06:09:54 PM Philipp Kern wrote: ... >> As above that does not help. If your SPF process is operating in the >> setup above, IPv4-mapped IPv6 space needs to be treated with the IPv4 >> ruleset. > > That sounds right. Apparently I fail at describing it though. Going back to > the current text in the document: > > Section 5 of draft-ietf-spfbis-4408bis-14: > > 'When any mechanism fetches host addresses to compare with , when > is an IPv4, "A" records are fetched; when 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 [RFC4291]. IPv4 addresses are only > listed in an SPF record using the "ip4" mechanism.' > > I'd appreciate suggestions on making it clearer. > > Thanks, > > Scott K > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From SRS0=xZs3m=OL==stuart@gathman.org Wed Apr 24 10:28: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 94A9621F8F08 for ; Wed, 24 Apr 2013 10:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-ZfwD+wzBBW for ; Wed, 24 Apr 2013 10:28:13 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id CD8C121F8F07 for ; Wed, 24 Apr 2013 10:28:12 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1366824508; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=jODFPxK/rt0Sv6npEIt/HTJGOX07SqQGsvelvVPjsq0=; b=jNgoItDl5pq7U63RPkwaUL9X/73GjbYIf1ebvIJEARROlx/zE1PneqQJG9DijTrrrs2LVd fP+wrHK690mkniZ3WtyuF40/eawSjORdvoBLVx9DjfKrdecunIlEo296yQodgzPsFc5UjZK/ DMu6BR3qT+IOoq5+YORVkDzdIB+3g= Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3OHSRS9019887 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 24 Apr 2013 13:28:28 -0400 Message-ID: <5178162B.8000505@gathman.org> Date: Wed, 24 Apr 2013 13:28:11 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130409062431.GK24624@mx1.yitter.info> <2528747.v4GPD3HTbD@scott-latitude-e6320> <51763F5D.3080004@tana.it> <2417280.JQpPtHczhD@scott-latitude-e6320> <5176FC31.3070801@isdg.net> In-Reply-To: <5176FC31.3070801@isdg.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 24 Apr 2013 17:28:13 -0000 Long ago, Nostradamus foresaw that on 04/23/2013 05:25 PM, Hector Santos would write: > I believe that would be a FAIL on our left to right natural string > parser, -ALL would terminate the processing, never see foobar. > > I think its correct logic to expect of all. Don't assume processing > would be a two-pass parser: > > Pass One: Check Validity of entire line > Pass Two: Process each string word as its extracted from the line. > > I would think the easiest, fastest is just a one pass parser. > You always have to parse the whole line, regardless, because you have to find any modifiers after "all". You can use a one-pass parser, but you will have to just note a match, and keep parsing until the end. Furthermore, as discussed for rfc4408, a guiding principle of SPF is for results to be deterministic as much as possible. Permerror or not depending on the connection is not good. From spf2@kitterman.com Wed Apr 24 10:32: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 6D74921F8F0F for ; Wed, 24 Apr 2013 10:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQlbYtza18a1 for ; Wed, 24 Apr 2013 10:32:56 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A56F821F8F08 for ; Wed, 24 Apr 2013 10:32:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2D8CD20E40FD; Wed, 24 Apr 2013 13:32:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366824776; bh=YtTNXEJ/lrAW8qSaeCbtEcA8FfE7EiTMt1QtN+6Y2yY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kdfbEy0olHmVCU6AegJGGgaoDsABDiRDWUhFQ48N8d2h78slgzcGrcok0P5byS0YC KayALnHlk7nzo6HZGUbEJkyQQ8VzSQSFIhn/J2gM6ftxArnVqhDWQnHD8+7jRaFoz5 AU4YMh0ohbZ+OShXZL8IPkdENBlXjtZRomDRemho= 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 1285720E4076; Wed, 24 Apr 2013 13:32:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 24 Apr 2013 13:32:55 -0400 Message-ID: <1647903.MlMSe2e5Xm@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <5178162B.8000505@gathman.org> References: <20130409062431.GK24624@mx1.yitter.info> <5176FC31.3070801@isdg.net> <5178162B.8000505@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] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first* 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, 24 Apr 2013 17:32:57 -0000 On Wednesday, April 24, 2013 01:28:11 PM Stuart Gathman wrote: > Long ago, Nostradamus foresaw that on 04/23/2013 05:25 PM, Hector Santos > > would write: > > I believe that would be a FAIL on our left to right natural string > > parser, -ALL would terminate the processing, never see foobar. > > > > I think its correct logic to expect of all. Don't assume processing > > > > would be a two-pass parser: > > Pass One: Check Validity of entire line > > Pass Two: Process each string word as its extracted from the line. > > > > I would think the easiest, fastest is just a one pass parser. > > You always have to parse the whole line, regardless, because you have to > find any modifiers after "all". You can use a one-pass parser, but you > will have to just note a match, and keep parsing until the end. > > Furthermore, as discussed for rfc4408, a guiding principle of SPF is for > results to be deterministic as much as possible. Permerror or not > depending on the connection is not good. Definitely. Scott K From johnl@iecc.com Wed Apr 24 10:43: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 1A60121F9027 for ; Wed, 24 Apr 2013 10:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYQ+UsxT0D+c for ; Wed, 24 Apr 2013 10:43:55 -0700 (PDT) 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 15EC221F8FA4 for ; Wed, 24 Apr 2013 10:43:54 -0700 (PDT) Received: (qmail 71777 invoked from network); 24 Apr 2013 17:43:54 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Apr 2013 17:43:54 -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; s=517819da.xn--yuvv84g.k1304; i=johnl@user.iecc.com; bh=L5W2BF418MEtXkUlO9ggCErpQ49/rRVk/4SXh5u6jSM=; b=dTm2YBnqeJIDqI2Y4qw1obcP9+eEGlX50eG3Jc+G6JbkOQp3tyNXMIX56ZzX0TcA8PDba5TZUO8q/wqU1hMezcwj31M+sdeaHPkPbVs8YMzKShtDwWIbzR8BY7WIxBv8U8gIMAMCkaU7iXRb4hAvtczl5iCZx+Tvm726a6Hd2jE= 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; s=517819da.xn--yuvv84g.k1304; olt=johnl@user.iecc.com; bh=L5W2BF418MEtXkUlO9ggCErpQ49/rRVk/4SXh5u6jSM=; b=zv7X8bflbwjn9TaEqTs4Oj+4luhq29rcyO6iLIob8VPXxZErPoH/k48uZbm4bOetFwTgpakXBI+xuLrHWsui6f3u+TfUBofmKQLAvQPc+zommxXM+Ncdxi6GAyGx9DqicOAmPmf5RxJdSug9pO8URG41Pj4CJmdCSplwm0ePE1w= Date: 24 Apr 2013 17:43:31 -0000 Message-ID: <20130424174331.35011.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] New issue: 8.4. Fail: rejection is not described explicitly 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, 24 Apr 2013 17:43:56 -0000 >> That the spec doesn't lend itself well to being used as a building >> block for other specs willing to refer to SPF results. > >DMARC, for example, hasn't found that to be the case. Nor has the Authentication-Results: header, which was defined after 4408. R's, John From johnl@iecc.com Wed Apr 24 10:50: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 5220B21F8900 for ; Wed, 24 Apr 2013 10:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgbuYV7dpomd for ; Wed, 24 Apr 2013 10:50:03 -0700 (PDT) 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 62C1821F890F for ; Wed, 24 Apr 2013 10:50:03 -0700 (PDT) Received: (qmail 73787 invoked from network); 24 Apr 2013 17:50:02 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Apr 2013 17:50:02 -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; s=51781b4a.xn--i8sz2z.k1304; i=johnl@user.iecc.com; bh=Xw9vwhKGEqTOir7YVD/MUx429L+VIfY0Tt3PwAuk4oU=; b=jU239sZfYOl7rE3l8dF0Abf76ygZsj5nUuT7CmWPYe5hp/TW+PvcW7z+wlEqMTlbUpes7n+prvAw/UT5qfBLmZzESyib8OLKgavIjBI5m4ne1k9qj/LNzdzyAt2sr/4RZrjWt3P5iHz8n2pV/zX0suw/TGRLu7A8+Ifs2yNfm3w= 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; s=51781b4a.xn--i8sz2z.k1304; olt=johnl@user.iecc.com; bh=Xw9vwhKGEqTOir7YVD/MUx429L+VIfY0Tt3PwAuk4oU=; b=K50dYqBqVjHinX3+KYFzFkNNrpXSUXoKrP/pRXCqradn0P09I+wAkHdADlfyPhwUjxzFVvNM2JuqJhvO/4uAMd3qykhY/vduyG3ksu5msvYe/rZvCWKvTFOoKUM5m5Ks21+Eq2HdMuAfYmnRHDmrl6pJle6ufb6IOGO3DJGgrxM= Date: 24 Apr 2013 17:49:40 -0000 Message-ID: <20130424174940.35096.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1620648.vNPTWAe3vH@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] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 17:50:04 -0000 >Check_host() [that's our generic SPF validation function name we use in the >document] should never see IPv4-mapped IPv6 addresses. The underlying layer >needs to convert them to IPv4 addresses. > >Is that about right? Depends on the implementation. On FreeBSD, you sometimes see addresses like ::ffff:1.2.3.4 which are mapped. I think we should leave the text alone, since anyone implementing SPF on dual stacked hosts should know what it means. From superuser@gmail.com Wed Apr 24 10:54: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 B182B21F8E9E for ; Wed, 24 Apr 2013 10:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KsQoDX8z3Aw for ; Wed, 24 Apr 2013 10:54:05 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DB40F21F8A6B for ; Wed, 24 Apr 2013 10:53:50 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id o7so1821746wea.18 for ; Wed, 24 Apr 2013 10:53:50 -0700 (PDT) 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=7aFlkg1yBO2+lzLShOH3oUctNqgsy7VCZqK2RABbHt0=; b=ZOBUXv9p+wStNJOdWL44jxdiGdCD5T/LfP0uGawF3ptNuRkGUBc4GRw3PYgIiKFHEg xTdXJPOtdCYil+bN206JppcVhC1qF3dE6dI81abtWhn3qzg0gwEihieVxzDHJ+xG9e/I 1kJkkGDO9iMkxHBrS/01WhYtoqeXqUZXfI54EPZAfkFZPKeVd9HkTOGOFH7r2PHZdyGO B1qDsTa9iLdbBZffRIMVhG6hlpUH/YY+EwSIWGmSFzoD3ZymjkCwHEuymuF6FUWFIv/O u4QtVz1Az2t7jjLiDg55/2+xC7TcNpoUbvhyjUEFwjUbV/SOCdCj7I/E2EY8P1IEyBNj bhOQ== MIME-Version: 1.0 X-Received: by 10.180.80.3 with SMTP id n3mr46819701wix.20.1366826030013; Wed, 24 Apr 2013 10:53:50 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 24 Apr 2013 10:53:49 -0700 (PDT) In-Reply-To: <9766120.devxyZIjod@scott-latitude-e6320> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <51780716.7020406@gathman.org> <9766120.devxyZIjod@scott-latitude-e6320> Date: Wed, 24 Apr 2013 10:53:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04182538fd288d04db1efbbc Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 17:54:05 -0000 --f46d04182538fd288d04db1efbbc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 24, 2013 at 9:42 AM, Scott Kitterman wrote: > > >> "(OBSOLETE - use TXT)" in the DNS Parameters registry.' > > >> > > >> Is the annotation in the DNS Parameters registry correct? > > > > > > And, more importantly (to me anyway), does that still ensure that the > RR > > > is available for any future v=spf3? The dual publishing as a > transition > > > may have failed, but the separate RR type is still a good idea for the > > > next version. > > > > That will not work as the "client" will not know the format the SPF > record > > "target" is publishing you need to pick one and only one option as much > as > > I hate that SPF is using TXT that boat has sailed and forcing the SPF > type > > usage will not work. > > The case Stuart is concerned about is some hypothetical future incompatible > upgrade to SPF that might use type SPF (and only type SPF) from the > beginning. > The RR type is still assigned and the DNS parameters registry could be > changed > again in the future, so if it comes up, I think the answer to Stuart's > question is "Yes". > The issue, however, is that SPFv3 might decide it wants an SPF RR that isn't formatted like a TXT field. That part probably can't/shouldn't be changed. Andrew, is there any precedent for this kind of recycling of RR types? Do you have any advice? -MSK --f46d04182538fd288d04db1efbbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2013 at 9:42 AM, Scott Kitterman <spf2@k= itterman.com> wrote:
> >> =A0 "(O= BSOLETE - use TXT)" in the DNS Parameters registry.'
> >>
> >> Is the annotation in the DNS Parameters registry correct?
> >
> > And, more importantly (to me anyway), does that still ensure that= the RR
> > is available for any future v=3Dspf3? =A0The dual publishing as a= transition
> > may have failed, but the separate RR type is still a good idea fo= r the
> > next version.
>
> That will not work as the "client" will not know the format = the SPF record
> "target" is publishing you need to pick one and only one opt= ion as much as
> I hate that SPF is using TXT that boat has sailed and forcing the SPF = type
> usage will not work.

The case Stuart is concerned about is some hypothetical future incomp= atible
upgrade to SPF that might use type SPF (and only type SPF) from the beginni= ng.
The RR type is still assigned and the DNS parameters registry could be chan= ged
again in the future, so if it comes up, I think the answer to Stuart's<= br> question is "Yes".

The issue, howe= ver, is that SPFv3 might decide it wants an SPF RR that isn't formatted= like a TXT field.=A0 That part probably can't/shouldn't be changed= .

Andrew, is there any precedent for thi= s kind of recycling of RR types?=A0 Do you have any advice?

-MSK
--f46d04182538fd288d04db1efbbc-- From ajs@anvilwalrusden.com Wed Apr 24 11:05: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 E1A5321F8C38 for ; Wed, 24 Apr 2013 11:05:16 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC+4GHRP+pCZ for ; Wed, 24 Apr 2013 11:05:16 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9D821F8738 for ; Wed, 24 Apr 2013 11:05:16 -0700 (PDT) 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 C36428A031 for ; Wed, 24 Apr 2013 18:05:15 +0000 (UTC) Date: Wed, 24 Apr 2013 14:05:13 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130424180512.GN16817@mx1.yitter.info> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <51780716.7020406@gathman.org> <9766120.devxyZIjod@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 18:05:17 -0000 On Wed, Apr 24, 2013 at 10:53:49AM -0700, Murray S. Kucherawy wrote: > > The issue, however, is that SPFv3 might decide it wants an SPF RR that > isn't formatted like a TXT field. That part probably can't/shouldn't be > changed. > > Andrew, is there any precedent for this kind of recycling of RR types? Do > you have any advice? If it's not formatted the same way as the old record (modulo the version number, I guess, and any differences that arise as a result), use a new RRTYPE. It's just better that way. Note that over on dnsext@ we're having a somewhat dull discussion about whether it'd have been better for an expert reviewer to have insisted on a single RRTYPE instead of two in a recent decision. The barriers to new RRTYPE assignment that happened when the SPF TXT decision was made are not there now. If there were an SPFv3 that needed a significantly different format, adding a new RRTYPE would be easy. It'd probably be better not to revive TYPE 99 in the future, also, for that reason. A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Wed Apr 24 11:08: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 C2F3D21F8E79 for ; Wed, 24 Apr 2013 11:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD+2E6Yj-5g7 for ; Wed, 24 Apr 2013 11:08:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2D821F8E5F for ; Wed, 24 Apr 2013 11:08:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 921D720E40FD; Wed, 24 Apr 2013 14:08:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366826894; bh=+zKlP0yNlRb0fbWT0BsSLldcj0aFn04nkJmjb7PeqZU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FyZF4L+7BAUDNDfsVWWFFQiIzOfboVJHkpQv7rwWMBHqRGaHAcMY6bT8bDuueQpoT FY2KIqCa63RjZQxIUAPmv1uwnYhxdnkZW1ZUptNJ5yUb0lxVihu2IxZARo8KjMlUDS UXK1nhkgwbuQQGXauPyU9AWipcoKYG8TEEdTYAwk= 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 75C1E20E4076; Wed, 24 Apr 2013 14:08:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 24 Apr 2013 14:08:11 -0400 Message-ID: <1431349.C0e3qG0mtd@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130424180512.GN16817@mx1.yitter.info> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130424180512.GN16817@mx1.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 18:08:16 -0000 On Wednesday, April 24, 2013 02:05:13 PM Andrew Sullivan wrote: > On Wed, Apr 24, 2013 at 10:53:49AM -0700, Murray S. Kucherawy wrote: > > The issue, however, is that SPFv3 might decide it wants an SPF RR that > > isn't formatted like a TXT field. That part probably can't/shouldn't be > > changed. > > > > Andrew, is there any precedent for this kind of recycling of RR types? Do > > you have any advice? > > If it's not formatted the same way as the old record (modulo the > version number, I guess, and any differences that arise as a result), > use a new RRTYPE. It's just better that way. > > Note that over on dnsext@ we're having a somewhat dull discussion > about whether it'd have been better for an expert reviewer to have > insisted on a single RRTYPE instead of two in a recent decision. The > barriers to new RRTYPE assignment that happened when the SPF TXT > decision was made are not there now. If there were an SPFv3 that > needed a significantly different format, adding a new RRTYPE would be > easy. It'd probably be better not to revive TYPE 99 in the future, > also, for that reason. The barriers to RR type assignment are different, but the barriers to RR type deployment (which in my opinion were more important for Type 99/SPF) are still real and substantial. Scott K From superuser@gmail.com Wed Apr 24 11:10: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 413C821F89D8; Wed, 24 Apr 2013 11:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbO9Osb21t6b; Wed, 24 Apr 2013 11:10:39 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3E36C21F8976; Wed, 24 Apr 2013 11:10:39 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id l13so7677067wie.16 for ; Wed, 24 Apr 2013 11:10:36 -0700 (PDT) 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=Ba8cvBvljJ0I+Lc8i6w0UiQFV/3IQL0JAqD+Hzi/Z5E=; b=VWTo0AuegogLUtKJDMZgNwypS5EBNf/DZTtuILvcslOwS0XU+0wOdCHTT2hsmGKTAm 73NTUaGOl9mht+a5xRzjwGjQj5tE92rp2hN2vMhWIP15Ynhhugd/tXTLIFDuPr3wVA2u ttaPFD25hyBvPNh75S8niZMpWNZqake1B35cWeGrgATdz83gqZc66EkYnG06S2tKs14E i/ckpPqocC2TLvxsnuwvzgZDOQahKaKdMqs8wtQHC3qktmwIeTofLkUdqcmLLZjKI0Ru +737ip1JEIzEDf5G/AvSvqnkbrpw/BFQ1/eLZBIPARWILoZB6KEVzJE1Z4E70XO/+Wca idVw== MIME-Version: 1.0 X-Received: by 10.180.92.229 with SMTP id cp5mr6988662wib.20.1366827036675; Wed, 24 Apr 2013 11:10:36 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 24 Apr 2013 11:10:36 -0700 (PDT) In-Reply-To: <51780DCC.7020802@viagenie.ca> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <20130424160954.GA31835@simplex.0x539.de> <517807E7.2050005@viagenie.ca> <1620648.vNPTWAe3vH@scott-latitude-e6320> <51780DCC.7020802@viagenie.ca> Date: Wed, 24 Apr 2013 11:10:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: Simon Perreault Content-Type: multipart/alternative; boundary=f46d043c094efd937a04db1f376d Cc: "spfbis@ietf.org" , ipv6@ietf.org, Scott Kitterman , Philipp Kern Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 18:10:40 -0000 --f46d043c094efd937a04db1f376d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Apr 24, 2013 at 9:52 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2013-04-24 18:46, Scott Kitterman a =E9crit : > > So from your perspective, we could remove that guidance and replace it >> with >> something along the lines of: >> >> Check_host() [that's our generic SPF validation function name we use in >> the >> document] should never see IPv4-mapped IPv6 addresses. The underlying >> layer >> needs to convert them to IPv4 addresses. >> >> Is that about right? >> > > Yes, that's perfect. > > Now, there's nothing specific to SPF here, but I don't know of any genera= l > guidelines that you could reference, so feel free to go ahead with that. > > I like this, but I would change "needs" to "is expected". (And be careful with "should".) -MSK --f46d043c094efd937a04db1f376d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2013 at 9:52 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
Le 2013-04-24 18:= 46, Scott Kitterman a =E9crit :

So from your perspective, we could remove that guidance and replace it with=
something along the lines of:

Check_host() [that's our generic SPF validation function name we use in= the
document] should never see IPv4-mapped IPv6 addresses. =A0The underlying la= yer
needs to convert them to IPv4 addresses.

Is that about right?

Yes, that's perfect.

Now, there's nothing specific to SPF here, but I don't know of any = general guidelines that you could reference, so feel free to go ahead with = that.


I like this, but I would= change "needs" to "is expected".=A0 (And be careful wi= th "should".)

-MSK

--f46d043c094efd937a04db1f376d-- From superuser@gmail.com Wed Apr 24 11:14: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 BC91221F8D92 for ; Wed, 24 Apr 2013 11:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKquHCyy+6JZ for ; Wed, 24 Apr 2013 11:14:52 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 043D921F8D31 for ; Wed, 24 Apr 2013 11:14:51 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hm14so2390741wib.17 for ; Wed, 24 Apr 2013 11:14:51 -0700 (PDT) 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=v4AS3qDTW8MbpmrNsVTNVpZU9dlu7EY0jN69AYMSzf4=; b=CUwzMRBP+gxQUqDj/GU050Zvu3qdcXd619aYG+faIhgkSWWG/m1d62WJ8qS41TUaZh K9vXp9kaUzn8D35KhD+Jyuk1LbujfU8L+/WJflgMqgtQLnbEd7DmWhUZGxgeVTI+I8sn BSKD36ykEo8NSZAaP4ruefUGe3snweggkSw0FhMgrLp+k1UKxVC/EHIRxSDgXAYxnIMI GhLqYIAMqq29vP8mAv92VoVoM1JG4xVS9OW168rBlr1bOKMtX1CsvIm7OOl0dWt5I/Pa tPSZPUI5RdOlf2i3pMoG5zzxJKOO0mnLYZhPL1AMzGkEQcK34khvpbELmhNJHlE0vUXv fREw== MIME-Version: 1.0 X-Received: by 10.180.94.133 with SMTP id dc5mr10264285wib.1.1366827291218; Wed, 24 Apr 2013 11:14:51 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 24 Apr 2013 11:14:51 -0700 (PDT) In-Reply-To: <1431349.C0e3qG0mtd@scott-latitude-e6320> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130424180512.GN16817@mx1.yitter.info> <1431349.C0e3qG0mtd@scott-latitude-e6320> Date: Wed, 24 Apr 2013 11:14:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04462e6629a19f04db1f476d Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 18:14:52 -0000 --f46d04462e6629a19f04db1f476d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 24, 2013 at 11:08 AM, Scott Kitterman wrote: > The barriers to RR type assignment are different, but the barriers to RR > type > deployment (which in my opinion were more important for Type 99/SPF) are > still > real and substantial. > > Sure, but they're unchanged. I think the only reason not to fully obsolete type 99 would be if we think SPF3 is: a) likely to ever appear; and b) likely to do a TXT clone again; and c) likely to be able to tolerate finding legacy SPFv1 records, which undoubtedly will linger. -MSK --f46d04462e6629a19f04db1f476d Content-Type: text/html; charset=ISO-8859-1
On Wed, Apr 24, 2013 at 11:08 AM, Scott Kitterman <spf2@kitterman.com> wrote:
The barriers to RR type assignment are different, but the barriers to RR type
deployment (which in my opinion were more important for Type 99/SPF) are still
real and substantial.


Sure, but they're unchanged.

I think the only reason not to fully obsolete type 99 would be if we think SPF3 is:

a) likely to ever appear; and

b) likely to do a TXT clone again; and

c) likely to be able to tolerate finding legacy SPFv1 records, which undoubtedly will linger.

-MSK
--f46d04462e6629a19f04db1f476d-- From spf2@kitterman.com Wed Apr 24 11:20: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 A46B321F8F63 for ; Wed, 24 Apr 2013 11:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnLA3v-l804r for ; Wed, 24 Apr 2013 11:20:40 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 51BF621F8E7A for ; Wed, 24 Apr 2013 11:20:40 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 672AD20E40FD; Wed, 24 Apr 2013 14:20:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366827638; bh=hkfAJzwwVxxtlaTP3r1QRYPTws9LTY5m+QTfdvjj7x4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HcNkgrBIntHCrjYBzHcvfh6XuRVscKFBDrUCuhdbLlCIITM0rC2dV7fX7PiloO6VC FHW3W4furQi2z2ZTuudn6CWOvxhVZysNs+JsfoIa/jfW3WkKYitTKxHQmTUSEcqwxw AEwScs2rRxJZg4F14pn2BYN/WgxxgDvQfP1y/CP0= 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 4C72D20E4076; Wed, 24 Apr 2013 14:20:37 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 24 Apr 2013 14:20:37 -0400 Message-ID: <1936386.sgrkPvE9zZ@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1431349.C0e3qG0mtd@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] Obsoleting SPF RRTYPE 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, 24 Apr 2013 18:20:41 -0000 On Wednesday, April 24, 2013 11:14:51 AM Murray S. Kucherawy wrote: > On Wed, Apr 24, 2013 at 11:08 AM, Scott Kitterman wrote: > > The barriers to RR type assignment are different, but the barriers to RR > > type > > deployment (which in my opinion were more important for Type 99/SPF) are > > still > > real and substantial. > > Sure, but they're unchanged. > > I think the only reason not to fully obsolete type 99 would be if we think > SPF3 is: > > a) likely to ever appear; and > > b) likely to do a TXT clone again; and > > c) likely to be able to tolerate finding legacy SPFv1 records, which > undoubtedly will linger. > > -MSK When we discussed this before, we concluded there was no benefit to fully obsoleting it since Type 99 still couldn't be reused for something else. I've seen lots of "If we could do an incompatible update to SPF ..." discussions over the last 9 years and I don't recall changing the record structure ever coming up. If there's a new version, I'm confident it would use a text clone. Scott K From superuser@gmail.com Wed Apr 24 11:35: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 3DDA021F89B2 for ; Wed, 24 Apr 2013 11:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja0vAbysCWmS for ; Wed, 24 Apr 2013 11:35:02 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0A09B21F8624 for ; Wed, 24 Apr 2013 11:35:01 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so954276wgh.0 for ; Wed, 24 Apr 2013 11:35:01 -0700 (PDT) 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=L7RAKFy17fXA8huHoxu01L9849tXEJVcAEWUIouR0tw=; b=BV5Y4lGUau4WE30QM/1+6u4VgNexE92kATdhyZf3fRzTVXJgel2xq+02nJfqNI2RYQ aUnXhgaFpzW2i6cKOhMflzbslImxiVi4e5MZYmx4w9qiT1jrI6iig0WLenk1o4h1RB+/ tGszRQLQDHZdWt4ubRZ4It5Ad/D1TCoQLykRnfxv6dQGfHNgEmu4HeYpgASH2a2SkvCX 8B1ll+xM62vD/xG2jsX3aOMdOqZ40DO0nrzHqjzJ7RORt2drtQ1PWIDiX9gcHLjxtHvw u1NqAVm5A5tK8JH3D0ERNXHK7eAB5LTbhISRrCOY6HZGhTd1hxp8nZmgrFKgsagojnnG tb/g== MIME-Version: 1.0 X-Received: by 10.180.37.101 with SMTP id x5mr8864wij.0.1366828488047; Wed, 24 Apr 2013 11:34:48 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 24 Apr 2013 11:34:47 -0700 (PDT) In-Reply-To: <1936386.sgrkPvE9zZ@scott-latitude-e6320> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1431349.C0e3qG0mtd@scott-latitude-e6320> <1936386.sgrkPvE9zZ@scott-latitude-e6320> Date: Wed, 24 Apr 2013 11:34:47 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=e89a8f646ff37fc11604db1f8e1c Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 18:35:03 -0000 --e89a8f646ff37fc11604db1f8e1c Content-Type: text/plain; charset=ISO-8859-1 Maybe it's enough to just update the DNS record type registry to point to the bis document as the defining document, wherein we already say "Don't use type 99 anymore". -MSK On Wed, Apr 24, 2013 at 11:20 AM, Scott Kitterman wrote: > On Wednesday, April 24, 2013 11:14:51 AM Murray S. Kucherawy wrote: > > On Wed, Apr 24, 2013 at 11:08 AM, Scott Kitterman >wrote: > > > The barriers to RR type assignment are different, but the barriers to > RR > > > type > > > deployment (which in my opinion were more important for Type 99/SPF) > are > > > still > > > real and substantial. > > > > Sure, but they're unchanged. > > > > I think the only reason not to fully obsolete type 99 would be if we > think > > SPF3 is: > > > > a) likely to ever appear; and > > > > b) likely to do a TXT clone again; and > > > > c) likely to be able to tolerate finding legacy SPFv1 records, which > > undoubtedly will linger. > > > > -MSK > > When we discussed this before, we concluded there was no benefit to fully > obsoleting it since Type 99 still couldn't be reused for something else. > > I've seen lots of "If we could do an incompatible update to SPF ..." > discussions over the last 9 years and I don't recall changing the record > structure ever coming up. If there's a new version, I'm confident it > would use > a text clone. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --e89a8f646ff37fc11604db1f8e1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Maybe it's enough to just update the DNS record t= ype registry to point to the bis document as the defining document, wherein= we already say "Don't use type 99 anymore".

-MS= K


On Wed,= Apr 24, 2013 at 11:20 AM, Scott Kitterman <spf2@kitterman.com> wrote:
On W= ednesday, April 24, 2013 11:14:51 AM Murray S. Kucherawy wrote:
> On Wed, Apr 24, 2013 at 11:08 AM, Scott Kitterman <spf2@kitterman.com>wrote:
> > The barriers to RR type assignment are different, but the barrier= s to RR
> > type
> > deployment (which in my opinion were more important for Type 99/S= PF) are
> > still
> > real and substantial.
>
> Sure, but they're unchanged.
>
> I think the only reason not to fully obsolete type 99 would be if we t= hink
> SPF3 is:
>
> a) likely to ever appear; and
>
> b) likely to do a TXT clone again; and
>
> c) likely to be able to tolerate finding legacy SPFv1 records, which > undoubtedly will linger.
>
> -MSK

When we discussed this before, we concluded there was no benefi= t to fully
obsoleting it since Type 99 still couldn't be reused for something else= .

I've seen lots of "If we could do an incompatible update to SPF ..= ."
discussions over the last 9 years and I don't recall changing the recor= d
structure ever coming up. =A0If there's a new version, I'm confiden= t it would use
a text clone.

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

--e89a8f646ff37fc11604db1f8e1c-- From pkern@simplex.0x539.de Wed Apr 24 11:51: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 023C121F8EF5; Wed, 24 Apr 2013 11:51:10 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFY5ddIPMb0L; Wed, 24 Apr 2013 11:51:07 -0700 (PDT) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id DE02121F8EC9; Wed, 24 Apr 2013 11:51:01 -0700 (PDT) Received: from hub.kern.lc ([91.143.80.43]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UV4lp-0005WB-43; Wed, 24 Apr 2013 20:50:21 +0200 Received: from [2001:470:720c:0:793a:99a:aedc:c0c3] (helo=simplex.lan.home.philkern.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UV4lb-0008Lz-B3; Wed, 24 Apr 2013 20:50:07 +0200 Received: from pkern by simplex.lan.home.philkern.de with local (Exim 4.80) (envelope-from ) id 1UV4la-0002F2-2z; Wed, 24 Apr 2013 20:50:06 +0200 Date: Wed, 24 Apr 2013 20:50:05 +0200 From: Philipp Kern To: Scott Kitterman Message-ID: <20130424185005.GB8393@simplex.0x539.de> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1620648.vNPTWAe3vH@scott-latitude-e6320> <51780DCC.7020802@viagenie.ca> <3088486.LRMBpqBOZF@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3088486.LRMBpqBOZF@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 24 Apr 2013 11:54:12 -0700 Cc: spfbis@ietf.org, Simon Perreault , ipv6@ietf.org Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 18:51:11 -0000 On Wed, Apr 24, 2013 at 12:55:19PM -0400, Scott Kitterman wrote: > Thanks. I'll use that unless Phil responds and it turns out you two need to > argue some more. I don't think so, that seems fine. ;-) Indeed one would assume that guidance wrt IPv4-mapped IPv6 exists somewhere already. Kind regards Philipp Kern From WebMaster@Commerco.Net Wed Apr 24 12:01: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 9FF2F21F9406 for ; Wed, 24 Apr 2013 12:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8cKWRDPYFRA for ; Wed, 24 Apr 2013 12:01:52 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id DE36B21F93E3 for ; Wed, 24 Apr 2013 12:01:51 -0700 (PDT) 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=YjjykpgsrA6f2S+N7VMQxVOxuwDBFPuAbapUw1TpIwNfI+pusdaZ5b8iuW2+A8ku4IX+zUaNLwTuvqwdbimMVmGm1N2AhTM3Xr6r9jixOfM0Ui0s3AKWIrGmHCxJNqSZwShC1CqLZ17C4W+gPx7yw+JJY7ntTIzOS1CiS+6LoCA= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.6) with ESMTP (EHLO [10.240.241.49]); Wed, 24 Apr 2013 19:01:49 +0000 Message-ID: <51782C16.7050404@Commerco.Net> Date: Wed, 24 Apr 2013 13:01:42 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1431349.C0e3qG0mtd@scott-latitude-e6320> <1936386.sgrkPvE9zZ@scott-latitude-e6320> In-Reply-To: <1936386.sgrkPvE9zZ@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: Scott Kitterman Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 19:01:52 -0000 On 4/24/2013 12:20 PM, Scott Kitterman wrote: > On Wednesday, April 24, 2013 11:14:51 AM Murray S. Kucherawy wrote: >> On Wed, Apr 24, 2013 at 11:08 AM, Scott Kitterman wrote: >>> The barriers to RR type assignment are different, but the barriers to RR >>> type >>> deployment (which in my opinion were more important for Type 99/SPF) are >>> still >>> real and substantial. >> >> Sure, but they're unchanged. >> >> I think the only reason not to fully obsolete type 99 would be if we think >> SPF3 is: >> >> a) likely to ever appear; and >> >> b) likely to do a TXT clone again; and >> >> c) likely to be able to tolerate finding legacy SPFv1 records, which >> undoubtedly will linger. >> >> -MSK > > When we discussed this before, we concluded there was no benefit to fully > obsoleting it since Type 99 still couldn't be reused for something else. > > I've seen lots of "If we could do an incompatible update to SPF ..." > discussions over the last 9 years and I don't recall changing the record > structure ever coming up. If there's a new version, I'm confident it would use > a text clone. > > Scott K I agree with Scott. The TXT RRs (and SPF, until the SPFbis retired the use) for the current SPF includes the v=spf1 syntax. Certainly, if the SPF/99 RR format was substantially changed in a future, the one thing we probably could depend upon would have to be the use of say, v=spf3, making what whatever follows entirely a design choice for the spec designers of SPFv3 at the time. In other words, the SPF/99 RRs could change substantively or remain largely the same without any impact to existing v=spf1 implementations (and for SPFbis adopters, SPF/99 RRs should not even be used in v=spf1). Thus, IMO retiring or depreciating the SPF/99 RR seems wasteful, as it certainly could be reused down the road without harm to current (albeit, now inappropriate as of SPFbis) implementers. Alan M From spf2@kitterman.com Wed Apr 24 12:04: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 CDA1C21F86B8 for ; Wed, 24 Apr 2013 12:04:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6AHT7BH4Lyp for ; Wed, 24 Apr 2013 12:04:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A9DE121F84FD for ; Wed, 24 Apr 2013 12:04:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0298720E40FD; Wed, 24 Apr 2013 15:04:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366830273; bh=0T2LzK88ZrNo8szhqcCOYG5G/7AdxC1XeTKlNiRvrKQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cKBH4KcdyzioewKkKVExkDG7D8j8/1kjiT+OHHkKFGawRMMSj95vfRSPXp0BTJlMy ckq0SjGnLv3liJYSMgaqJhFUdTllYk4CNM8lQB+9C4tqtUMqZNBD/j4oqRpH98s4uY QqlyCmWhWzFWSyU5Jysbk4h/wXy5NhfJXioC6uUI= 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 D961720E4076; Wed, 24 Apr 2013 15:04:32 -0400 (EDT) From: Scott Kitterman To: "spfbis@ietf.org" Date: Wed, 24 Apr 2013 15:04:31 -0400 Message-ID: <2936220.a4Qo14FLj7@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1936386.sgrkPvE9zZ@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] Obsoleting SPF RRTYPE 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, 24 Apr 2013 19:04:38 -0000 Sounds reasonable. Would you propose modified text please? Scott K On Wednesday, April 24, 2013 11:34:47 AM Murray S. Kucherawy wrote: > Maybe it's enough to just update the DNS record type registry to point to > the bis document as the defining document, wherein we already say "Don't > use type 99 anymore". > > -MSK > > On Wed, Apr 24, 2013 at 11:20 AM, Scott Kitterman wrote: > > On Wednesday, April 24, 2013 11:14:51 AM Murray S. Kucherawy wrote: > > > On Wed, Apr 24, 2013 at 11:08 AM, Scott Kitterman > > > > >wrote: > > > > The barriers to RR type assignment are different, but the barriers to > > > > RR > > > > > > type > > > > deployment (which in my opinion were more important for Type 99/SPF) > > > > are > > > > > > still > > > > real and substantial. > > > > > > Sure, but they're unchanged. > > > > > > I think the only reason not to fully obsolete type 99 would be if we > > > > think > > > > > SPF3 is: > > > > > > a) likely to ever appear; and > > > > > > b) likely to do a TXT clone again; and > > > > > > c) likely to be able to tolerate finding legacy SPFv1 records, which > > > undoubtedly will linger. > > > > > > -MSK > > > > When we discussed this before, we concluded there was no benefit to fully > > obsoleting it since Type 99 still couldn't be reused for something else. > > > > I've seen lots of "If we could do an incompatible update to SPF ..." > > discussions over the last 9 years and I don't recall changing the record > > structure ever coming up. If there's a new version, I'm confident it > > would use > > a text clone. > > > > Scott K > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From superuser@gmail.com Wed Apr 24 12:25: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 EFADD21F93BC for ; Wed, 24 Apr 2013 12:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VAg7KdFGdpl for ; Wed, 24 Apr 2013 12:25:05 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 31BB221F8E4B for ; Wed, 24 Apr 2013 12:25:05 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x43so1870363wey.25 for ; Wed, 24 Apr 2013 12:25:04 -0700 (PDT) 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=TUWiOimogzf9Mxbox+IMMx1m0pwmuZq/PVito4w/azI=; b=Xdk3szsoC9ikY6qdrZIKeDPbedasUcHDhU8tT8n9jEj3/+QYBAxNjXvlUKm49m0gKM 6reXPjS9goHFx7OwSkIkuihnIGMwYd67zCZB8GouJUnjg8YD0NwJ9pl2COHXIf3b2VuM EVF9OQ1vgXO/BHjEUKljQdYYT7xAS/7ELJ1TkKzhU8JpbgPTPPBCbW/EBECu+TrfUz9A vF2OFkZ8OQm9ZBMXc+DNZqIPpPqb+AEGnFfm48XNlSkVFDVI+cucHbgsdesR43KCZkjr /qRU1tn6WVffqksGjvOnzgwBz1Mh59qXoCnyoZrm3votu08OMC8MoHTX/vyruU0sy4BP xZrA== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr70921202wjb.15.1366831504277; Wed, 24 Apr 2013 12:25:04 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 24 Apr 2013 12:25:04 -0700 (PDT) In-Reply-To: <2936220.a4Qo14FLj7@scott-latitude-e6320> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1936386.sgrkPvE9zZ@scott-latitude-e6320> <2936220.a4Qo14FLj7@scott-latitude-e6320> Date: Wed, 24 Apr 2013 12:25:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e010d857447c8a904db204272 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 19:25:06 -0000 --089e010d857447c8a904db204272 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 24, 2013 at 12:04 PM, Scott Kitterman wrote: > Sounds reasonable. Would you propose modified text please? > Replace Section 13.1 with: Per [RFC4408], ... (as you have it now until) ... [US-ASCII]. Studies have shown that RRTYPE 99 has not seen any substantial use, and in fact its existence and mechanism defined in [RFC4408] has led to some interoperability issues. Accordingly, its use is now obsolete, and new implementations are not to use it. IANA is requested to update the Resource Record (RR) TYPEs registry to indicate that this document is the reference document for that RRTYPE. --089e010d857447c8a904db204272 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2013 at 12:04 PM, Scott Kitterman <spf2@= kitterman.com> wrote:
Sounds reasonable. Would = you propose modified text please?

Repla= ce Section 13.1 with:

Per [RFC4408], ... (as you have it now until) ...=A0 [US-ASC= II].

Studies have shown that RRTYPE 99 has not seen any s= ubstantial use, and in fact its existence and mechanism defined in [RFC4408= ] has led to some interoperability issues.=A0 Accordingly, its use is now o= bsolete, and new implementations are not to use it.

IANA is requested to update the Resource Record (= RR) TYPEs registry to indicate that this document is the reference document= for that RRTYPE.
--089e010d857447c8a904db204272-- From spf2@kitterman.com Wed Apr 24 12:44: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 D30DB21F8618 for ; Wed, 24 Apr 2013 12:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOmuVhNrWg96 for ; Wed, 24 Apr 2013 12:44:13 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 40B9B21F83DF for ; Wed, 24 Apr 2013 12:44:13 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1B05720E40FD; Wed, 24 Apr 2013 15:44:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366832652; bh=48vxSXDaWzY6rjD93c9lYvszFMrQdnH7Z20u9epXB8I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LIqpN4WzHNONL+4A3xZR7Fsg2Uv1RsWbRNnzI200HAL+dmQWh8BNibrz1cLTtKOuO 7P0jarP5JkG91o0HpY4LR/ckyHPX7L6Yh+rwiccCSJQe2chpMDCjLh0jIhx+MWxZr8 fkyDNsA/G+wkWIPKUk0QKvUp4qxLMTYlfeS/v2Jg= 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 0137A20E4076; Wed, 24 Apr 2013 15:44:11 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 24 Apr 2013 15:44:10 -0400 Message-ID: <5844273.qoMFm1C3hB@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <2936220.a4Qo14FLj7@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] Obsoleting SPF RRTYPE 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, 24 Apr 2013 19:44:13 -0000 On Wednesday, April 24, 2013 12:25:04 PM Murray S. Kucherawy wrote: > Studies have shown that RRTYPE 99 has not seen any substantial use, and in > fact its existence and mechanism defined in [RFC4408] has led to some > interoperability issues. Accordingly, its use is now obsolete, and new > implementations are not to use it. > > IANA is requested to update the Resource Record (RR) TYPEs registry to > indicate that this document is the reference document for that RRTYPE. Thanks. Done locally. Scott K From WebMaster@Commerco.Net Wed Apr 24 13: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 3573721F890F for ; Wed, 24 Apr 2013 13:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7FydUZr2FIA for ; Wed, 24 Apr 2013 13:00:50 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id C385821F86BB for ; Wed, 24 Apr 2013 13:00:48 -0700 (PDT) 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=YIMVKrFHErpJpGWBoHWtNhB4iXhQdTzVBgM2ap7qb1yrZLpy6kQGcEOz0G9yaIuuItB3ypUKtOuriT3hcHk0S9KVRJfIyFkFT5GINweRr0wG/GLNyAPpT7H6TYi60RizcCdbF2pocCNw3cG7kO/trT1rmfbVFxRvC3+1xzQ1jzQ= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.6) with ESMTP (EHLO [10.240.241.49]); Wed, 24 Apr 2013 20:00:45 +0000 Message-ID: <517839E6.6080403@Commerco.Net> Date: Wed, 24 Apr 2013 14:00:38 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "spfbis@ietf.org" References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1936386.sgrkPvE9zZ@scott-latitude-e6320> <2936220.a4Qo14FLj7@scott-latitude-e6320> 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" , Scott Kitterman Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 20:00:51 -0000 On 4/24/2013 1:25 PM, Murray S. Kucherawy wrote: > On Wed, Apr 24, 2013 at 12:04 PM, Scott Kitterman > wrote: > > Sounds reasonable. Would you propose modified text please? > > > Replace Section 13.1 with: > > Per [RFC4408], ... (as you have it now until) ... [US-ASCII]. > > Studies have shown that RRTYPE 99 has not seen any substantial use, and > in fact its existence and mechanism defined in [RFC4408] has led to some > interoperability issues. Accordingly, its use is now obsolete, and new > implementations are not to use it. > > IANA is requested to update the Resource Record (RR) TYPEs registry to > indicate that this document is the reference document for that RRTYPE. > > Could we consider this? Studies have shown that DNS RRTYPE 99 has not enjoyed the substantial use seen by SPF TXT records for "v=spf1" deployment. In fact, its existence and mechanism as defined in [RFC4408] have led to some interoperability issues. Accordingly, its use for SPF "v=spf1" records is now obsolete, and any new implementations of SPF "v=spf1" are not to consider RRTYPE 99 in processing nor use RRTYPE 99 in SPF record deployment. IANA is requested to update the Resource Record (RR) TYPEs registry to indicate that this document is the reference document for that RRTYPE until such time any future SPF version may redefine its use. Alan M. From spf2@kitterman.com Wed Apr 24 13:04: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 73AF521F86CA for ; Wed, 24 Apr 2013 13:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl403Rc9Kqpm for ; Wed, 24 Apr 2013 13:04:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C128521F86C5 for ; Wed, 24 Apr 2013 13:04:46 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1719720E40FD; Wed, 24 Apr 2013 16:04:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366833886; bh=7jQDPezeZ+7XTdjofLeGdHOFHuwKhPD7iDJZpPjjqyU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EiybYq7IHB6Y/V93TeqvqQA0LB1Efazq/6gsCSGqZIEsGp3ZAvjfkdGgkGrL/wB9L FX/MuzzLXWmT+MxPrcWs8Q881Shj3uNH16M1SH6dVPzJZJ+b476RLoE7aOHXa+2TiK 5J5vhII9bLTXwmTGuVVMiPuk648MxOs1PaEh9Wtw= 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 D199220E4076; Wed, 24 Apr 2013 16:04:35 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 24 Apr 2013 16:04:29 -0400 Message-ID: <2815523.KcR0f6LIC4@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <517839E6.6080403@Commerco.Net> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <517839E6.6080403@Commerco.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] Obsoleting SPF RRTYPE 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, 24 Apr 2013 20:04:47 -0000 On Wednesday, April 24, 2013 02:00:38 PM Commerco WebMaster wrote: > On 4/24/2013 1:25 PM, Murray S. Kucherawy wrote: > > On Wed, Apr 24, 2013 at 12:04 PM, Scott Kitterman > > > > wrote: > > Sounds reasonable. Would you propose modified text please? > > > > Replace Section 13.1 with: > > > > Per [RFC4408], ... (as you have it now until) ... [US-ASCII]. > > > > Studies have shown that RRTYPE 99 has not seen any substantial use, and > > in fact its existence and mechanism defined in [RFC4408] has led to some > > interoperability issues. Accordingly, its use is now obsolete, and new > > implementations are not to use it. > > > > IANA is requested to update the Resource Record (RR) TYPEs registry to > > indicate that this document is the reference document for that RRTYPE. > > Could we consider this? > > Studies have shown that DNS RRTYPE 99 has not enjoyed the substantial > use seen by SPF TXT records for "v=spf1" deployment. In fact, its > existence and mechanism as defined in [RFC4408] have led to some > interoperability issues. Accordingly, its use for SPF "v=spf1" records > is now obsolete, and any new implementations of SPF "v=spf1" are not to > consider RRTYPE 99 in processing nor use RRTYPE 99 in SPF record deployment. > > IANA is requested to update the Resource Record (RR) TYPEs registry to > indicate that this document is the reference document for that RRTYPE > until such time any future SPF version may redefine its use. I think that raises more questions than it answers. I believe it's better as msk proposed. Scott K From ajs@anvilwalrusden.com Wed Apr 24 13:05: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 20AA021F89DB for ; Wed, 24 Apr 2013 13:05:21 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OANoKx8tgKFq for ; Wed, 24 Apr 2013 13:05:20 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9969121F89B2 for ; Wed, 24 Apr 2013 13:05:20 -0700 (PDT) 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 CA0048A031 for ; Wed, 24 Apr 2013 20:05:19 +0000 (UTC) Date: Wed, 24 Apr 2013 16:05:18 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130424200517.GX16817@mx1.yitter.info> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1431349.C0e3qG0mtd@scott-latitude-e6320> <1936386.sgrkPvE9zZ@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 20:05:21 -0000 In which case, we're not deprecating the RRTYPE, just deprecating its use. That sounds perfectly reasonable to me. I don't know if the registry even gets updated. A On Wed, Apr 24, 2013 at 11:34:47AM -0700, Murray S. Kucherawy wrote: > Maybe it's enough to just update the DNS record type registry to point to > the bis document as the defining document, wherein we already say "Don't > use type 99 anymore". > > -MSK > > > On Wed, Apr 24, 2013 at 11:20 AM, Scott Kitterman wrote: > > > On Wednesday, April 24, 2013 11:14:51 AM Murray S. Kucherawy wrote: > > > On Wed, Apr 24, 2013 at 11:08 AM, Scott Kitterman > >wrote: > > > > The barriers to RR type assignment are different, but the barriers to > > RR > > > > type > > > > deployment (which in my opinion were more important for Type 99/SPF) > > are > > > > still > > > > real and substantial. > > > > > > Sure, but they're unchanged. > > > > > > I think the only reason not to fully obsolete type 99 would be if we > > think > > > SPF3 is: > > > > > > a) likely to ever appear; and > > > > > > b) likely to do a TXT clone again; and > > > > > > c) likely to be able to tolerate finding legacy SPFv1 records, which > > > undoubtedly will linger. > > > > > > -MSK > > > > When we discussed this before, we concluded there was no benefit to fully > > obsoleting it since Type 99 still couldn't be reused for something else. > > > > I've seen lots of "If we could do an incompatible update to SPF ..." > > discussions over the last 9 years and I don't recall changing the record > > structure ever coming up. If there's a new version, I'm confident it > > would use > > a text clone. > > > > 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 -- Andrew Sullivan ajs@anvilwalrusden.com From WebMaster@Commerco.Net Wed Apr 24 13: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 07DDD21F91CA for ; Wed, 24 Apr 2013 13:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqiSjTdbPi88 for ; Wed, 24 Apr 2013 13:20:23 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1300621F91BC for ; Wed, 24 Apr 2013 13:20:23 -0700 (PDT) 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=v417GgvoTiIATtRy5BSLo9DEVHS4QQtdsOWiZw4/lKLDqyi/h1useMlfn4HKkD25Jlao2lVIsf0DisyWTeEswr6tlwEeydyX8CraxhHbjfozJJTisbUFr4FHtMvBMOho3Sh9Grqn0144GxgjpaE6u8gCwYiTxlhOO6sVAbL2wxc= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.6) with ESMTP (EHLO [10.240.241.49]); Wed, 24 Apr 2013 20:20:20 +0000 Message-ID: <51783E7D.4090100@Commerco.Net> Date: Wed, 24 Apr 2013 14:20:13 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <517839E6.6080403@Commerco.Net> <2815523.KcR0f6LIC4@scott-latitude-e6320> In-Reply-To: <2815523.KcR0f6LIC4@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: Scott Kitterman Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 20:20:24 -0000 On 4/24/2013 2:04 PM, Scott Kitterman wrote: > On Wednesday, April 24, 2013 02:00:38 PM Commerco WebMaster wrote: >> On 4/24/2013 1:25 PM, Murray S. Kucherawy wrote: >>> On Wed, Apr 24, 2013 at 12:04 PM, Scott Kitterman >> >>> > wrote: >>> Sounds reasonable. Would you propose modified text please? >>> >>> Replace Section 13.1 with: >>> >>> Per [RFC4408], ... (as you have it now until) ... [US-ASCII]. >>> >>> Studies have shown that RRTYPE 99 has not seen any substantial use, and >>> in fact its existence and mechanism defined in [RFC4408] has led to some >>> interoperability issues. Accordingly, its use is now obsolete, and new >>> implementations are not to use it. >>> >>> IANA is requested to update the Resource Record (RR) TYPEs registry to >>> indicate that this document is the reference document for that RRTYPE. >> >> Could we consider this? >> >> Studies have shown that DNS RRTYPE 99 has not enjoyed the substantial >> use seen by SPF TXT records for "v=spf1" deployment. In fact, its >> existence and mechanism as defined in [RFC4408] have led to some >> interoperability issues. Accordingly, its use for SPF "v=spf1" records >> is now obsolete, and any new implementations of SPF "v=spf1" are not to >> consider RRTYPE 99 in processing nor use RRTYPE 99 in SPF record deployment. >> >> IANA is requested to update the Resource Record (RR) TYPEs registry to >> indicate that this document is the reference document for that RRTYPE >> until such time any future SPF version may redefine its use. > > I think that raises more questions than it answers. I believe it's better as > msk proposed. > > Scott K Very well then, looks good as MSK proposed. Alan From superuser@gmail.com Wed Apr 24 13:25: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 70ED921F918C for ; Wed, 24 Apr 2013 13:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2qwa+s67Vtq for ; Wed, 24 Apr 2013 13:25:07 -0700 (PDT) Received: from mail-da0-x233.google.com (mail-da0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7676921F8E9A for ; Wed, 24 Apr 2013 13:25:07 -0700 (PDT) Received: by mail-da0-f51.google.com with SMTP id g27so28559dan.24 for ; Wed, 24 Apr 2013 13:25:01 -0700 (PDT) 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=mM9U6ChOxRzAOT8qGtf5MSxmaUxriuz7SbIdMZCtgL0=; b=fcCGoGSQ3GikC+C7AZS+CjAfRPsp21EDOPcyfi92urG/5Hp50Nx9UJzzfTUWW5ctLx coWkIR69XkbVWjMxyqGuaJdLWp/7iAHTu8Jky9jsZ2YoROlIsVnQsmQNKXKhFWKSOsuw Bs60uKHgjJ8Gey41vZPh2BDDnYuJe8kJqxwDL6t2Ymhwt9VZH0xA5NmpvVdqs2mgmGDS 2rZAbWiz50PSo7zTk4mHJf36qFb/jOoFKlpg5B6gMP2rsL2XnOraP8uTdmeFzuToVLb7 W1mQ90u8mWWXABPYDO4JcOkbTC7NIxYiuCdBisyvi1MeA3hGP1Cmz4KbCDC7zsKn/l94 LYyg== MIME-Version: 1.0 X-Received: by 10.68.134.36 with SMTP id ph4mr49224476pbb.181.1366835101094; Wed, 24 Apr 2013 13:25:01 -0700 (PDT) Received: by 10.66.234.40 with HTTP; Wed, 24 Apr 2013 13:25:00 -0700 (PDT) In-Reply-To: <20130424200517.GX16817@mx1.yitter.info> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1431349.C0e3qG0mtd@scott-latitude-e6320> <1936386.sgrkPvE9zZ@scott-latitude-e6320> <20130424200517.GX16817@mx1.yitter.info> Date: Wed, 24 Apr 2013 13:25:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=047d7b10d177aad95e04db21187f Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 20:25:08 -0000 --047d7b10d177aad95e04db21187f Content-Type: text/plain; charset=ISO-8859-1 I think we should point the reference in the registry to a document that makes it clear use is deprecated, since there's not a "status" column in the registry to do so there. On Wed, Apr 24, 2013 at 1:05 PM, Andrew Sullivan wrote: > In which case, we're not deprecating the RRTYPE, just deprecating its > use. That sounds perfectly reasonable to me. I don't know if the > registry even gets updated. > > A > > On Wed, Apr 24, 2013 at 11:34:47AM -0700, Murray S. Kucherawy wrote: > > Maybe it's enough to just update the DNS record type registry to point to > > the bis document as the defining document, wherein we already say "Don't > > use type 99 anymore". > > > > -MSK > > > > > > On Wed, Apr 24, 2013 at 11:20 AM, Scott Kitterman >wrote: > > > > > On Wednesday, April 24, 2013 11:14:51 AM Murray S. Kucherawy wrote: > > > > On Wed, Apr 24, 2013 at 11:08 AM, Scott Kitterman < > spf2@kitterman.com > > > >wrote: > > > > > The barriers to RR type assignment are different, but the barriers > to > > > RR > > > > > type > > > > > deployment (which in my opinion were more important for Type > 99/SPF) > > > are > > > > > still > > > > > real and substantial. > > > > > > > > Sure, but they're unchanged. > > > > > > > > I think the only reason not to fully obsolete type 99 would be if we > > > think > > > > SPF3 is: > > > > > > > > a) likely to ever appear; and > > > > > > > > b) likely to do a TXT clone again; and > > > > > > > > c) likely to be able to tolerate finding legacy SPFv1 records, which > > > > undoubtedly will linger. > > > > > > > > -MSK > > > > > > When we discussed this before, we concluded there was no benefit to > fully > > > obsoleting it since Type 99 still couldn't be reused for something > else. > > > > > > I've seen lots of "If we could do an incompatible update to SPF ..." > > > discussions over the last 9 years and I don't recall changing the > record > > > structure ever coming up. If there's a new version, I'm confident it > > > would use > > > a text clone. > > > > > > 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 > > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --047d7b10d177aad95e04db21187f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think we should point the reference in the registry to a= document that makes it clear use is deprecated, since there's not a &q= uot;status" column in the registry to do so there.


On Wed, Apr 24, 2013 at 1:05 PM, Andrew = Sullivan <ajs@anvilwalrusden.com> wrote:
In which case, we're not deprecating the RRTYPE, just deprecating its use. =A0That sounds perfectly reasonable to me. =A0I don't know if the<= br> registry even gets updated.

A

On Wed, Apr 24, 2013 at 11:34:47AM -0700, Murray S. Kucherawy wrote:
> Maybe it's enough to just update the DNS record type registry to p= oint to
> the bis document as the defining document, wherein we already say &quo= t;Don't
> use type 99 anymore".
>
> -MSK
>
>
> On Wed, Apr 24, 2013 at 11:20 AM, Scott Kitterman <spf2@kitterman.com>wrote:
>
> > On Wednesday, April 24, 2013 11:14:51 AM Murray S. Kucherawy wrot= e:
> > > On Wed, Apr 24, 2013 at 11:08 AM, Scott Kitterman <spf2@kitterman.com
> > >wrote:
> > > > The barriers to RR type assignment are different, but t= he barriers to
> > RR
> > > > type
> > > > deployment (which in my opinion were more important for= Type 99/SPF)
> > are
> > > > still
> > > > real and substantial.
> > >
> > > Sure, but they're unchanged.
> > >
> > > I think the only reason not to fully obsolete type 99 would = be if we
> > think
> > > SPF3 is:
> > >
> > > a) likely to ever appear; and
> > >
> > > b) likely to do a TXT clone again; and
> > >
> > > c) likely to be able to tolerate finding legacy SPFv1 record= s, which
> > > undoubtedly will linger.
> > >
> > > -MSK
> >
> > When we discussed this before, we concluded there was no benefit = to fully
> > obsoleting it since Type 99 still couldn't be reused for some= thing else.
> >
> > I've seen lots of "If we could do an incompatible update= to SPF ..."
> > discussions over the last 9 years and I don't recall changing= the record
> > structure ever coming up. =A0If there's a new version, I'= m confident it
> > would use
> > a text clone.
> >
> > 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


--
Andrew Sullivan
ajs@anvilwalrusden.com
_____________________= __________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis

--047d7b10d177aad95e04db21187f-- From sm@elandsys.com Wed Apr 24 13:31: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 8272C21F8D2B for ; Wed, 24 Apr 2013 13:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhIPhnwdg9LN for ; Wed, 24 Apr 2013 13:31:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 541C721F8C16 for ; Wed, 24 Apr 2013 13:31:47 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.221]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3OKVUex007514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Apr 2013 13:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366835502; bh=3KK/3OcH2W2wo9xlPZpriTJUCbo8TgDlPWP/BHopNCc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FyvQfFlmgAq7+i6N2u/2KF2IDs8PjSuRaJs4faD2xc1824YCl6sbOBrIu4/gkxPKa GpJKVTHIbK9NANyVI7d4M0fG63rboE/p4qAwHknMzWx9JuNK78dPvzCRH70/tXIz45 ziyZCGLmVMtQLnwrJoTc9nTggNNrlQ9tQTsYp8E8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366835502; i=@elandsys.com; bh=3KK/3OcH2W2wo9xlPZpriTJUCbo8TgDlPWP/BHopNCc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Vadu061dE9krpkWDgNY5Q8xlOufTW4odkBcYise1pw+1rwKRJM/Mfhtl+CwM3q718 sgM4KvZSUqhOoWLqdbsnKMvKSnYxnL1eJ7P7TCUsxFyXKo3K3gRpoehhFG+f7tpTn4 9p6uhqdk+yJCVDYt8GDhxzNCQ786sjwPa9XQUW00= Message-Id: <6.2.5.6.2.20130424131459.0ad2ad98@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 13:30:49 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1936386.sgrkPvE9zZ@scott-latitude-e6320> <2936220.a4Qo14FLj7@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 20:31:52 -0000 Hi Murray, At 12:25 24-04-2013, Murray S. Kucherawy wrote: >Replace Section 13.1 with: > >Per [RFC4408], ... (as you have it now until) ... [US-ASCII]. > >Studies have shown that RRTYPE 99 has not seen any substantial use, >and in fact its existence and mechanism defined in [RFC4408] has led >to some interoperability issues. Accordingly, its use is now >obsolete, and new implementations are not to use it. I'll nit-pick on this. This is already mentioned in RFC 6686. >IANA is requested to update the Resource Record (RR) TYPEs registry >to indicate that this document is the reference document for that RRTYPE. draft-ietf-spfbis-4408bis-14 is unfortunately not the document which defines the Resource Record Type. I suggest not doing this (process-wise) as I think it is better not to create legacy problems (in future). I suggest removing Section 13.1. As the process is at the moment unknown I suggest that anyone who would like a change to the DNS Parameters Registry to explain the process to do that. Please note that I'll defer to advice from Andrew Sullivan or Olafur Gudmundsson on this matter. Regards, S. Moonesamy From spf2@kitterman.com Wed Apr 24 13:35: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 10C3921F86F0 for ; Wed, 24 Apr 2013 13:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0Bm9IzP8oMN for ; Wed, 24 Apr 2013 13:35:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5D521F85ED for ; Wed, 24 Apr 2013 13:35:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BE15020E40FD; Wed, 24 Apr 2013 16:35:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366835721; bh=gQQ9HwEeJJjT0q1c16BIssi7newSVN4Ztl51dWaKmVk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mVj3SqcE4YiZo2ymw+O765l9R590/GLyQpOe/lqGvLTAwTo0j7DUc//J3WQ7B7SNe 237olsDeiDLfsXSWubsEoipo5/BIDsRUdFZg2p2CgBhWQcQzLc2wJpeTpCHpfCeS2g 3aoihQ3PKD8wxH3/JrBUr1qUVpgcBqVLnZ+gOaqw= 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 A481D20E4076; Wed, 24 Apr 2013 16:35:21 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 24 Apr 2013 16:35:20 -0400 Message-ID: <3687301.iFb2CzrX68@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130424131459.0ad2ad98@resistor.net> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <6.2.5.6.2.20130424131459.0ad2ad98@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] Obsoleting SPF RRTYPE 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, 24 Apr 2013 20:35:23 -0000 On Wednesday, April 24, 2013 01:30:49 PM S Moonesamy wrote: > Hi Murray, > > At 12:25 24-04-2013, Murray S. Kucherawy wrote: > >Replace Section 13.1 with: > > > >Per [RFC4408], ... (as you have it now until) ... [US-ASCII]. > > > >Studies have shown that RRTYPE 99 has not seen any substantial use, > >and in fact its existence and mechanism defined in [RFC4408] has led > >to some interoperability issues. Accordingly, its use is now > >obsolete, and new implementations are not to use it. > > I'll nit-pick on this. This is already mentioned in RFC 6686. > > >IANA is requested to update the Resource Record (RR) TYPEs registry > >to indicate that this document is the reference document for that RRTYPE. > > draft-ietf-spfbis-4408bis-14 is unfortunately not the document which > defines the Resource Record Type. I suggest not doing this > (process-wise) as I think it is better not to create legacy problems > (in future). > > I suggest removing Section 13.1. As the process is at the moment > unknown I suggest that anyone who would like a change to the DNS > Parameters Registry to explain the process to do that. Please note > that I'll defer to advice from Andrew Sullivan or Olafur Gudmundsson > on this matter. My intent then is to leave it the way Murray suggested until we get some advice then. Scott K From sm@elandsys.com Wed Apr 24 13:43: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 90A0421F86CA for ; Wed, 24 Apr 2013 13:43:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jprft8IMu-Ev for ; Wed, 24 Apr 2013 13:43:37 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FEE21F86C5 for ; Wed, 24 Apr 2013 13:43:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.221]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3OKhNG2012697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Apr 2013 13:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366836215; bh=lEcuhRj3KFA4qDKVOoMyC11SZtw9uaZPX7jUILqFNP4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oic7n2g8h0GB7AVG3QzdCjDNcCQd3923mz7yRhx8doDbYv+txxsij0ZKYxFxMVcfP QcdIgwfX46Y/X0Gw3RA9DUQIDRzFtoRXqEvazFYVpBAgxa7ZNjjThYYkGTSNEspgkN wd9VI08xoh11ZheWA1Gg7vPmnpx4RMaLsqx0M2bI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366836215; i=@elandsys.com; bh=lEcuhRj3KFA4qDKVOoMyC11SZtw9uaZPX7jUILqFNP4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uytJX9tUWS+kFIWMqonzEweBGYwAQeZnk3sCUeSIeXVvj+TUFIh48LM9LxhL2fr8o PJlH3EtME0OtnomhJBR/OO93z/clXoc0NutqYXrckv9iVwxo+NoVI5h0bYpQc+HBQV Dkt1EYjX8/V2NSZjZhKlIESAzHilzWLM1CsKD5jY= Message-Id: <6.2.5.6.2.20130424133358.0addabc8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 13:42:08 -0700 To: Philipp Kern From: S Moonesamy In-Reply-To: <20130424185005.GB8393@simplex.0x539.de> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1620648.vNPTWAe3vH@scott-latitude-e6320> <51780DCC.7020802@viagenie.ca> <3088486.LRMBpqBOZF@scott-latitude-e6320> <20130424185005.GB8393@simplex.0x539.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Simon Perreault Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 20:43:37 -0000 Hi Philipp, At 11:50 24-04-2013, Philipp Kern wrote: >Indeed one would assume that guidance wrt IPv4-mapped IPv6 exists somewhere >already. I looked into this issue some time back but I could not find anything of use. There is a short discussion at http://www.ietf.org/mail-archive/web/spfbis/current/msg03226.html In my opinion the text could be used for a DISCUSS. I do not know how to resolve that as SPFBIS WG participants have not provided any references to support the text. Regards, S. Moonesamy From sm@elandsys.com Wed Apr 24 14:02: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 4B22F21F8BE8 for ; Wed, 24 Apr 2013 14:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgWeqxm8eTOZ for ; Wed, 24 Apr 2013 14:02:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9937721F8A6B for ; Wed, 24 Apr 2013 14:02:58 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.221]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3OL2khW010276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Apr 2013 14:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366837377; bh=i+nPwktlKGC0UVliwxwj5pULMmHPO3f/fupiNFd+Y94=; h=Date:To:From:Subject:In-Reply-To:References; b=f2VRB5UC3rggIqvT3VzlMQMA2XcoTRjv75mYS5RvMcA8nyLRiidiFRWsxL1nqZx9c pgJKb5UKZw8qRyqR/QaN7sG1IMW8ZxUHg8OTdpz2kDk1WQxRogvl5GlXCYksqCv6zz FPUdC9G/vZ5bx9CpmEuSNdh7gteepTNP8ySPRKFc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366837377; i=@elandsys.com; bh=i+nPwktlKGC0UVliwxwj5pULMmHPO3f/fupiNFd+Y94=; h=Date:To:From:Subject:In-Reply-To:References; b=xJp0YmZlx25ud/Eatz8uXaqfW0aYD/LUDfE1knojbFR6aeG3S9db2sPuq0Xel6YOl 6yMWdYtxvurCqeMAS5y3NvoCvQJC0ncvL4y/7ru2SV/OENOvVbSVZVC56tfWH2rh78 ZlWGOfUhSE10vnY499rof3cteLheNQ/b42TEjpNk= Message-Id: <6.2.5.6.2.20130424140004.0bc4df90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 14:02:32 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <20130424002629.13505.qmail@joyce.lan> <1460222.e6VXMsC181@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 24 Apr 2013 21:02:59 -0000 Hello, As a reminder, the WGLC for draft-ietf-spfbis-4408bis-14 will close at 2014-04-24 00:00 UTC [1]. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03347.html From ajs@anvilwalrusden.com Wed Apr 24 14:15: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 BBA1D21F918C for ; Wed, 24 Apr 2013 14:15:49 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLalJ0a+NuV2 for ; Wed, 24 Apr 2013 14:15:49 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 31C7521F866E for ; Wed, 24 Apr 2013 14:15:49 -0700 (PDT) Received: from crankycanuck.ca (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 2EF248A031 for ; Wed, 24 Apr 2013 21:15:41 +0000 (UTC) Date: Wed, 24 Apr 2013 17:15:39 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130424211539.GE16817@crankycanuck.ca> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1936386.sgrkPvE9zZ@scott-latitude-e6320> <2936220.a4Qo14FLj7@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 21:15:49 -0000 No hat. Thinking about this some more, I don't think that will work. RFC 4008 actually has a somewhat poor definition of the RRTYPE, in that there isn't really a formal definition of the type (normally, you'd require a wire representation). That was fine in an experimental document. If we were to keep the type, then we would have needed to improve this part of the old document and then change the IANA registry. But since we were planning to obsolete the type, the effect was instead that we just needed the registry to be altered to deprecate the type and point at the new document. If we're now not actually going to update the registry to deprecate the type, then we need 4408bis to contain the actual formal definition of the SPF RR, and also still to tell people not to use it. That seems a little perverse. So I think this document needs to request IANA to update the "Reference" field of "Resource Record (RR) TYPEs" subregistry to point to this document, and to update the "Meaning" field to say "OBSOLETE - use TXT". This is roughly what the currend document does. I am not concerned about the loss of the RRTYPE. Yes, it would be nicer if there were an RR for this, but there isn't. On Wed, Apr 24, 2013 at 12:25:04PM -0700, Murray S. Kucherawy wrote: > On Wed, Apr 24, 2013 at 12:04 PM, Scott Kitterman wrote: > > > Sounds reasonable. Would you propose modified text please? > > > > Replace Section 13.1 with: > > Per [RFC4408], ... (as you have it now until) ... [US-ASCII]. > > Studies have shown that RRTYPE 99 has not seen any substantial use, and in > fact its existence and mechanism defined in [RFC4408] has led to some > interoperability issues. Accordingly, its use is now obsolete, and new > implementations are not to use it. > > IANA is requested to update the Resource Record (RR) TYPEs registry to > indicate that this document is the reference document for that RRTYPE. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Wed Apr 24 14:17: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 48B0721F9195 for ; Wed, 24 Apr 2013 14:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XMDMKwnMbWw for ; Wed, 24 Apr 2013 14:17:54 -0700 (PDT) Received: from mail-da0-x236.google.com (mail-da0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 330A321F918C for ; Wed, 24 Apr 2013 14:17:54 -0700 (PDT) Received: by mail-da0-f54.google.com with SMTP id s35so1072219dak.41 for ; Wed, 24 Apr 2013 14:17:53 -0700 (PDT) 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=V8oVmXQ/6n/DDCwa3+Jl5p6BlIFffCqxaPboGdP8vdY=; b=z45/73wFYf2wMxkdinoQdBVaG1TF3nnNPDbw2n3AKWkjgnOysXO8v5Ol0hv3rjq34i Oj7TfwnMHQprEP8S65Vbq26rm7225PMzztVidm6ggCza9R/e3zyD/tvOjqhw5ZyGVr1O 0O4cl+FhahSJS066n00NxsF/BN7eHF7D96VmXMB0AXjJp6TrBkUSRo+xCD497Uk++u6A dLmPnzHKDTPsm3KVrV+xYpfWLg9uJ0kV/9LrawKP19QWtctK2zaEsri/RvJGz5viB7VJ T6IpM6luzsBipibgLqoshqCkH8+idT+Pwr20/k+G8VgEwBeKEvzM66DRWQVYDcNBgszR qmsg== MIME-Version: 1.0 X-Received: by 10.68.36.197 with SMTP id s5mr49824695pbj.23.1366838273880; Wed, 24 Apr 2013 14:17:53 -0700 (PDT) Received: by 10.66.234.40 with HTTP; Wed, 24 Apr 2013 14:17:53 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130424131459.0ad2ad98@resistor.net> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1936386.sgrkPvE9zZ@scott-latitude-e6320> <2936220.a4Qo14FLj7@scott-latitude-e6320> <6.2.5.6.2.20130424131459.0ad2ad98@resistor.net> Date: Wed, 24 Apr 2013 14:17:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=bcaec520f1cdc7bbaf04db21d5bd Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 21:17:55 -0000 --bcaec520f1cdc7bbaf04db21d5bd Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 24, 2013 at 1:30 PM, S Moonesamy wrote: > At 12:25 24-04-2013, Murray S. Kucherawy wrote: > >> Replace Section 13.1 with: >> >> Per [RFC4408], ... (as you have it now until) ... [US-ASCII]. >> >> Studies have shown that RRTYPE 99 has not seen any substantial use, and >> in fact its existence and mechanism defined in [RFC4408] has led to some >> interoperability issues. Accordingly, its use is now obsolete, and new >> implementations are not to use it. >> > > I'll nit-pick on this. This is already mentioned in RFC 6686. If all we do is point the IANA entry to this draft, the reference is now ambiguous since the bis draft doesn't talk about type 99 at all except as a bullet point in Appendix C. A reader would be right to wonder what's going on here. We need to at least explain that it's a legacy allocation. We could rely on people following the IANA entry to the obsolete document and realizing what that means, but that seems like an incomplete solution to me. > IANA is requested to update the Resource Record (RR) TYPEs registry to >> indicate that this document is the reference document for that RRTYPE. >> > > draft-ietf-spfbis-4408bis-14 is unfortunately not the document which > defines the Resource Record Type. I suggest not doing this (process-wise) > as I think it is better not to create legacy problems (in future). > > I suggest removing Section 13.1. As the process is at the moment unknown > I suggest that anyone who would like a change to the DNS Parameters > Registry to explain the process to do that. Please note that I'll defer to > advice from Andrew Sullivan or Olafur Gudmundsson on this matter. > > I disagree. I suggest also asking Pete or Barry since this is a particularly strange procedural point, but also not so gnarly that it couldn't be fixed as late as IESG Evaluation. -MSK --bcaec520f1cdc7bbaf04db21d5bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2013 at 1:30 PM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
At 12:25 24-04-2013, Murray S. Kucherawy = wrote:
Replace Section 13.1 with:

Per [RFC4408], ... (as you have it now until) ... =A0[US-ASCII].

Studies have shown that RRTYPE 99 has not seen any substantial use, and in = fact its existence and mechanism defined in [RFC4408] has led to some inter= operability issues. =A0Accordingly, its use is now obsolete, and new implem= entations are not to use it.

I'll nit-pick on this. =A0This is already mentioned in RFC 6686.

If all we do is point the IANA entry to this draft, th= e reference is now ambiguous since the bis draft doesn't talk about typ= e 99 at all except as a bullet point in Appendix C.=A0 A reader would be ri= ght to wonder what's going on here.=A0 We need to at least explain that= it's a legacy allocation.

We could rely on people following the IANA entry to the obsolete docume= nt and realizing what that means, but that seems like an incomplete solutio= n to me.



IANA is requested to update the Resource Record (RR) TYPEs registry to indi= cate that this document is the reference document for that RRTYPE.

draft-ietf-spfbis-4408bis-14 is unfortunately not the document which define= s the Resource Record Type. =A0I suggest not doing this (process-wise) as I= think it is better not to create legacy problems (in future).

I suggest removing Section 13.1. =A0As the process is at the moment unknown= I suggest that anyone who would like a change to the DNS Parameters Regist= ry to explain the process to do that. =A0Please note that I'll defer to= advice from Andrew Sullivan or Olafur Gudmundsson on this matter.


I disagree.=A0 I suggest also asking P= ete or Barry since this is a particularly strange procedural point, but als= o not so gnarly that it couldn't be fixed as late as IESG Evaluation.
-MSK

--bcaec520f1cdc7bbaf04db21d5bd-- From superuser@gmail.com Wed Apr 24 14:19: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 7992421F85DC for ; Wed, 24 Apr 2013 14:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH9R+HIHskKs for ; Wed, 24 Apr 2013 14:19:33 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3C30121F85D7 for ; Wed, 24 Apr 2013 14:19:33 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id lj1so1429463pab.7 for ; Wed, 24 Apr 2013 14:19:33 -0700 (PDT) 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=ib0et9lSl07FGqH9dfsQrB5y+rYpnWgAvzsVMUg2uSg=; b=JI1DT7y3w2cZRXPMCohSptPpyOw1fzucQsTRF5EB/skmztcJsRboptTKvmNQnY9Bb0 YeVWCMgfPWaBpGI33BQfPqh8qkWd0iFVKUkUxNZw8ryuWsqF/5/gjRt6JdfgigMqMQJo qd0pU/EpKqDYC+oiFZqCIQoM81J00tzfxsG2HlvrL1Li02qDT6UXEWLugganMbuQe9ha IkVVbClS0ZMfRBJYuM0uz8m11lKV90v5ucH4pjXChT01VG7W/upR3J5W8SP9tMAB3q7C f7IGZvt6tnjnxIV5B/Nu6w0WvSQOqOQfq0dgvFmmgmgDj4mdpUAiOpAOoLVT0Vvet1YR hdOg== MIME-Version: 1.0 X-Received: by 10.66.245.75 with SMTP id xm11mr21444410pac.40.1366838372966; Wed, 24 Apr 2013 14:19:32 -0700 (PDT) Received: by 10.66.234.40 with HTTP; Wed, 24 Apr 2013 14:19:32 -0700 (PDT) In-Reply-To: <20130424211539.GE16817@crankycanuck.ca> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1936386.sgrkPvE9zZ@scott-latitude-e6320> <2936220.a4Qo14FLj7@scott-latitude-e6320> <20130424211539.GE16817@crankycanuck.ca> Date: Wed, 24 Apr 2013 14:19:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=047d7b15a3fbafa89304db21dbcf Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 21:19:34 -0000 --047d7b15a3fbafa89304db21dbcf Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 24, 2013 at 2:15 PM, Andrew Sullivan wrote: > No hat. > > Thinking about this some more, I don't think that will work. > > RFC 4008 actually has a somewhat poor definition of the RRTYPE, in > that there isn't really a formal definition of the type (normally, > you'd require a wire representation). That was fine in an > experimental document. > > If we were to keep the type, then we would have needed to improve this > part of the old document and then change the IANA registry. But since > we were planning to obsolete the type, the effect was instead that we > just needed the registry to be altered to deprecate the type and point > at the new document. > > If we're now not actually going to update the registry to deprecate > the type, then we need 4408bis to contain the actual formal definition > of the SPF RR, and also still to tell people not to use it. That > seems a little perverse. > > So I think this document needs to request IANA to update the > "Reference" field of "Resource Record (RR) TYPEs" subregistry to point > to this document, and to update the "Meaning" field to say "OBSOLETE - > use TXT". This is roughly what the currend document does. > > I am not concerned about the loss of the RRTYPE. Yes, it would be > nicer if there were an RR for this, but there isn't. > > I'm satisfied with that solution as well. -MSK --047d7b15a3fbafa89304db21dbcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 24, 2013 at 2:15 PM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
No hat.

Thinking about this some more, I don't think that will work.

RFC 4008 actually has a somewhat poor definition of the RRTYPE, in
that there isn't really a formal definition of the type (normally,
you'd require a wire representation). =A0That was fine in an
experimental document.

If we were to keep the type, then we would have needed to improve this
part of the old document and then change the IANA registry. =A0But since we were planning to obsolete the type, the effect was instead that we
just needed the registry to be altered to deprecate the type and point
at the new document.

If we're now not actually going to update the registry to deprecate
the type, then we need 4408bis to contain the actual formal definition
of the SPF RR, and also still to tell people not to use it. =A0That
seems a little perverse.

So I think this document needs to request IANA to update the
"Reference" field of "Resource Record (RR) TYPEs" subre= gistry to point
to this document, and to update the "Meaning" field to say "= OBSOLETE -
use TXT". =A0This is roughly what the currend document does.

I am not concerned about the loss of the RRTYPE. =A0Yes, it would be
nicer if there were an RR for this, but there isn't.

<= br>
I'm satisfied with that solution as well.

-MSK

--047d7b15a3fbafa89304db21dbcf-- From superuser@gmail.com Wed Apr 24 14:22: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 8AA4A21F85F4 for ; Wed, 24 Apr 2013 14:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.918, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4PjTBtNQeIL for ; Wed, 24 Apr 2013 14:22:17 -0700 (PDT) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4B021F8EF2 for ; Wed, 24 Apr 2013 14:22:13 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id 10so1386196pdi.15 for ; Wed, 24 Apr 2013 14:22:13 -0700 (PDT) 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=P3Ed4lI3rbHirCLRj+XCdqCFXj0Bb/1CupHTNd+wrQM=; b=JjKlIp5oTd+aRfV5MdNf13E1xWtZbA+AveMdrc3suAxh8ChHmQodxau1phxAZJOgoV yGMeJQB14isLR8+yv54GQjOlKy3Ei640vJuwCZfBZSIIIf8t5Er/GalgbNu9FzUUjLhA 4til/fJSbqbrMGBRUWEZ0iBAmk4yT8SOcLdmktOoaI32v42rTiefF2B3G5M1QhZkq8A0 TH2JUN+oKXwGsgdmuMlyR+jIEKQf/F3yV4ZyeRj/5bFmMPh7icqglJYxGZJA+iGtXPbL xoErmNpH0nXfSbuu838dTyyL8T+m8x44w37CKglRaucsxHKtSCb0mQGpxKSY4qYeIUFm Ib9A== MIME-Version: 1.0 X-Received: by 10.66.220.104 with SMTP id pv8mr21068784pac.72.1366838533003; Wed, 24 Apr 2013 14:22:13 -0700 (PDT) Received: by 10.66.234.40 with HTTP; Wed, 24 Apr 2013 14:22:12 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130424133358.0addabc8@resistor.net> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <1620648.vNPTWAe3vH@scott-latitude-e6320> <51780DCC.7020802@viagenie.ca> <3088486.LRMBpqBOZF@scott-latitude-e6320> <20130424185005.GB8393@simplex.0x539.de> <6.2.5.6.2.20130424133358.0addabc8@resistor.net> Date: Wed, 24 Apr 2013 14:22:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7b5d477839a7e304db21e50d Cc: "spfbis@ietf.org" , Simon Perreault , Philipp Kern Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 24 Apr 2013 21:22:20 -0000 --047d7b5d477839a7e304db21e50d Content-Type: text/plain; charset=ISO-8859-1 I think Scott's last suggestion is perfectly defensible. On Wed, Apr 24, 2013 at 1:42 PM, S Moonesamy wrote: > Hi Philipp, > > At 11:50 24-04-2013, Philipp Kern wrote: > >> Indeed one would assume that guidance wrt IPv4-mapped IPv6 exists >> somewhere >> already. >> > > I looked into this issue some time back but I could not find anything of > use. There is a short discussion at http://www.ietf.org/mail-** > archive/web/spfbis/current/**msg03226.html In my opinion the text could be used for a DISCUSS. I do not know how to > resolve that as SPFBIS WG participants have not provided any references to > support the text. > > Regards, > S. Moonesamy > ______________________________**_________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/**listinfo/spfbis > --047d7b5d477839a7e304db21e50d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think Scott's last suggestion is perfectly defensibl= e.


O= n Wed, Apr 24, 2013 at 1:42 PM, S Moonesamy <sm+ietf@elandsys.com= > wrote:
Hi Philipp,

At 11:50 24-04-2013, Philipp Kern wrote:
Indeed one would assume that guidance wrt IPv4-mapped IPv6 exists somewhere=
already.

I looked into this issue some time back but I could not find anything of us= e. =A0There is a short discussion at http://www.ietf.o= rg/mail-archive/web/spfbis/current/msg03226.html =A0In my= opinion the text could be used for a DISCUSS. =A0I do not know how to reso= lve that as SPFBIS WG participants have not provided any references to supp= ort the text.

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

--047d7b5d477839a7e304db21e50d-- From johnl@iecc.com Wed Apr 24 14:27: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 EBE4121F8A48 for ; Wed, 24 Apr 2013 14:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPoQpLxCrbYa for ; Wed, 24 Apr 2013 14:27:23 -0700 (PDT) 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 0C09521F896B for ; Wed, 24 Apr 2013 14:27:22 -0700 (PDT) Received: (qmail 35273 invoked from network); 24 Apr 2013 21:27:22 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 24 Apr 2013 21:27:22 -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; s=51784e3a.xn--hew.k1304; i=johnl@user.iecc.com; bh=sviO7n1WXwZfeRggbLvB+1yijDgWpxneQT1HeKBnxBE=; b=YxGZ6RQ8dVmFJRX+CCgUAktiI7bPElSHxIJ6dUxcMhpwOhS1/8+CUk8hI8xPFHJouhGWpeqnUX9luWn4FTmwUjruCRz17X6XSzYIBZORbftVZjfL/kWlwhM9a4HGviMvl8OorNxbQhzrQK7eGCkS9/EV4opbRVZHSKBohNfZBaI= 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; s=51784e3a.xn--hew.k1304; olt=johnl@user.iecc.com; bh=sviO7n1WXwZfeRggbLvB+1yijDgWpxneQT1HeKBnxBE=; b=tp3GkF1XJLF0hoR2BUg87FTacWsDQKnlPEZXJnpsleCk4VfWPCHVu8QNlYiOH8Ycp+sSWCS4f5RaYuyLKL4bZfDJ13Vi+gGgR4kCBaJ6wuZsxDpxdy0OMdKIkbHSTql21oWzi4OORzv2YT4N9+fgpjHboNWUSihfz7NZll+Le7g= Date: 24 Apr 2013 21:27:00 -0000 Message-ID: <20130424212700.35961.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20130424211539.GE16817@crankycanuck.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ajs@anvilwalrusden.com Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 21:27:24 -0000 >RFC 4408 actually has a somewhat poor definition of the RRTYPE, in >that there isn't really a formal definition of the type (normally, >you'd require a wire representation). That was fine in an >experimental document. It says in sec 3.1.1 that it's identical to TXT. Dunno how formal that is, but it was adequate for people to implement it and interoperate, give or take the bugs in the query algorithm. >So I think this document needs to request IANA to update the >"Reference" field of "Resource Record (RR) TYPEs" subregistry to point >to this document, and to update the "Meaning" field to say "OBSOLETE - >use TXT". This is roughly what the currend document does. Seems reasonable. R's, John From SRS0=xZs3m=OL==stuart@gathman.org Wed Apr 24 14:47: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 B242021F9027 for ; Wed, 24 Apr 2013 14:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si46Gn+ySM4Q for ; Wed, 24 Apr 2013 14:47:10 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD3E21F8F63 for ; Wed, 24 Apr 2013 14:47:09 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (PLAIN sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1366840045; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=5xtnyzlBx1Cz0aVBH9turoN4zP/yjhM/qb05RhDQpz4=; b=Ie0vVHcEAt4d1nlGtfb+NZJNhOFbA8mv0tymKUosY+chM+fWtMgjYc2MQsSq8mC2rcrpuF rUUv+btvAyMFowADI894UkXqV+mHOx6ZA1Z5FrH5SWAToIkdXPw0NyUvBDedM3CTiVWCD/ti 8XLXL6r42N+EeP1yhIM4GAYtGw6D4= Received: from silver.gathman.org ([IPv6:2001:470:8:809:c05c:2ad1:ab1f:efb6]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3OLlMaQ021008 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 24 Apr 2013 17:47:25 -0400 Message-ID: <517852DA.8060108@gathman.org> Date: Wed, 24 Apr 2013 17:47:06 -0400 From: Stuart Gathman Organization: BWI Corporation User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130424002629.13505.qmail@joyce.lan> <1460222.e6VXMsC181@scott-latitude-e6320> <6.2.5.6.2.20130424140004.0bc4df90@resistor.net> In-Reply-To: <6.2.5.6.2.20130424140004.0bc4df90@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 24 Apr 2013 21:47:10 -0000 On 04/24/2013 05:02 PM, S Moonesamy wrote: > As a reminder, the WGLC for draft-ietf-spfbis-4408bis-14 will close at > 2014-04-24 00:00 UTC [1]. I'm not sure we need another whole year! From sm@elandsys.com Wed Apr 24 14:53: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 554DB21F902A for ; Wed, 24 Apr 2013 14:53:02 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61X4NJTWS2qA for ; Wed, 24 Apr 2013 14:53:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2915421F9080 for ; Wed, 24 Apr 2013 14:52:59 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.221]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3OLqlbr010810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Apr 2013 14:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366840379; bh=ihFBHsPOSLpTTvZERJwXw1pRh3fAzcWycBGxqBzkc2k=; h=Date:To:From:Subject:In-Reply-To:References; b=qa2VOwPW49ZlWdGVSqJmNDXvdVHjALrQc8Gdm0QueOIPweo+jc3/B+uNj9Hn0jN6D 8YAkKjly0l3BuNDzI8Q4BJ6uzX2PEeAkfjIRtRsi05wEV3BWUjfiWO16GZHULoI/38 qmE0WeDQA3f6CImO5ZlEPB5u8rV+bZh+PGasEt+w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366840379; i=@elandsys.com; bh=ihFBHsPOSLpTTvZERJwXw1pRh3fAzcWycBGxqBzkc2k=; h=Date:To:From:Subject:In-Reply-To:References; b=ou6vEHgrucnysKQczBfwd+PwiECakOx97DmuOrcWf+DVajPAmghSweC9fELgtsEPK FtMDdvR679+srbttlylqtIJWhMRssHZnX2evDmnSAUH9lqYdb7hMxEXcD74XMpUCmN qvrwolw0WYRnHyvHCllzISdDCQNwiB/4BqCuukQs= Message-Id: <6.2.5.6.2.20130424144506.0ada3298@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 14:49:47 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20130424211539.GE16817@crankycanuck.ca> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1936386.sgrkPvE9zZ@scott-latitude-e6320> <2936220.a4Qo14FLj7@scott-latitude-e6320> <20130424211539.GE16817@crankycanuck.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 21:53:06 -0000 At 14:15 24-04-2013, Andrew Sullivan wrote: >So I think this document needs to request IANA to update the >"Reference" field of "Resource Record (RR) TYPEs" subregistry to point >to this document, and to update the "Meaning" field to say "OBSOLETE - >use TXT". This is roughly what the currend document does. Ok, here's the suggestion after discussing with Andrew and Pete: The entry in the Resource Record (RR) TYPEs sub-registry for SPF is updated; the "Meaning" will say "Obsolete, use TXT" and include a reference to RFC 4408 and the document. Regards, S. Moonesamy From sm@elandsys.com Wed Apr 24 14:53: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 9BA6221F9164 for ; Wed, 24 Apr 2013 14:53:26 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4Vi4+1wjZK0 for ; Wed, 24 Apr 2013 14:53:26 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB82A21F914C for ; Wed, 24 Apr 2013 14:53:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.221]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3OLqlbt010810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Apr 2013 14:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366840383; bh=Mg1XzwSRwkXO4U1QKQ9TbNbzB9c5IwxlA3PtNmO2lo8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wPhTmfW1+E7RRZ4vofk5vzGk+xl3UYBtjxiWlFqtbndt+tqqrzaGAWMZstoDnqQPm 0HUvT1eqywtL/fPXfN6tCYiBroq0OPJ/wanc5K4RN1HHoEf323HwFy5n28FOGmERFm 3OnDcqZIc9uhuQJVYZArrVg0zQ1Ul2zPquwdBMug= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366840383; i=@elandsys.com; bh=Mg1XzwSRwkXO4U1QKQ9TbNbzB9c5IwxlA3PtNmO2lo8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tix1wOrWf0riWYQ6/yw6tJOEfw+93ObMjsxzxYvOwt/OdFnkm79AovPbkT5fKz3Tk RQqmSSGL9ZdjLIkjsa0Fefw/h/2UB7n+oisUUJ1JxOvPdEpp8cZntBexVvGsqb8/TU roc9/NK7ITZ/1fLfuG7FeGHO4wmMd3rhDP/GZpNQ= Message-Id: <6.2.5.6.2.20130424145005.0b55c720@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 14:52:25 -0700 To: Stuart Gathman From: S Moonesamy In-Reply-To: <517852DA.8060108@gathman.org> References: <20130424002629.13505.qmail@joyce.lan> <1460222.e6VXMsC181@scott-latitude-e6320> <6.2.5.6.2.20130424140004.0bc4df90@resistor.net> <517852DA.8060108@gathman.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 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, 24 Apr 2013 21:53:26 -0000 Hi Stuart, At 14:47 24-04-2013, Stuart Gathman wrote: > I'm not sure we need another whole year! That should be April 24, 2013 00:00 UTC. Another whole year is too much for me. :-) Regards, S. Moonesamy From spf2@kitterman.com Wed Apr 24 14:55: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 4BCEB21F90AF for ; Wed, 24 Apr 2013 14:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn0GxQlL8JqH for ; Wed, 24 Apr 2013 14:55:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A8C7921F9080 for ; Wed, 24 Apr 2013 14:55:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 19F5120E40FD; Wed, 24 Apr 2013 17:55:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366840515; bh=QZgrPoDVdrwXY+RyXA6aFj7bx5dsucyaqZuyFm52MmE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eu9xeO1yZCNh/qQI4Dd5gY4HS0evxJA99IryTvRm5hj4n6umIsxiCqAoQuJLQBC1E X4bcMIdNKhkX07642XWCM8QDbCrx5AFHkg+WBbkfPs6208ib0jr7ZK2m/YmHivQ0uL pOmT/DD1ZUSWJ6NrJmSDdKChI4QMywhcmuJTEFOQ= 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 0400220E4076; Wed, 24 Apr 2013 17:55:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 24 Apr 2013 17:55:14 -0400 Message-ID: <1457193.1skIDydpWO@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130424144506.0ada3298@resistor.net> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130424211539.GE16817@crankycanuck.ca> <6.2.5.6.2.20130424144506.0ada3298@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] Obsoleting SPF RRTYPE 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, 24 Apr 2013 21:55:16 -0000 On Wednesday, April 24, 2013 02:49:47 PM S Moonesamy wrote: > At 14:15 24-04-2013, Andrew Sullivan wrote: > >So I think this document needs to request IANA to update the > >"Reference" field of "Resource Record (RR) TYPEs" subregistry to point > >to this document, and to update the "Meaning" field to say "OBSOLETE - > >use TXT". This is roughly what the currend document does. > > Ok, here's the suggestion after discussing with Andrew and Pete: > > The entry in the Resource Record (RR) TYPEs sub-registry for SPF is > updated; the "Meaning" will say "Obsolete, use TXT" and include a > reference to RFC 4408 and the document. Would you please provide the exact change you want me to apply? This discussion has had a lot of moving parts and I'd like to make sure I get it right. Scott K From sm@elandsys.com Wed Apr 24 15:31: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 82D6821F8D2B for ; Wed, 24 Apr 2013 15:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNY2IyJwcJXK for ; Wed, 24 Apr 2013 15:31:04 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAD121F8BE8 for ; Wed, 24 Apr 2013 15:31:04 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.221]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3OMUp8B002411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Apr 2013 15:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366842662; bh=zQhnNV6oTfWpjrX8V7MiK1swwjMAak53r5yQNOXQ2/Q=; h=Date:To:From:Subject:In-Reply-To:References; b=4Vi3Q6r5hwBTQezQan+SwiJFVLmsoJg1IU6Ox8bXShKyHBGcJsJ5R4wm0is1qu7U/ xHsth8VUPzGGdE0r+eTny5DlT/yrJ4/qHJvxdD4hqigLbDrdnnocg9i/n71RpU+ZJE l6CiUcw/GTXP3DAngcV0RTVR698jCtrjLr1Qm9pU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366842662; i=@elandsys.com; bh=zQhnNV6oTfWpjrX8V7MiK1swwjMAak53r5yQNOXQ2/Q=; h=Date:To:From:Subject:In-Reply-To:References; b=L8/u3Lq57FV/2x9t7ydKvyVmSFgfzmg6R4ZDi9HU523zvKjHkn20osnKSTb1DvOOo zqN2+QcKbHcFY4ZIMHyyVvUkkKeaby/e4w1ZkYIMB8gv/bRBoOd8jDnDYckg6aeTid kYw3Hu+FvJl8kJMe5h4/cfjSGBV9LvCGVHwJkh4I= Message-Id: <6.2.5.6.2.20130424151823.06586b98@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 15:29:11 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1457193.1skIDydpWO@scott-latitude-e6320> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130424211539.GE16817@crankycanuck.ca> <6.2.5.6.2.20130424144506.0ada3298@resistor.net> <1457193.1skIDydpWO@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 22:31:08 -0000 Hi Scott, At 14:55 24-04-2013, Scott Kitterman wrote: >Would you please provide the exact change you want me to apply? I suggest having the second paragraph of Section 13.1 as follows: IANA is requested to update the DNS Parameters sub-registry entry for the SPF RR TYPE with "(OBSOLETE - use TXT)" in the Meaning column and with "[RFC 4408][RFC XXXX]" in the References column. [Note to RFC Editor: Please update XXXX to this RFC number upon publication] Regards, S. Moonesamy From ajs@crankycanuck.ca Wed Apr 24 14:05: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 5BD1B21F8B60 for ; Wed, 24 Apr 2013 14:05:45 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwFWCtKuUCHE for ; Wed, 24 Apr 2013 14:05:44 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD3021F8B07 for ; Wed, 24 Apr 2013 14:05:44 -0700 (PDT) Received: from crankycanuck.ca (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 BC0CE8A031 for ; Wed, 24 Apr 2013 21:05:43 +0000 (UTC) Date: Wed, 24 Apr 2013 17:05:41 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130424210541.GB16817@crankycanuck.ca> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1936386.sgrkPvE9zZ@scott-latitude-e6320> <2936220.a4Qo14FLj7@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 24 Apr 2013 21:07:37 -0700 Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 24 Apr 2013 21:05:45 -0000 No hat. Thinking about this some more, I don't think that will work. RFC 4008 actually has a somewhat poor definition of the RRTYPE, in that there isn't really a formal definition of the type (normally, you'd require a wire representation). That was fine in an experimental document. If we were to keep the type, then we would have needed to improve this part of the old document and then change the IANA registry. But since we were planning to obsolete the type, the effect was instead that we just needed the registry to be altered to deprecate the type and point at the new document. If we're now not actually going to update the registry to deprecate the type, then we need 4408bis to contain the actual formal definition of the SPF RR, and also still to tell people not to use it. That seems a little perverse. So I think this document needs to request IANA to update the "Reference" field of "Resource Record (RR) TYPEs" subregistry to point to this document, and to update the "Meaning" field to say "OBSOLETE - use TXT". This is roughly what the currend document does. I am not concerned about the loss of the RRTYPE. Yes, it would be nicer if there were an RR for this, but there isn't. On Wed, Apr 24, 2013 at 12:25:04PM -0700, Murray S. Kucherawy wrote: > On Wed, Apr 24, 2013 at 12:04 PM, Scott Kitterman wrote: > > > Sounds reasonable. Would you propose modified text please? > > > > Replace Section 13.1 with: > > Per [RFC4408], ... (as you have it now until) ... [US-ASCII]. > > Studies have shown that RRTYPE 99 has not seen any substantial use, and in > fact its existence and mechanism defined in [RFC4408] has led to some > interoperability issues. Accordingly, its use is now obsolete, and new > implementations are not to use it. > > IANA is requested to update the Resource Record (RR) TYPEs registry to > indicate that this document is the reference document for that RRTYPE. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Andrew Sullivan ajs@crankycanuck.ca From drc@virtualized.org Wed Apr 24 17:12: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 19A0B21F8EF2; Wed, 24 Apr 2013 17:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt20y-psRfit; Wed, 24 Apr 2013 17:12:10 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5E721F8D29; Wed, 24 Apr 2013 17:12:09 -0700 (PDT) Received: from [10.0.1.4] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 0790A17166; Thu, 25 Apr 2013 00:12:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> Date: Wed, 24 Apr 2013 17:12:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Wed, 24 Apr 2013 21:07:44 -0700 Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 00:12:11 -0000 Hi, On Apr 23, 2013, at 3:03 PM, S Moonesamy wrote: > Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: >=20 > 'IANA is requested to add an annotation to the SPF RRTYPE saying > "(OBSOLETE - use TXT)" in the DNS Parameters registry.' >=20 > Is the annotation in the DNS Parameters registry correct? It is in keeping with past practice, e.g., see the notations for MD, MF, = A6, and the MAILA RRtypes at = http://www.iana.org/assignments/dns-parameters/dns-parameters.xml. I personally believe deprecating the SPF RR is the wrong way to go, but = I'm guessing that discussion has already been had. Regards, -drc From marka@isc.org Wed Apr 24 17:28: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 2EFDC21F902A; Wed, 24 Apr 2013 17:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QH3vPuWFtwja; Wed, 24 Apr 2013 17:28:58 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDC321F8CE9; Wed, 24 Apr 2013 17:28:58 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 85198C94B0; Thu, 25 Apr 2013 00:28:49 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366849738; bh=KwbHRjok2cIbiGh7i5h5xzGj8FmWwoiwj1z7CxPrz0Y=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Cm5sB1uQs5r3L3Iatn28pkQMvI7BhuvMjMkpIafYE5HfQ4zyDUfpyW0R2Tx/muAA5 EOvWRmjjdKJ1GT1JSeTDVbbAfFYOMqjSLWCOioOUOYsf9XRChNMEliV+wI/apejUxs moWCgc/s9hE2RsPeir9yD0gk10WgxvhyJhoUlm54= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 25 Apr 2013 00:28:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c864:9043:57a3:304b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 46C2B216C40; Thu, 25 Apr 2013 00:28:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2F41B32F308D; Thu, 25 Apr 2013 10:28:47 +1000 (EST) To: David Conrad From: Mark Andrews References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> In-reply-to: Your message of "Wed, 24 Apr 2013 17:12:07 -0700." <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> Date: Thu, 25 Apr 2013 10:28:47 +1000 Message-Id: <20130425002847.2F41B32F308D@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist X-Mailman-Approved-At: Wed, 24 Apr 2013 21:08:28 -0700 Cc: spfbis@ietf.org, S Moonesamy , dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 00:28:59 -0000 In message <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org>, David Conrad writes: > Hi, > > On Apr 23, 2013, at 3:03 PM, S Moonesamy wrote: > > Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: > > > > 'IANA is requested to add an annotation to the SPF RRTYPE saying > > "(OBSOLETE - use TXT)" in the DNS Parameters registry.' > > > > Is the annotation in the DNS Parameters registry correct? > > It is in keeping with past practice, e.g., see the notations for MD, MF, A6, > and the MAILA RRtypes at http://www.iana.org/assignments/dns-parameters/dns-p > arameters.xml. > > I personally believe deprecating the SPF RR is the wrong way to go, but I'm g > uessing that discussion has already been had. > > Regards, > -drc Personally, I agree with you. TXT to SPF transition was always going to be a slow transition. libspf2 took ages to come out but it is out now and looks for SPF records first. Waiting less than is single hardware deprecation cycle before stating that the transition is not working wasn't a good faith effort. The introduction of MX records to 10 or more years before you could reliably have MX only (no A records) domains. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@elandsys.com Wed Apr 24 21:55: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 1F7CD21F896D; Wed, 24 Apr 2013 21:55:51 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+UE8T37YJX7; Wed, 24 Apr 2013 21:55:50 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2C121F85C0; Wed, 24 Apr 2013 21:55:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.138.130]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3P4tWwq012233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Apr 2013 21:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366865745; bh=RIprv/oba+fo7x9pAwFihLodS/ddKWVZvYxlwMUB5oc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hxTdrvFuUWfAN18ZLtrg3ww1B3vFbN59zSE0m3yY8SjLxRH57SzC7zWbfQGpGd7Mc HCNx88PDaXgQsUK5avnnHVacMq2+MBr4WCu10DaaDHHKvUcK4l4hNBFc9xIC3wjAbQ EXHzc3Xus95tkqfaQlfSPN1tx1C8+L6KL8edyi1I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366865745; i=@elandsys.com; bh=RIprv/oba+fo7x9pAwFihLodS/ddKWVZvYxlwMUB5oc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0y7oMyJQD/XSR0ZYCx0HZ64H4NfG1IUBxWAmSO0URfJImCF+zpEUuTMqki6CpWPbj i6LEQ1j/MEyN/AyAoYCGwG78OLsOqd0TKVmYP2bAsz/Fo9mxwDKPfw6RP+y1Hzr1fs bMti2J4hb7+HZu3LPjIW08QDsy4BEvhRd+HXKl4s= Message-Id: <6.2.5.6.2.20130424211648.0a804468@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 21:42:03 -0700 To: David Conrad From: S Moonesamy In-Reply-To: <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 04:55:51 -0000 Hi David, At 17:12 24-04-2013, David Conrad wrote: >It is in keeping with past practice, e.g., see the notations for MD, >MF, A6, and the MAILA RRtypes at >http://www.iana.org/assignments/dns-parameters/dns-parameters.xml. Based on the current discussion a similar approach may be followed for the SPF RRTYPE. Please note that this is in my view a IANA Considerations (administrative) issue. >I personally believe deprecating the SPF RR is the wrong way to go, >but I'm guessing that discussion has already been had. Yes, the thread is at http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html The results of the discussion is documented in RFC 6686. Regards, S. Moonesamy From sm@elandsys.com Wed Apr 24 22:53: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 0C64E21F9367 for ; Wed, 24 Apr 2013 22:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAMMDqWr2hzE for ; Wed, 24 Apr 2013 22:53:19 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5010B21F8A80 for ; Wed, 24 Apr 2013 22:53:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.138.130]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3P5r5b5008830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Apr 2013 22:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366869197; bh=1ElEKhpcin9/5BotYljEvz9iC0JuqvohuIzWWHH+e9o=; h=Date:To:From:Subject; b=QwH8lKfjbRPTIgMU7bijVLNQlUmzK6ejl0P4iLaJWLT+QwBZ4pLrIV2h9NQftFoii 2EKscnDPAi+nqH7PsqCcdytkekb80VL/9wSRLouu1YsvSTMgt5GJKs1J2gvZqqPMdq fCbQR2Uqd3RaNM9rzQ6CygWeAQAPI/l6y0D10AJc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366869197; i=@elandsys.com; bh=1ElEKhpcin9/5BotYljEvz9iC0JuqvohuIzWWHH+e9o=; h=Date:To:From:Subject; b=cwS7R+VnMaC+AeXY5DBA3RsbpMyLg0thFpo68qLCImmP9wvcJeLpbPSzZmurdQ+5t pG8N9HmOuK0GXUgX6HvfdXcJ5+jW2c6f/bXTBg+0hW76+sgRh7rDPjuQ2i7R/t4MQ1 GgFdDeUIhQ/ExzvaEByPL5i0qSTCVUjVLQ+KIfZc= Message-Id: <6.2.5.6.2.20130424220713.0b9efed0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Apr 2013 22:52:22 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Summary of WGLC for draft-ietf-spfbis-4408bis-14 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, 25 Apr 2013 05:53:20 -0000 Hello, Here's a summary of the WGLC discussion for draft-ietf-spfbis-4408bis-14. The WGLC was quiet until the last day. There was some feedback from DNSEXT and 6MAN for one of the DNS and one of the IPv6 issues. Hector Santos posted two messages [1][2]. Mike commented about the ADMD in the Abstract and the "permerror" in Section 2.6.7 [3]. Tim Draegen posted some notes about Section 2.2 and 2.5 [4]. Alessandro Vesely posted a review [5]. I'll list the "Appendix H.2 should be merged into Section 8.4 " comment [6]. There is a thread about "fail: rejection is not explicitly described" [7]. Scott Kitterman mentioned that "550 reject is right in the fail definition" [8]. John Levine mentioned some parts of Section 2 in his review [9]. Stuart Gathman commented about "Fully parse record *first*" [10] (Section 4.6). I have to review the previous discussions about this issue. Murray S. Kucherawy submitted a review [11]. I'll consider it as not addressed yet. There wasn't any follow-up to the issues raised in my review [12]. I verified the IANA Considerations Section. The only IANA issue of significance is likely resolved [13]. Let me know if I missed any issue or if you consider an issue as not resolved in the next revision of draft-ietf-spfbis-4408bis. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03350.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg03351.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg03358.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg03362.html 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg03365.html 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg03386.html 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg03370.html 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg03375.html 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg03378.html 10. http://www.ietf.org/mail-archive/web/spfbis/current/msg03387.html 11. http://www.ietf.org/mail-archive/web/spfbis/current/msg03406.html 12. http://www.ietf.org/mail-archive/web/spfbis/current/msg03414.html 13. http://www.ietf.org/mail-archive/web/spfbis/current/msg03475.html From mansaxel@besserwisser.org Thu Apr 25 00:51: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 9CCCE21F8FCF; Thu, 25 Apr 2013 00:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1PvEUvUDWpz; Thu, 25 Apr 2013 00:51:51 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id 168BF21F8E6A; Thu, 25 Apr 2013 00:51:50 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 60CE39EF0; Thu, 25 Apr 2013 09:51:47 +0200 (CEST) Date: Thu, 25 Apr 2013 09:51:47 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: David Conrad Message-ID: <20130425075147.GN23770@besserwisser.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YuJye9aIuN0w6xGV" Content-Disposition: inline In-Reply-To: <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Thu, 25 Apr 2013 01:27:57 -0700 Cc: spfbis@ietf.org, S Moonesamy , dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 07:51:51 -0000 --YuJye9aIuN0w6xGV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] Obsoleting SPF RRTYPE Date: Wed, Apr 24, 2013 at 05:1= 2:07PM -0700 Quoting David Conrad (drc@virtualized.org): =20 > I personally believe deprecating the SPF RR is the wrong way to go, but I= 'm guessing that discussion has already been had. Overloading the TXT record has always been a Really Bad Idea. I'm with drc here. While the draft probably is formally proper, it advocates the worng decision and I cannot support it. OTOH, mixing up routing layer with application layer and gilding some IP addresses in favour of others is another Really Bad Idea; I'd rather throw the entire business of supposedly Good and Bad addresses out the window and start looking at the in-band data instead; ie. DKIM or similar. While removing SPF can be seen as in support of above, I'm pretty certain that it in practice just will continue as usual, in TXT records. Better=20 then that we get to keep TXT records for free-form data.=20 Regards,=20 --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I want you to organize my PASTRY trays ... my TEA-TINS are gleaming in formation like a ROW of DRUM MAJORETTES -- please don't be FURIOUS with me = -- --YuJye9aIuN0w6xGV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF44JMACgkQ02/pMZDM1cUlPgCgnlUDj/ZCIF/KPgurChMzpxqA kzwAoIizScdRC7Leb10Rd+zRkWKcJK0U =RvJI -----END PGP SIGNATURE----- --YuJye9aIuN0w6xGV-- From vesely@tana.it Thu Apr 25 04:15: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 CA98F21F9350 for ; Thu, 25 Apr 2013 04:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.359 X-Spam-Level: X-Spam-Status: No, score=-4.359 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvJLr58mRBtU for ; Thu, 25 Apr 2013 04:15:16 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C278321F84E2 for ; Thu, 25 Apr 2013 04:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366888514; bh=TNjrsdqBXjMiLuvDwfZJ3Esm7GwQUkhXZOa06NB/hKw=; l=3179; h=Date:From:To:References:In-Reply-To; b=gOzGxlf2q73xGpRNte28XX0ZyMXTjgDFzDGyvzTwVM7/FQl4R5fa9QCFhGJkwyvMR WbgCJLJpo88kZcamb0OGV9+bXHVzT6i+QKwjabEm3ziGYtTIQsmi90ZOoOdfZMA6wF QW1ybWwNMGKQYoGQC+EQpPB+h2mAGKU+TbeaPC/c= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 25 Apr 2013 13:15:14 +0200 id 00000000005DC035.0000000051791042.00001FA6 Message-ID: <51791042.9030800@tana.it> Date: Thu, 25 Apr 2013 13:15:14 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <51726641.7070606@tana.it> <51763F51.3020608@tana.it> <1478526.K9TjTEXC2I@scott-latitude-e6320> <5176B405.3010109@tana.it> <517796D9.9050303@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 25 Apr 2013 11:15:16 -0000 On Wed 24/Apr/2013 18:56:48 +0200 Murray S. Kucherawy wrote: > On Wed, Apr 24, 2013 at 1:24 AM, Alessandro Vesely wrote: > >> That the spec doesn't lend itself well to being used as a building >> block for other specs willing to refer to SPF results. > > DMARC, for example, hasn't found that to be the case. Nor has VBR, actually. We can pretend that SPF results are well defined, 'cause we know what we mean, and live with that loose cannon. >>> I would expect that's obvious from the result spec; >>> "smtp.mailfrom" means it evaluated the MAIL FROM command >>> parameter. >> >> Right, but since that parameter was null, the verifier synthesized a >> mailbox composed of the local-part "postmaster" and the "HELO" >> identity, as per Section 2.2. > > Such synthesis is meant for internal use by the SPF module only. Would it hurt to say so in Section 2.2? Better yet, we could entirely remove the sentence: When the reverse-path is null, _this document defines_ the "MAIL FROM" identity to be the mailbox composed of the local-part "postmaster" and the "HELO" identity (which might or might not have been checked separately before). In fact, Section 4.3 already says: If the has no local-part, substitute the string "postmaster" for the local-part. How come it has no local part? We don't need to do it twice. The former sentence is a "shortcut" to say that checking HELO is required when MAIL FROM is null. To wit, only an idiot can think that, irrespectively of whether the HELO identity had been checked separately before, he or she MUST --i.e., it is an absolute requirement of the specification to-- check the thereby defined "MAIL FROM" anew. Such an idiot will probably report that result as smtp.mailfrom. But why do we use a formal language if implementers will have to do what we mean rather than what we write? > If that value is exposed via A-R or some other method, then the > module is distributing false information. If we're going to > anything here, I think a sentence or two in Section 9 is the right > solution. IMHO it is more elaborate than it needs to. To spell "check HELO" is shorter and clearer than "define MAIL FROM to be the mailbox composed so and so". What am I missing? Furthermore, a result is exposed via A-R or some other /header/ method only in some cases, which depend on local policy, as I tried to express in the paragraph quoted below: >> Perhaps, 5451bis could word something clever in terms of check_host() >> so that other specs can refer to it instead of SPF. However, if a >> message is going to be rejected, the border MTA SHOULD issue an [SMTP] >> rejection response to the message rather than adding this header field >> with the failure result. Which brings us back to this thread's subject. > > But doesn't the bis draft already say that? Which bis? I copied the middle sentence from RFC 5451. It says there is no A-R in that case, hence one cannot refer to it. A third spec would have to refer to the SPF result that /would have been/ exposed in case the local policy had provided to accept the message... From hsantos@isdg.net Thu Apr 25 04:54: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 9F45121F890F for ; Thu, 25 Apr 2013 04:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.322 X-Spam-Level: X-Spam-Status: No, score=-102.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOvEGEA97FvG for ; Thu, 25 Apr 2013 04:54:11 -0700 (PDT) Received: from mail.santronics.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 36A9C21F869A for ; Thu, 25 Apr 2013 04:54:09 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3314; t=1366890835; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=3T9MRzh SlQOdeB8D5hQqLc7dvYU=; b=Mwr2eR9YU6o2ftsB7uxgc0xLHIwA2mKN0qStDJm iWOAYNogKQYG/gb19/B/QaSrbe67a5GeSFMmIwxqiiFygiiJn6v0xUHveeef5Px3 tYqyG6RrhF42Mt+5Cu7z0O1yb1EKsXwZ0F1jYm5dxITCs+EMZ7VRAetrN9NV5FpZ 8weI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 25 Apr 2013 07:53:55 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1389557504.615.4972; Thu, 25 Apr 2013 07:53:54 -0400 Message-ID: <51791903.3000402@isdg.net> Date: Thu, 25 Apr 2013 07:52:35 -0400 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: spfbis@ietf.org References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1936386.sgrkPvE9zZ@scott-latitude-e6320> <2936220.a4Qo14FLj7@scott-latitude-e6320> <20130424210541.GB16817@crankycanuck.ca> In-Reply-To: <20130424210541.GB16817@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 25 Apr 2013 11:54:17 -0000 Is this going to cause a lost of endorsement by the DNS community folks? I raised that question last year in SPFBIS and took it to IETF and DNSOP [1], and I got a good sense people still expected an RRTYPE rather than continue to use TXT for all these new DNS application protocols. I felt that the migration was occurring, but slow. There was evidence of clients using both. I know the folks who pushed other TXT solutions, like DKIM, believe that it was probably OK to stick with TXT for SPF as well. But that was the not the general feel I got from key DNS folks it was the preferred thing to do as more and more TXT solutions were being proposed. I only changed my own mind about the dedicated SPF type when I found out as out last year, Microsoft DNS servers still hadn't supported rfc3597 "Handling of Unknown DNS Resource Record (RR) Types" and that was the hope back in 2003 during MARID, that the passthru nature of servers was going to be available for queries. -- HLS [1] http://www.ietf.org/mail-archive/web/dnsop/current/msg09440.html On 4/24/2013 5:05 PM, Andrew Sullivan wrote: > No hat. > > Thinking about this some more, I don't think that will work. > > RFC 4008 actually has a somewhat poor definition of the RRTYPE, in > that there isn't really a formal definition of the type (normally, > you'd require a wire representation). That was fine in an > experimental document. > > If we were to keep the type, then we would have needed to improve this > part of the old document and then change the IANA registry. But since > we were planning to obsolete the type, the effect was instead that we > just needed the registry to be altered to deprecate the type and point > at the new document. > > If we're now not actually going to update the registry to deprecate > the type, then we need 4408bis to contain the actual formal definition > of the SPF RR, and also still to tell people not to use it. That > seems a little perverse. > > So I think this document needs to request IANA to update the > "Reference" field of "Resource Record (RR) TYPEs" subregistry to point > to this document, and to update the "Meaning" field to say "OBSOLETE - > use TXT". This is roughly what the currend document does. > > I am not concerned about the loss of the RRTYPE. Yes, it would be > nicer if there were an RR for this, but there isn't. > > On Wed, Apr 24, 2013 at 12:25:04PM -0700, Murray S. Kucherawy wrote: >> On Wed, Apr 24, 2013 at 12:04 PM, Scott Kitterman wrote: >> >>> Sounds reasonable. Would you propose modified text please? >>> >> >> Replace Section 13.1 with: >> >> Per [RFC4408], ... (as you have it now until) ... [US-ASCII]. >> >> Studies have shown that RRTYPE 99 has not seen any substantial use, and in >> fact its existence and mechanism defined in [RFC4408] has led to some >> interoperability issues. Accordingly, its use is now obsolete, and new >> implementations are not to use it. >> >> IANA is requested to update the Resource Record (RR) TYPEs registry to >> indicate that this document is the reference document for that RRTYPE. > >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis > > From doug.mtview@gmail.com Thu Apr 25 02: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 3FD6F21F8FF2; Thu, 25 Apr 2013 02:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvOD6XoY6MR5; Thu, 25 Apr 2013 02:15:30 -0700 (PDT) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4F90821F86CA; Thu, 25 Apr 2013 02:15:28 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id i38so2482328iae.20 for ; Thu, 25 Apr 2013 02:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=G8nBCqSXbLg2MXGb+nMQpLbL10NM3S+3zLZPVKC4Rp8=; b=qqohewri91PxM0MR0Md0lUlzXZst+APl7sYhAwqw1a+peRcyiChoAXfjDwE4Tnhp/u g8nvp9BInEKBnmH0awTojX9CXGZkJA1Op0EVllmuZlXdjMIPnjqU8qqnUTVrccROAxLz KevYwfePXogtcgJWyCe42zDW69KrsjEUPQFH5+qQCtMR35q1zuhM/fFXGird546Tqbyk HzmAI56D740u/5tskRbBHcaqvmqtyTM0aN5VVt/BIdmIcnM6om6P5cweTb++46shDqTl WaZINmAoGS3ZoaLLaBb35JjDTcOo7VENfWjltM5Ms4LbX2PWybnXZUSb/UAlz3SJLzoO l4vw== X-Received: by 10.50.128.16 with SMTP id nk16mr17840944igb.15.1366881327990; Thu, 25 Apr 2013 02:15:27 -0700 (PDT) Received: from ?IPv6:2601:9:4d80:89:21c1:6200:53b7:b135? ([2601:9:4d80:89:21c1:6200:53b7:b135]) by mx.google.com with ESMTPSA id p9sm33284379iga.7.2013.04.25.02.15.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 02:15:27 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: <20130425075147.GN23770@besserwisser.org> Date: Thu, 25 Apr 2013 02:15:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0991993C-F710-4617-9333-07996AB2C700@gmail.com> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> <20130425075147.GN23770@besserwisser.org> To: =?iso-8859-1?Q?M=E5ns_Nilsson?= X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Thu, 25 Apr 2013 06:54:20 -0700 Cc: spfbis@ietf.org, dnsext@ietf.org, David Conrad , S Moonesamy Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE and deprecate all macros 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, 25 Apr 2013 09:15:31 -0000 On Apr 25, 2013, at 12:51 AM, M=E5ns Nilsson = wrote: > Subject: Re: [dnsext] Obsoleting SPF RRTYPE Date: Wed, Apr 24, 2013 at = 05:12:07PM -0700 Quoting David Conrad (drc@virtualized.org): >=20 >> I personally believe deprecating the SPF RR is the wrong way to go, = but I'm guessing that discussion has already been had. >=20 > Overloading the TXT record has always been a Really Bad Idea. I'm with > drc here. While the draft probably is formally proper, it advocates = the > worng decision and I cannot support it. >=20 > OTOH, mixing up routing layer with application layer and gilding some > IP addresses in favour of others is another Really Bad Idea; I'd = rather > throw the entire business of supposedly Good and Bad addresses out the > window and start looking at the in-band data instead; ie. DKIM or = similar. >=20 > While removing SPF can be seen as in support of above, I'm pretty = certain > that it in practice just will continue as usual, in TXT records. = Better=20 > then that we get to keep TXT records for free-form data. Dear M=E5ns, Obsoleting SPF RR is not enough. All macros should be deprecated as = well. tools.ietf.org/html/rfc3123 predates this poorly conceived = scheme. SPF was poorly conceived starting out as 2KB TXT XML encoded resource = records in DNS where many expect direct use of TXT resource records = permits wildcard replication. This scheme also expects receivers to = combine email-address local-parts with SPF domains to query other = resource record sets. SPF may induce high query overheads flooding = caches with up to 100 transactions derived from email-address = local-parts that normally vary in spam campaigns to also support DDoS = attacks leveraging receiver's attempt to verify service authorizations. (10 mechanisms x 10 (PTRs or As or AAAAs)) Permitting PTRs can also = lead to connection resource exhaustion. The macro expansion can also = leverage DNS name compression to further increase network amplifications = against some unseen domain while spamming entirely different domains. The macro scheme was not intended to validate EHLOs or provide NDN = authorizations and inappropriately exposes aspects of message handling. = The review of SPF use also neglects whether major providers process = these macros, many whom assure they do not. Verifying the ELHO is = seldom supported, where authorization permits by bulk sender's to dodge = accountability. Without genuine domain authentication SMTP is not safe. = =20 A safe and effective alternative is needed to safely provide a basis for = assessing and reacting to abusive behavior. XMPP offers examples of = StartTLS used in a highly scalable fashion that can leverage OCSP and = self published DANE Certs needed to support IPv6. =20 Regards, Douglas Otis =20 From superuser@gmail.com Thu Apr 25 06:57: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 D961821F90A1 for ; Thu, 25 Apr 2013 06:57:58 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LlwxI-25-x2 for ; Thu, 25 Apr 2013 06:57:58 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D7F3921F9132 for ; Thu, 25 Apr 2013 06:57:55 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id z2so2792166wey.1 for ; Thu, 25 Apr 2013 06:57:55 -0700 (PDT) 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=/RukD+Zth+vVZvMGJr4kznwGUaJeu7Iyebx9Gua/oxo=; b=B2nwwFuVByxGeRd/TRcvkuIhstf2SiqQL5Q+0TFMhFc2zRyluZ4a9IyXUi3+UKvaUM bWKeludN9jOKyH2azy7KHQN+9/kiy9zjgNalD+Pplqd6jPjdtBOcEIceh61DHqXJ7GO8 GFMhORmEfUhJ5dy6mbzLmHU7a8VpT5yMSop78D3xKxgHQP6vpG/hbp1q+1JRSDXGw16I +zobUSYORzKOlzgsJd65csoYvHemThyG/+36394KmqeUeRo4/2L1PaFjrs2w1a6gc/LK WClOSpyqRpxEjdv+YfS8aGWWcGAMJF32bvJPSdaQLoJ3v+gGCX8uZJLU1WwW1A1rJUNA dyhQ== MIME-Version: 1.0 X-Received: by 10.180.80.3 with SMTP id n3mr52319175wix.20.1366898275005; Thu, 25 Apr 2013 06:57:55 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 25 Apr 2013 06:57:54 -0700 (PDT) In-Reply-To: <51791042.9030800@tana.it> References: <51726641.7070606@tana.it> <51763F51.3020608@tana.it> <1478526.K9TjTEXC2I@scott-latitude-e6320> <5176B405.3010109@tana.it> <517796D9.9050303@tana.it> <51791042.9030800@tana.it> Date: Thu, 25 Apr 2013 06:57:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d04182538203bbf04db2fceb3 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 25 Apr 2013 13:57:59 -0000 --f46d04182538203bbf04db2fceb3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 4:15 AM, Alessandro Vesely wrote: > On Wed 24/Apr/2013 18:56:48 +0200 Murray S. Kucherawy wrote: > > On Wed, Apr 24, 2013 at 1:24 AM, Alessandro Vesely > wrote: > > > >> That the spec doesn't lend itself well to being used as a building > >> block for other specs willing to refer to SPF results. > > > > DMARC, for example, hasn't found that to be the case. > > Nor has VBR, actually. We can pretend that SPF results are well > defined, 'cause we know what we mean, and live with that loose cannon. > We could also concede that in fact the results are well-defined enough for all practical uses, absent actual evidence to the contrary. > > >>> I would expect that's obvious from the result spec; > >>> "smtp.mailfrom" means it evaluated the MAIL FROM command > >>> parameter. > >> > >> Right, but since that parameter was null, the verifier synthesized a > >> mailbox composed of the local-part "postmaster" and the "HELO" > >> identity, as per Section 2.2. > > > > Such synthesis is meant for internal use by the SPF module only. > > Would it hurt to say so in Section 2.2? > No, but it doesn't appear to be necessary either. > > Better yet, we could entirely remove the sentence: > > When the reverse-path is null, _this document defines_ > the "MAIL FROM" identity to be the mailbox composed of > the local-part "postmaster" and the "HELO" identity > (which might or might not have been checked separately > before). > If you really want to make a change, I suggest changing "this document defines..." to "an SPF verifier acts as if..." or words to that effect. But I don't agree that it's necessary. > > In fact, Section 4.3 already says: > > If the has no local-part, substitute the string > "postmaster" for the local-part. > > How come it has no local part? We don't need to do it twice. The > former sentence is a "shortcut" to say that checking HELO is required > when MAIL FROM is null. > What about macro evaluation? > > If that value is exposed via A-R or some other method, then the > > module is distributing false information. If we're going to > > anything here, I think a sentence or two in Section 9 is the right > > solution. > > IMHO it is more elaborate than it needs to. To spell "check HELO" is > shorter and clearer than "define MAIL FROM to be the mailbox composed > so and so". What am I missing? > They're orthogonal issues. > > >> Perhaps, 5451bis could word something clever in terms of check_host() > >> so that other specs can refer to it instead of SPF. However, if a > >> message is going to be rejected, the border MTA SHOULD issue an [SMTP] > >> rejection response to the message rather than adding this header field > >> with the failure result. Which brings us back to this thread's subject. > > > > But doesn't the bis draft already say that? > > Which bis? I copied the middle sentence from RFC 5451. It says there > is no A-R in that case, hence one cannot refer to it. A third spec > would have to refer to the SPF result that /would have been/ exposed > in case the local policy had provided to accept the message... > The sentence "However, if a message is going to be rejected, the border MTA SHOULD issue an [SMTP] rejection response to the message rather than adding this header field with the failure result" is strange, because issuing an SMTP rejection response is the very definition of a rejection; adding a header field is not a rejection, it's a delivery. Section 8.4 of this document talks about what SMTP codes to return when rejecting a message. If that doesn't answer your question, then I remain completely confused by this thread. -MSK --f46d04182538203bbf04db2fceb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 4:15 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
On Wed 24/Apr/2013 18:56:4= 8 +0200 Murray S. Kucherawy wrote:
> On Wed, Apr 24, 2013 at 1:24 AM, Alessandro Vesely <vesely@tana.it> wrote:
>
>> That the spec doesn't lend itself well= to being used as a building
>> block for other specs willing to refer to SPF results.
>
> DMARC, for example, hasn't found that to be the case.

Nor has VBR, actually. =A0We can pretend that SPF results are well defined, 'cause we know what we mean, and live with that loose cannon.<= br>

We could also concede that in fact the = results are well-defined enough for all practical uses, absent actual evide= nce to the contrary.
=A0

>>> I would expect that's obvious from the result spec;
>>> "smtp.mailfrom" means it evaluated the MAIL FROM com= mand
>>> parameter.
>>
>> Right, but since that parameter was null, the verifier synthesized= a
>> mailbox composed of the local-part "postmaster" and the = "HELO"
>> identity, as per Section 2.2.
>
> Such synthesis is meant for internal use by the SPF module only.

Would it hurt to say so in Section 2.2?

No, but it doesn't appear to be necessary either.
=A0

Better yet, we could entirely remove the sentence:

=A0 =A0When the reverse-path is null, _this document defines_
=A0 =A0the "MAIL FROM" identity to be the mailbox composed of
=A0 =A0the local-part "postmaster" and the &quo= t;HELO" identity
=A0 =A0(which might or might not have been checked separately
=A0 =A0before).

If you really want to m= ake a change, I suggest changing "this document defines..." to &q= uot;an SPF verifier acts as if..." or words to that effect.=A0 But I d= on't agree that it's necessary.
=A0

In fact, Section 4.3 already says:

=A0 =A0If the <sender> has no local-part, substitute the string
=A0 =A0"postmaster" for the local-part.

How come it has no local part? =A0We don't need to do it twice. =A0The<= br> former sentence is a "shortcut" to say that checking HELO is requ= ired
when MAIL FROM is null.

What about macr= o evaluation?
=A0
> If that v= alue is exposed via A-R or some other method, then the
> module is distributing false information. =A0If we're going to
> anything here, I think a sentence or two in Section 9 is the right
> solution.

IMHO it is more elaborate than it needs to. =A0To spell "check H= ELO" is
shorter and clearer than "define MAIL FROM to be the mailbox composed<= br> so and so". =A0What am I missing?

= They're orthogonal issues.
=A0

>> Perhaps, 5451bis could word something clever in terms of check_hos= t()
>> so that other specs can refer to it instead of SPF. =A0However, if= a
>> message is going to be rejected, the border MTA SHOULD issue an [S= MTP]
>> rejection response to the message rather than adding this header f= ield
>> with the failure result. =A0Which brings us back to this thread= 9;s subject.
>
> But doesn't the bis draft already say that?

Which bis? =A0I copied the middle sentence from RFC 5451. =A0It says = there
is no A-R in that case, hence one cannot refer to it. =A0A third spec
would have to refer to the SPF result that /would have been/ exposed
in case the local policy had provided to accept the message...

The sentence "However, if a message is going t= o be rejected, the border MTA SHOULD issue an [SMTP] rejection response to = the message rather than adding this header field with the failure result&qu= ot; is strange, because issuing an SMTP rejection response is the very defi= nition of a rejection; adding a header field is not a rejection, it's a= delivery.

Section 8.4 of this document talks about what SMTP codes to = return when rejecting a message.

If that doesn't answ= er your question, then I remain completely confused by this thread.

-MSK
--f46d04182538203bbf04db2fceb3-- From spf2@kitterman.com Thu Apr 25 07:05: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 B258E21F93B1 for ; Thu, 25 Apr 2013 07:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6Sow+591CNh for ; Thu, 25 Apr 2013 07:05:06 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6A321F930E for ; Thu, 25 Apr 2013 07:05:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 52AB120E410F; Thu, 25 Apr 2013 10:05:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366898705; bh=Oslc8XUFMnyHCWW58wHlAS32AUHPF2b9mg38uQd+3fE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=j2flaURa7V4tu5kQ1kfPgGi2bGmwBUMNpz1IFddfDkvlQ0MBwQmnZifCoR8kz6nd7 nRLoElemkGRDHDeP/8irInBboqwC8wgJnDkRR9exX8ZDW2BsuGyD0DXqTdlU3yIIcO qwZPfhWUySivzkYYqTROD6BYBGKMEiIA5OaCEVmE= 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 3841420E40BE; Thu, 25 Apr 2013 10:05:04 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 25 Apr 2013 10:05:04 -0400 Message-ID: <1818071.XgB9D1drlR@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <51726641.7070606@tana.it> <51791042.9030800@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] New issue: 8.4. Fail: rejection is not described explicitly 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, 25 Apr 2013 14:05:06 -0000 On Thursday, April 25, 2013 06:57:54 AM Murray S. Kucherawy wrote: > > In fact, Section 4.3 already says: > > If the has no local-part, substitute the string > > "postmaster" for the local-part. > > > > How come it has no local part? We don't need to do it twice. The > > former sentence is a "shortcut" to say that checking HELO is required > > when MAIL FROM is null. > > What about macro evaluation? Macro evaluation is precisely why that's there. Scott K From superuser@gmail.com Thu Apr 25 08:30: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 3B8B721F93FF for ; Thu, 25 Apr 2013 08:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHK1IGGNhhTC for ; Thu, 25 Apr 2013 08:30:21 -0700 (PDT) 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 D097521F8D8E for ; Thu, 25 Apr 2013 08:30:15 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id r3so2761715wey.17 for ; Thu, 25 Apr 2013 08:30:15 -0700 (PDT) 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:content-type; bh=a1PYAPk6utRJgfiuovuwFuAR9Fn7RZvX4E8Go8Snxhk=; b=d4rrfbCAlUpGlP9ZCMmiCeY4s4bmIz+W/e55/K7MPBhaUkAnB8PiQzZEHOxBr7HiFF i8mCXn4XHNKDZSK8BQdMeCFIy2IW8JnFLJuTUOz/VeP2r0gTV05aCkSK9d3DHCsw6wKe JMXfFTMgckqoCbVTZIRuUNMY/k0EhOWuMQ2aKPFfuRpBtotC6ZLbDnItzQdspISULf3V 86bCf0szPPwoL4Z3feTJdqBDV9ISOaS/02UxVb2aF/eLVduodmEAHclciKKD0La0bp3V czH6ZZva8kNqqsslwFRhql9qivrxfAge/o9BsSRTeeS7ON1VyiW/76HicOpfU/q6qqWX 0LSQ== MIME-Version: 1.0 X-Received: by 10.180.84.162 with SMTP id a2mr8849209wiz.14.1366903814993; Thu, 25 Apr 2013 08:30:14 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 25 Apr 2013 08:30:14 -0700 (PDT) In-Reply-To: References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> Date: Thu, 25 Apr 2013 08:30:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=f46d0442719455bf9504db311865 Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 15:30:30 -0000 --f46d0442719455bf9504db311865 Content-Type: text/plain; charset=ISO-8859-1 Just a suggestion: Maybe we should include an appendix about this topic. In RFC6686 too the time to discuss the problem with the transition plan that was shoe-horned into RFC4408 at the last minute, so maybe here we should include a paragraph or two that acknowledges what the "right" way to do the DNS piece would've been, don't use this as an example for future work, etc. On Thu, Apr 25, 2013 at 8:05 AM, John R Levine wrote: > That does not imply I am quiet in other places, and I am as many others >> nervous over the implications. >> > > That we have a large and unaddressed problem of cruddy provisioning > software? I entirely agree. > > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > ______________________________**_________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/**listinfo/dnsext > --f46d0442719455bf9504db311865 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Just a suggestion: Maybe we should include an appendix abo= ut this topic.=A0 In RFC6686 too the time to discuss the problem with the t= ransition plan that was shoe-horned into RFC4408 at the last minute, so may= be here we should include a paragraph or two that acknowledges what the &qu= ot;right" way to do the DNS piece would've been, don't use thi= s as an example for future work, etc.


On Thu,= Apr 25, 2013 at 8:05 AM, John R Levine <johnl@taugh.com> wrot= e:
That does not imply I am quiet in other places, and I am as many others ner= vous over the implications.

That we have a large and unaddressed problem of cruddy provisioning softwar= e? =A0I entirely agree.


Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
dnsext mailing list
dnsext@ietf.org = https://www.ietf.org/mailman/listinfo/dnsext

--f46d0442719455bf9504db311865-- From hsantos@isdg.net Thu Apr 25 08:32: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 0AD0821F941D for ; Thu, 25 Apr 2013 08:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMfkoNFxTcTo for ; Thu, 25 Apr 2013 08:32:02 -0700 (PDT) Received: from listserv.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D9B4621F93FF for ; Thu, 25 Apr 2013 08:31:58 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4295; t=1366903915; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=zbm6OHs Ajo4QRuOcH4B9lywSw4w=; b=ZOGEy7Vp5OgMiv6OarnM8UBSxPChtPybGmy1l+N dlTyoZcu9kRC2sYO1tALm/xyEIWctTQSFhZhsWwSlGiAOTIEjrYTkkZtaaPWUm5V kXTAkYGHnombOIOKiJWCfJ1lAH5FXA4Pm2oiwZqvo7OXeIV/xfS5S83fZiAI5+gP tE8w= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 25 Apr 2013 11:31:55 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1402637189.615.5052; Thu, 25 Apr 2013 11:31:54 -0400 Message-ID: <51794C1B.8010505@isdg.net> Date: Thu, 25 Apr 2013 11:30:35 -0400 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: spfbis@ietf.org References: <51726641.7070606@tana.it> <51763F51.3020608@tana.it> <1478526.K9TjTEXC2I@scott-latitude-e6320> <5176B405.3010109@tana.it> <517796D9.9050303@tana.it> <51791042.9030800@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 25 Apr 2013 15:32:08 -0000 On 4/25/2013 9:57 AM, Murray S. Kucherawy wrote: > > If that doesn't answer your question, then I remain completely confused by > this thread. > Confusion is exactly my concern with this BIS can create for new implementators and operators on the FAIL policy. I know it is hard for the long time opponents of this SPF policy to get, but rejection was the very essence and intent of the SPF FAIL policy. The SENDER-ID/SUBMITTER/PRA integrated SPF protocols is proof of that intent when all this was developed during MARID. I know we don't wish to rehash this, but it is what it is. You can not eliminate these expensive design considerations that took place. You can not ignore the integration efforts performed by original adopters of all the early LMAP-like experimental protocols, including SPF, CALLER-ID which morphed to SENDER-ID/SUBMITTER/PRA. The Sender-ID/SPF integrated framework has clear normalized language: If these tests indicate that the connecting SMTP client is not authorized to transmit e-mail messages on behalf of the SUBMITTER domain, the receiving SMTP server SHOULD reject the message and when rejecting MUST use "550 5.7.1 Submitter not allowed." If the receiving SMTP server allows the connecting SMTP client to transmit message data, then the server SHOULD determine the purported responsible address of the message by examining the RFC 2822 message headers as described in [PRA]. If this purported responsible address does not match the address appearing in the SUBMITTER parameter, the receiving SMTP server MUST reject the message and when rejecting MUST use "550 5.7.1 Submitter does not match header." If no purported responsible address is found according to the procedure defined in [PRA], the SMTP server SHOULD reject the message and when rejecting MUST use "554 5.7.7 Cannot verify submitter address." It would be totally strange for someone to suggest that full, total complete SMTP + Addons integrators will program a two paths reject and Accept logic that would be different for a SPF fail message: FAIL via MAIL FROM domain --> ACCEPT (plus expected Separation) FAIL via SUBMITTER/PRA domain --> REJECT My key point as always stated, FAIL (-ALL) is a special condition that really SHOULD NOT have ambiguity behind it. IMV, it never did until SPF BIS and even if there are systems that claims SPF support but still accept the message, I pointed out that it must be a separation otherwise we have a clear security issue (loophole) if a system does not separate it. Fortunately, SPFBIS does cover this security condition, but don't you find that strange that a SECURITY alert is not part of the natural SPF protocol logic and for this specific FAIL case, a reject is done. I would like to see the FAIL functional description to be streamlined and reduced. Right now, BIS makes all sound like there are other ideas that SHOULD be used/coupled with SPF and that includes for fail results. If true, what is that? If SPFBIS can not specifically spell out that extra component is, then it SHOULD still to the basics and be very explicit on how a receiver should handle a SPF fail as to not reduce the payoff and expected powerful spoof protection for DOMAINS publishing a strong and exclusive -ALL mail network policy. There should be two clear protocol logical paths described that is possible for a SPF failed transaction: FAIL->REJECT FAIL->ACCEPT+SEPARATION What SHOULD NOT be deployed is a: FAIL->ACCEPT+REPORT with a reliance on MUA or agent outside the backend or any other MFA (Mail Filtering Agent) unless it is 100% described and existing in the market place to be used by receivers. The power of SPF FAIL is that it doesn't really need anything else. We have seen a 20% effectiveness of SPF rejections on our system. To do anything else, in my view, the receiver is not SPF compliant. I should note, for implementators that currently REJECT and which to consider the SPFBIS relaxtion to offer an ACCEPT, it would an expensive design change to offer this deployment option. As a side note, I don't think SPFBIS has enough Reporting examples. It should have an example and description of all possible SPF results. -- HLS From spf2@kitterman.com Thu Apr 25 08: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 0375821F95F9 for ; Thu, 25 Apr 2013 08:38:07 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZebeNN9COafH for ; Thu, 25 Apr 2013 08:38:03 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0846521F9436 for ; Thu, 25 Apr 2013 08:38:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DF4A220E410F; Thu, 25 Apr 2013 11:37:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366904282; bh=tOFb8Kqkh5qXhEjq8zQ17L/Rfe+eCYRoYwBZdvqiU9A=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KfdRmXIj11a3EQwof5Vv9a2ZEScurenX9SHLq/EsigWkOt8WQyyXpbBqO32N1i7WY QXuY/Kp8MdoFEIScr4pnTyOxoGg9E0r727pVYDkcFzh25t5s1Yk+okkLSidXOFqY56 y6NTggmR9viwRqg/vet/yabUcPT9KcAMzgxm4TuY= 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 C361A20E40BE; Thu, 25 Apr 2013 11:37:51 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 25 Apr 2013 11:37:50 -0400 Message-ID: <2711949.2NXGGSvfFZ@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <51794C1B.8010505@isdg.net> References: <51726641.7070606@tana.it> <51794C1B.8010505@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 25 Apr 2013 15:38:07 -0000 On Thursday, April 25, 2013 11:30:35 AM Hector Santos wrote: > On 4/25/2013 9:57 AM, Murray S. Kucherawy wrote: > > If that doesn't answer your question, then I remain completely confused by > > this thread. > > Confusion is exactly my concern with this BIS can create for new > implementators and operators on the FAIL policy. I know it is hard for > the long time opponents of this SPF policy to get, but rejection was the > very essence and intent of the SPF FAIL policy. The > SENDER-ID/SUBMITTER/PRA integrated SPF protocols is proof of that intent > when all this was developed during MARID. I know we don't wish to rehash > this, but it is what it is. You can not eliminate these expensive > design considerations that took place. You can not ignore the > integration efforts performed by original adopters of all the early > LMAP-like experimental protocols, including SPF, CALLER-ID which morphed > to SENDER-ID/SUBMITTER/PRA. I think it's reasonably safe to say I don't fall into the category of "long time opponents of this SPF policy" and I don't understand your objections either. > The Sender-ID/SPF integrated framework has clear normalized language: > > If these tests indicate that the connecting SMTP client is not > authorized to transmit e-mail messages on behalf of the SUBMITTER > domain, the receiving SMTP server SHOULD reject the message and when > rejecting MUST use "550 5.7.1 Submitter not allowed." > > If the receiving SMTP server allows the connecting SMTP client to > transmit message data, then the server SHOULD determine the purported > responsible address of the message by examining the RFC 2822 message > headers as described in [PRA]. If this purported responsible address > does not match the address appearing in the SUBMITTER parameter, the > receiving SMTP server MUST reject the message and when rejecting MUST > use "550 5.7.1 Submitter does not match header." > > If no purported responsible address is found according to the > procedure defined in [PRA], the SMTP server SHOULD reject the message > and when rejecting MUST use "554 5.7.7 Cannot verify submitter > address." What document are you quoting from here? > It would be totally strange for someone to suggest that full, total > complete SMTP + Addons integrators will program a two paths reject and > Accept logic that would be different for a SPF fail message: > > FAIL via MAIL FROM domain --> ACCEPT (plus expected Separation) > FAIL via SUBMITTER/PRA domain --> REJECT > > My key point as always stated, FAIL (-ALL) is a special condition that > really SHOULD NOT have ambiguity behind it. IMV, it never did until SPF > BIS and even if there are systems that claims SPF support but still > accept the message, I pointed out that it must be a separation otherwise > we have a clear security issue (loophole) if a system does not separate > it. Fortunately, SPFBIS does cover this security condition, but don't > you find that strange that a SECURITY alert is not part of the natural > SPF protocol logic and for this specific FAIL case, a reject is done. > > I would like to see the FAIL functional description to be streamlined > and reduced. > > Right now, BIS makes all sound like there are other ideas that SHOULD be > used/coupled with SPF and that includes for fail results. If true, what > is that? If SPFBIS can not specifically spell out that extra component > is, then it SHOULD still to the basics and be very explicit on how a > receiver should handle a SPF fail as to not reduce the payoff and > expected powerful spoof protection for DOMAINS publishing a strong and > exclusive -ALL mail network policy. > > There should be two clear protocol logical paths described that is > possible for a SPF failed transaction: > > FAIL->REJECT > FAIL->ACCEPT+SEPARATION > > What SHOULD NOT be deployed is a: > > FAIL->ACCEPT+REPORT > > with a reliance on MUA or agent outside the backend or any other MFA > (Mail Filtering Agent) unless it is 100% described and existing in the > market place to be used by receivers. The power of SPF FAIL is that it > doesn't really need anything else. We have seen a 20% effectiveness of > SPF rejections on our system. > > To do anything else, in my view, the receiver is not SPF compliant. > > I should note, for implementators that currently REJECT and which to > consider the SPFBIS relaxtion to offer an ACCEPT, it would an expensive > design change to offer this deployment option. There's nothing in 4408bis that says you HAVE to change anything about receiver policy if you don't want to. > As a side note, I don't think SPFBIS has enough Reporting examples. It > should have an example and description of all possible SPF results. Provide text and I'll see about including them. From spf2@kitterman.com Thu Apr 25 08:41: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 B11DE21F9605 for ; Thu, 25 Apr 2013 08:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts0ULYUnxKXQ for ; Thu, 25 Apr 2013 08:41:34 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F1EA221F9604 for ; Thu, 25 Apr 2013 08:41:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7CA5920E410F; Thu, 25 Apr 2013 11:41:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366904493; bh=/KB1oLPRtc9GYzS8RFt+FafRlEyXicXclLZT2PDaquA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Mu/gHyT0hRbUGC8eSbIxaSMghQ3CjUdkwjZZ6foeBrBrs8jjZsvMnrtu4+AVAEsWU vUHeNSz3oFLXUGt42o8YVvPjsILxVDpM2qgeQiOZDuXXZNkI81C8vRMhCJfWtOtPVB G9NUHFLXaB7k9D0KXvsLzOcYiVavAsxUQJO4AHuU= 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 621F620E40BE; Thu, 25 Apr 2013 11:41:33 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 25 Apr 2013 11:41:32 -0400 Message-ID: <5494784.pN4EEqLaH4@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <20130425013317.36729.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] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 15:41:34 -0000 The barriers to deployment of new RR Types that are outside of the IETF/IANA processes haven't changed much since 2005. I think the lesson ought to be that until that's changed it's pretty pointless to try and assign new RR Types for new functions (note that other services such as DKIM that came after SPF have used TXT and not even attempted a new RR Type). I think the lesson has been learned and we don't need an appendix about what other working groups in the future ought to do. Scott K On Thursday, April 25, 2013 08:30:14 AM Murray S. Kucherawy wrote: > Just a suggestion: Maybe we should include an appendix about this topic. > In RFC6686 too the time to discuss the problem with the transition plan > that was shoe-horned into RFC4408 at the last minute, so maybe here we > should include a paragraph or two that acknowledges what the "right" way to > do the DNS piece would've been, don't use this as an example for future > work, etc. > > On Thu, Apr 25, 2013 at 8:05 AM, John R Levine wrote: > > That does not imply I am quiet in other places, and I am as many others > > > >> nervous over the implications. > > > > That we have a large and unaddressed problem of cruddy provisioning > > software? I entirely agree. From mansaxel@besserwisser.org Thu Apr 25 08:42: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 C1F7021F9605; Thu, 25 Apr 2013 08:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB5DlEYBdBCR; Thu, 25 Apr 2013 08:42:37 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id 38BA121F9604; Thu, 25 Apr 2013 08:42:36 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 6522A9EF0; Thu, 25 Apr 2013 17:42:35 +0200 (CEST) Date: Thu, 25 Apr 2013 17:42:35 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Patrik =?utf-8?B?RsOkbHRzdHLDtm0=?= Message-ID: <20130425154235.GP23770@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftQmbtOmUf2cr8rB" Content-Disposition: inline In-Reply-To: <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: spfbis@ietf.org, John R Levine , "dnsext@ietf.org Group" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 15:42:37 -0000 --ftQmbtOmUf2cr8rB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] Obsoleting SPF RRTYPE Date: Thu, Apr 25, 2013 at 05:0= 3:55PM +0200 Quoting Patrik F=C3=A4ltstr=C3=B6m (paf@frobbit.se): >=20 > On 25 apr 2013, at 16:44, John R Levine wrote: >=20 > > In any event, the SPF draft is in WGLC. Feel free to read the extensiv= e discussion in the list archives and let them know how you feel. >=20 > They know how i feel. We in IETF do believe in rough consensus. I am this= time on the rough side. >=20 > That does not imply I am quiet in other places, and I am as many others n= ervous over the implications. This is a slippery slope. One record overload is not bad, but it sort of opens the floodgates for systematic overloading. DNSEXT and DNSOP certainly need to get involved; because this is way bigger than just SPF. And IMNSHO spfbis is out of scope prescribing TXT records, just because of this contagiousness. For the record: I think that the spfbis draft is unfit for publication as RFC unless TXT records are deprectaed as only carrier of data. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 =2E.. I want FORTY-TWO TRYNEL FLOATATION SYSTEMS installed within SIX AND A HALF HOURS!!! --ftQmbtOmUf2cr8rB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF5TusACgkQ02/pMZDM1cUQggCfaxOyZqwStzExMXJIhjfUpum8 u08AnRH+iYj934pT7mmbD1y2g/IV6ZzF =tXWw -----END PGP SIGNATURE----- --ftQmbtOmUf2cr8rB-- From hsantos@isdg.net Thu Apr 25 08:59: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 8A66F21F8766 for ; Thu, 25 Apr 2013 08:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.94 X-Spam-Level: X-Spam-Status: No, score=-101.94 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YdTQCee2JzD for ; Thu, 25 Apr 2013 08:59:36 -0700 (PDT) Received: from ftp.catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E3A9B21F873D for ; Thu, 25 Apr 2013 08:59:35 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2214; t=1366905561; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=ACeGkwL kxFa21rkN51PkINaL400=; b=u5mqa3zjl198tN8GvAocNKFG+sgk/6zwARV8+Z2 yP90vYviwyWcVBEXBF8rSgaJm1DxjkhxsRwnzJHyxkouRRbldIKIdjtAAcNMWEq6 Z4AVgDk8e8Mr/tdQfwyJpeCMAFbwTfvaT35XXLFTchngk/AViHxn1wUWMOZDT/S3 ApkQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 25 Apr 2013 11:59:21 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1404282438.615.3116; Thu, 25 Apr 2013 11:59:19 -0400 Message-ID: <51795288.8050605@isdg.net> Date: Thu, 25 Apr 2013 11:58:00 -0400 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: spfbis@ietf.org References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <264F7B0D-C3FC-4C7C-A4D8-AF180DEC331F@virtualized.org> <6.2.5.6.2.20130424211648.0a804468@elandnews.com> In-Reply-To: <6.2.5.6.2.20130424211648.0a804468@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 15:59:37 -0000 On 4/25/2013 12:42 AM, S Moonesamy wrote: > Hi David, > At 17:12 24-04-2013, David Conrad wrote: >> It is in keeping with past practice, e.g., see the notations for MD, >> MF, A6, and the MAILA RRtypes at >> http://www.iana.org/assignments/dns-parameters/dns-parameters.xml. > > Based on the current discussion a similar approach may be followed for > the SPF RRTYPE. Please note that this is in my view a IANA > Considerations (administrative) issue. > >> I personally believe deprecating the SPF RR is the wrong way to go, >> but I'm guessing that discussion has already been had. > > Yes, the thread is at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html The > results of the discussion is documented in RFC 6686. FYI, that msg reference was Feb, 2012. I don't recall it all, but I sensed that many in the DNS community believed in a status quo design choice - use RR TYPE and give the migration for unknown type processing by DNS servers more time. I don't know if RFC 6686 properly reflected that idea or not. My position was one of surprise when there was reports of clients actually doing SPF RRTYPE query as described in 4408. However, the problem was still the same one, the DNS servers still did not propagate unknown types (follow rfc3597 "Handling of Unknown DNS Resource Record (RR) Types"). To my disappointment, now even Microsoft DNS servers v5.0 did not support rfc3597 10 years later! That would make it nearly impossible to work well. The solution to this problem was discussed here: [DNSOP] Batch Multiple Query Packet http://www.ietf.org/mail-archive/web/dnsop/current/msg09440.html I believe SPFBIS should continue supporting its special "registered" RR type and then relax the REQUIREMENT to use it in BIS and keep it open ended for developers to watch development of future Multiple Query packet designs. As you will note in the above thread, the MX record was a similar introduction. But the all DNS servers on all platforms quickly supported that so it wasn't an WASTE issue. I still find it surprising Microsoft DNS server v5.0 doesn't support RFC3597. Why not? What servers out there support it? -- HLS From dotzero@gmail.com Thu Apr 25 09:27: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 472B121F8613; Thu, 25 Apr 2013 09:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oywa45NQFH0J; Thu, 25 Apr 2013 09:27:30 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6192021F9633; Thu, 25 Apr 2013 09:26:59 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id es20so2803456lab.27 for ; Thu, 25 Apr 2013 09:26:51 -0700 (PDT) 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=g+VuFvXnjcjIFs6AMfbNW3UVe3fJaK2YkdVS4rx7nrs=; b=dMA/hlwcHFjo8llVOQJxidhmySvMl907juEEu9NwFXbrhXhMznCacKy07bNg7PmSFG bAj2B4KVDSDpwrWd3okkbmyvZtI/JVtBmjJ4CBT4O0MSmwAPsl272lvsbI0ffR6daLUo OiffQpXTrOOCt0+SIpHBQWEjq+NszX7dFKeh44w9SJIIz7VLPIfcTri5p8IbiXP6ZcBr 0+20xmyePFVU9s8IgBbMNObk1EvBB2pTMHVpdumGw0SjT202dFHxPLTGmYp+b3Wd//QS 2bjKkHF2VIhUuMQbWSvroQGl6soweIsJnUMhmxFabE2LB9zP7H7GWKYu1c12sTwqKo4R RyIA== MIME-Version: 1.0 X-Received: by 10.112.135.133 with SMTP id ps5mr6641222lbb.42.1366907211779; Thu, 25 Apr 2013 09:26:51 -0700 (PDT) Received: by 10.112.72.166 with HTTP; Thu, 25 Apr 2013 09:26:51 -0700 (PDT) In-Reply-To: <20130425154235.GP23770@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> Date: Thu, 25 Apr 2013 12:26:51 -0400 Message-ID: From: Dotzero To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, John R Levine , "dnsext@ietf.org Group" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 16:27:48 -0000 On Thu, Apr 25, 2013 at 11:42 AM, M=E5ns Nilsson wrote: > Subject: Re: [dnsext] Obsoleting SPF RRTYPE Date: Thu, Apr 25, 2013 at 05= :03:55PM +0200 Quoting Patrik F=E4ltstr=F6m (paf@frobbit.se): >> >> On 25 apr 2013, at 16:44, John R Levine wrote: >> >> > In any event, the SPF draft is in WGLC. Feel free to read the extensi= ve discussion in the list archives and let them know how you feel. >> >> They know how i feel. We in IETF do believe in rough consensus. I am thi= s time on the rough side. >> >> That does not imply I am quiet in other places, and I am as many others = nervous over the implications. > > This is a slippery slope. One record overload is not bad, but it sort > of opens the floodgates for systematic overloading. DNSEXT and DNSOP > certainly need to get involved; because this is way bigger than just SPF. > > And IMNSHO spfbis is out of scope prescribing TXT records, just because > of this contagiousness. > It is not so much that SPFbis is prescribing practice as it is updating to describe practice and avoid potential problems that have been identified with having both TXT and type 99 records (without a lot of verbage to address hypothetical future use). > For the record: I think that the spfbis draft is unfit for publication > as RFC unless TXT records are deprectaed as only carrier of data. > Would you be any happier if the WG left type 99 records and in a coy manner made it clear that usage is overwhelmingly TXT based with little likelyhood of type 99 gathering any meaningful traction? I'm sure that if the issues surrounding adoption of new RR types were resolved we would not be having this discussion - but they haven't been resolved. Mike From hsantos@isdg.net Thu Apr 25 09:43: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 A755721F9663 for ; Thu, 25 Apr 2013 09:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.608 X-Spam-Level: X-Spam-Status: No, score=-101.608 tagged_above=-999 required=5 tests=[AWL=-0.530, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8Y71s1Assln for ; Thu, 25 Apr 2013 09:43:29 -0700 (PDT) Received: from ftp.catinthebox.net (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 30F7121F965D for ; Thu, 25 Apr 2013 09:43:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4828; t=1366908203; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=R52nnU2 ZqUU082msD4NFqQs9kCk=; b=CXlrSBPBOMBNct1XhbQKp977osnwr8rNj3hh6IK OhuVtIPS9QLR7KQrwQUz1FMGj7Q3WmRdKfFtat69xQiZmHJwFpDjxHZtC9ov1aX2 iew6woF0dao9xZbm756osbbuqacavGAn9nCTI6rKmPF2xM5pwCIKX5ELKAobhsNL F8wA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 25 Apr 2013 12:43:23 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1406925188.615.5752; Thu, 25 Apr 2013 12:43:22 -0400 Message-ID: <51795CDB.6050901@isdg.net> Date: Thu, 25 Apr 2013 12:42:03 -0400 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: spfbis@ietf.org References: <51726641.7070606@tana.it> <51794C1B.8010505@isdg.net> <2711949.2NXGGSvfFZ@scott-latitude-e6320> In-Reply-To: <2711949.2NXGGSvfFZ@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 25 Apr 2013 16:43:30 -0000 On 4/25/2013 11:37 AM, Scott Kitterman wrote: > On Thursday, April 25, 2013 11:30:35 AM Hector Santos wrote: >> The Sender-ID/SPF integrated framework has clear normalized language: >> >> If these tests indicate that the connecting SMTP client is not >> authorized to transmit e-mail messages on behalf of the SUBMITTER >> domain, the receiving SMTP server SHOULD reject the message and when >> rejecting MUST use "550 5.7.1 Submitter not allowed." >> >> If the receiving SMTP server allows the connecting SMTP client to >> transmit message data, then the server SHOULD determine the purported >> responsible address of the message by examining the RFC 2822 message >> headers as described in [PRA]. If this purported responsible address >> does not match the address appearing in the SUBMITTER parameter, the >> receiving SMTP server MUST reject the message and when rejecting MUST >> use "550 5.7.1 Submitter does not match header." >> >> If no purported responsible address is found according to the >> procedure defined in [PRA], the SMTP server SHOULD reject the message >> and when rejecting MUST use "554 5.7.7 Cannot verify submitter >> address." > > What document are you quoting from here? SUBMITTER rfc4405, section 4.2 Processing the SUBMITTER Parameter: http://tools.ietf.org/html/rfc4405#section-4.2 It is even stronger language and clearer in SENDER-ID section 5.3 http://tools.ietf.org/html/rfc4406#section-5.3 >> To do anything else, in my view, the receiver is not SPF compliant. >> >> I should note, for implementators that currently REJECT and which to >> consider the SPFBIS relaxtion to offer an ACCEPT, it would an expensive >> design change to offer this deployment option. > > There's nothing in 4408bis that says you HAVE to change anything about > receiver policy if you don't want to. You're right. I am saying it is advocating this approach (opening the door) and developers who follow this stuff take it all into account. Part of the issue is that according to either one person or a few, the norm is: SPF FAIL --> ACCEPT Again, what I am not hearing is whether they are separating it or not. I'm saying they MUST and therefore should be an explicit statement in 8.4 and not divert it to the security section. Just a flow chart and see if make sense to not naturally CODE what the security section recommends should be done or else. >> As a side note, I don't think SPFBIS has enough Reporting examples. It >> should have an example and description of all possible SPF results. > > Provide text and I'll see about including them. I did Scott, a number of different ways of the year or so. Take a look at how PRA describes it in 5.3 and try to mode this in SPF terms. I believe I had suggested that before. This is whats in PRA, it covers it clearly for both REJECT and ACCEPT logical paths: 5.3. Fail When performing the Sender ID test during an SMTP transaction, an MTA that chooses to reject a message receiving this result SHOULD reject the message with a "550 5.7.1 Sender ID (xxx) yyy - zzz" SMTP error, where "xxx" is replaced with "PRA" or "MAIL FROM", "yyy" is replaced with the additional reason returned by the check_host() function, and "zzz" is replaced with the explanation string returned by the check_host() function. When performing the Sender ID test after accepting an e-mail message for delivery, an MTA that chooses to reject a message receiving this result SHOULD NOT deliver the message. Instead, it should create a DSN message, consistent with the usual rules for DSN messages. Look at how this helps Murray's work with Auth-Res for reporting. I personally do not believe in this path (reporting and bounce) and therefore reject at SMTP to avoid the bounce requirement/expectation. I can't be any more clearer as I have been and that's because there is pressure to use USER-LEVEL policies or one that is embedded ACCEPT PLUS SEPERATE. That is what I am saying it should be PART of the protocol, and not needed to be stated as a SECURITY ISSUE in order for one to do what must be done anyway - not deliver the message. Keep in mind that the POV is not just a tree-like folders display of separated messages, but the idea of how the USER gets access to his mail. As I stated at the very beginning, if a system offers a POP3 server, I highly recommended that this ACCEPTED failed mail IS NOT made part of the POP3 download process which is a single stream. It is not like IMAP where there are multiple viewing streams and possible for a separation to take place. The POP3 user will be victims of an FAIL+ACCEPT deployment - period. There is no ambiguity about that. Folks using Web Mail and IMAP have a separation - I hope. -- HLS From spf2@kitterman.com Thu Apr 25 09:58: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 4499221F9662 for ; Thu, 25 Apr 2013 09:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FgFXd9INR52 for ; Thu, 25 Apr 2013 09:58:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 55D2121F8E46 for ; Thu, 25 Apr 2013 09:58:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8A53F20E410F; Thu, 25 Apr 2013 12:58:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366909109; bh=BluvnXclPgPjARzdvS0UZEDiMe7zfNDoIf/Ir1nnmlk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Z9VmMpfaY3FAc1WESlZ5mMjuXITKoznjIc3lrBqgh7CfQRN4LV1Itkkljq12hDRnB NtybruMlc1JzKnS9mwCUwtTwBGObx15sF8yiyfRqs8nEY8wF09TvHWNp8BxUZ8ydRx 4+AyMG5/1CVSBvZ1kr/aE2DDzHu6OPs9s/7P2qEM= 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 6F6E720E40BE; Thu, 25 Apr 2013 12:58:28 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 25 Apr 2013 12:58:28 -0400 Message-ID: <1813288.bA9KueRQeF@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <51795CDB.6050901@isdg.net> References: <51726641.7070606@tana.it> <2711949.2NXGGSvfFZ@scott-latitude-e6320> <51795CDB.6050901@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 25 Apr 2013 16:58:31 -0000 On Thursday, April 25, 2013 12:42:03 PM Hector Santos wrote: > On 4/25/2013 11:37 AM, Scott Kitterman wrote: > > On Thursday, April 25, 2013 11:30:35 AM Hector Santos wrote: > >> The Sender-ID/SPF integrated framework has clear normalized language: > >> If these tests indicate that the connecting SMTP client is not > >> authorized to transmit e-mail messages on behalf of the SUBMITTER > >> domain, the receiving SMTP server SHOULD reject the message and when > >> rejecting MUST use "550 5.7.1 Submitter not allowed." > >> > >> If the receiving SMTP server allows the connecting SMTP client to > >> transmit message data, then the server SHOULD determine the > >> purported > >> responsible address of the message by examining the RFC 2822 message > >> headers as described in [PRA]. If this purported responsible > >> address > >> does not match the address appearing in the SUBMITTER parameter, the > >> receiving SMTP server MUST reject the message and when rejecting > >> MUST > >> use "550 5.7.1 Submitter does not match header." > >> > >> If no purported responsible address is found according to the > >> procedure defined in [PRA], the SMTP server SHOULD reject the > >> message > >> and when rejecting MUST use "554 5.7.7 Cannot verify submitter > >> address." > > > > What document are you quoting from here? > > SUBMITTER rfc4405, section 4.2 Processing the SUBMITTER Parameter: > > http://tools.ietf.org/html/rfc4405#section-4.2 > > It is even stronger language and clearer in SENDER-ID section 5.3 > > http://tools.ietf.org/html/rfc4406#section-5.3 This is the SPFbis working group, not the Sender ID working group, so I think it's off topic. > >> To do anything else, in my view, the receiver is not SPF compliant. > >> > >> I should note, for implementators that currently REJECT and which to > >> consider the SPFBIS relaxtion to offer an ACCEPT, it would an expensive > >> design change to offer this deployment option. > > > > There's nothing in 4408bis that says you HAVE to change anything about > > receiver policy if you don't want to. > > You're right. I am saying it is advocating this approach (opening the > door) and developers who follow this stuff take it all into account. > > Part of the issue is that according to either one person or a few, the > norm is: > > SPF FAIL --> ACCEPT > > Again, what I am not hearing is whether they are separating it or not. What you've heard is correct for many large providers. Send an SPF fail mail to gmail and see if it gets rejected. It's common. > I'm saying they MUST and therefore should be an explicit statement in > 8.4 and not divert it to the security section. Just a flow chart and > see if make sense to not naturally CODE what the security section > recommends should be done or else. > > >> As a side note, I don't think SPFBIS has enough Reporting examples. It > >> should have an example and description of all possible SPF results. > > > > Provide text and I'll see about including them. > > I did Scott, a number of different ways of the year or so. > > Take a look at how PRA describes it in 5.3 and try to mode this in SPF > terms. I believe I had suggested that before. This is whats in PRA, it > covers it clearly for both REJECT and ACCEPT logical paths: > > 5.3. Fail > > When performing the Sender ID test during an SMTP transaction, an MTA > that chooses to reject a message receiving this result SHOULD reject > the message with a "550 5.7.1 Sender ID (xxx) yyy - zzz" SMTP error, > where "xxx" is replaced with "PRA" or "MAIL FROM", "yyy" is replaced > with the additional reason returned by the check_host() function, and > "zzz" is replaced with the explanation string returned by the > check_host() function. > > When performing the Sender ID test after accepting an e-mail message > for delivery, an MTA that chooses to reject a message receiving this > result SHOULD NOT deliver the message. Instead, it should create a > DSN message, consistent with the usual rules for DSN messages. > > Look at how this helps Murray's work with Auth-Res for reporting. I > personally do not believe in this path (reporting and bounce) and > therefore reject at SMTP to avoid the bounce requirement/expectation. > > I can't be any more clearer as I have been and that's because there is > pressure to use USER-LEVEL policies or one that is embedded ACCEPT PLUS > SEPERATE. That is what I am saying it should be PART of the protocol, > and not needed to be stated as a SECURITY ISSUE in order for one to do > what must be done anyway - not deliver the message. > > Keep in mind that the POV is not just a tree-like folders display of > separated messages, but the idea of how the USER gets access to his > mail. As I stated at the very beginning, if a system offers a POP3 > server, I highly recommended that this ACCEPTED failed mail IS NOT made > part of the POP3 download process which is a single stream. It is not > like IMAP where there are multiple viewing streams and possible for a > separation to take place. The POP3 user will be victims of an > FAIL+ACCEPT deployment - period. There is no ambiguity about that. > > Folks using Web Mail and IMAP have a separation - I hope. I meant text for examples. I think we've had this discussion before and, in my, I'm not the chair, but I read every message on the list, opinion, the body of the text ~represents the consensus of the WG I'm certainly against copying text into 4408bis from any of the SenderID documents. Scott K From sm@elandsys.com Thu Apr 25 10: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 D2CEA21F84CA for ; Thu, 25 Apr 2013 10:34:17 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0XXcUIBmVlY for ; Thu, 25 Apr 2013 10:34:17 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D0321F84A7 for ; Thu, 25 Apr 2013 10:34:17 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.138.130]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3PHXqck021130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Apr 2013 10:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366911247; bh=RmxPpk3oapmnNE2/3C8iV73ar5l/6K0Lrr+dcrStns0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HVCV4mMxRCkeHSmReK2EXsGpfL+kG0EAPiuUqvp3HI6jXBTNd9ygCZ7QbcfF9hGiO 8EqrevIurp71ECiPUelC2GBZbU2MKXkuUo5QKttEPp9bnDe1yaLBE84Pr/8R372O66 +1NmEuLiwtMNnPHwQqLv/8W5ZYs2huplc8nud++w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366911247; i=@elandsys.com; bh=RmxPpk3oapmnNE2/3C8iV73ar5l/6K0Lrr+dcrStns0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fX7gxqmY/ZXf6mJ4V1o6FPvsyAg6ExI1SADRTyPz5aZg3EkRynm6X9VnmQ+C4nFSN n920n+bJLVPOCmjkTbxKyzC3ciONxy/xa5uCMZzPAevapJwjB/7OFm+SSU0RuKQ7s/ 1qsrM95eg2UYwWUsqp922niMMqF6UQ+0dnfh/czY= Message-Id: <6.2.5.6.2.20130425090950.0ceffc00@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 25 Apr 2013 10:33:33 -0700 To: mansaxel@besserwisser.org, paf@frobbit.se From: S Moonesamy In-Reply-To: <20130425154235.GP23770@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 17:34:17 -0000 At 08:42 25-04-2013, Nilsson wrote: >And IMNSHO spfbis is out of scope prescribing TXT records, just because >of this contagiousness. The discussion about the SPF RRTYPE was tracked as Issue #9. There are long threads about that topic in the SPFBIS mailing list archive. The issue was also discussed at IETF 83 ( http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt ). There is a rough summary of the WGLC of the previous SPFBIS draft at http://www.ietf.org/mail-archive/web/spfbis/current/msg01505.html The SPFBIS charter is at http://tools.ietf.org/wg/spfbis/charters I have read that document several times last year to ensure that I understand the working group scope. The working group was also chartered to resolve some experiments and that is what it did. >For the record: I think that the spfbis draft is unfit for publication >as RFC unless TXT records are deprectaed as only carrier of data. I requested comments from DNSEXT ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html ) to ensure that the DNS parameters registry was not being updated incorrectly. I read the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg03491.html I unfortunately do not see any arguments to suggest that the SPFBIS WG take any action. Regards, S. Moonesamy (as document shepherd) From presnick@qti.qualcomm.com Thu Apr 25 10:34: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 35B6521F881C; Thu, 25 Apr 2013 10:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjG0ob3fpVOH; Thu, 25 Apr 2013 10:34:27 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id EF07121F84B7; Thu, 25 Apr 2013 10:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1366911263; x=1398447263; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UUj3Q3VaadkoiSop6s1H9kEW06YTCTIgMEyBMHqTIjE=; b=r9E2V+qST9RvAduSI3DVAFO25+L9s47EwftX0U6MHCs5RAmMa9Az99Fd 0qqBdLuFq0bCbG6QDBUGUS5vft0HxjlMFFXcxykRfZHKXp0QviqE8fH3Y 6pJ5ZlpcIr6+2uCB8i9Mi/FD8Te9q4X+8PBK9QomR3dSCViE9SCLdTSDm E=; X-IronPort-AV: E=Sophos;i="4.87,551,1363158000"; d="scan'208";a="36633237" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 25 Apr 2013 10:34:21 -0700 X-IronPort-AV: E=Sophos;i="4.87,551,1363158000"; d="scan'208";a="438587763" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Apr 2013 10:34:21 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 25 Apr 2013 10:34:21 -0700 Message-ID: <5179691B.50602@qti.qualcomm.com> Date: Thu, 25 Apr 2013 12:34:19 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?M=E5ns_Nilsson?= References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> In-Reply-To: <20130425154235.GP23770@besserwisser.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, John R Levine , "dnsext@ietf.org Group" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 17:34:28 -0000 On 4/25/13 10:42 AM, Måns Nilsson wrote: > And IMNSHO spfbis is out of scope prescribing TXT records, just because > of this contagiousness. > > For the record: I think that the spfbis draft is unfit for publication > as RFC unless TXT records are deprectaed as only carrier of data. > SPFBIS AD hat on for this: We are *long* past this discussion. This discussion should have happened at SPFBIS *chartering* time, as it is crystal clear from the charter that existing features currently in use in SPF are not going away. Indeed, the TXT record was specifically mentioned in the charter. I certainly have the same heartburn as everyone else about having used TXT in this manner, but that ship has long sailed. This is running and interoperable code and it is being documented on the standards track. Unless you think there is a piece of information I missed in my assessment that we had consensus to go forward with this work in the first place, you are going to have a hard time convincing me that this is not in the rough part of the consensus now. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From hsantos@isdg.net Thu Apr 25 10:54: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 EA58621F969A for ; Thu, 25 Apr 2013 10:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqPegr9is+4r for ; Thu, 25 Apr 2013 10:54:06 -0700 (PDT) Received: from catinthebox.net (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E8EC321F9697 for ; Thu, 25 Apr 2013 10:53:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2725; t=1366912434; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=SqtMBAI QPUpTueyoK+8s5pX2MZA=; b=NoE0RifmxmL/J975S849a9mAyxuT7UlYtIao0kS z8z4KBOIjeUAMC1HC+kccQVS0DsFUvR7yDRj3zaA/FMw3SWly+3h3skB1j4jlNL0 d3fWXpG4xUOKQtNzXhcY85JvTElSRclBgb4ND4aJ0LGt6d2uO81rDH0MQtovZ6Xy olks= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 25 Apr 2013 13:53:54 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1411156575.615.4836; Thu, 25 Apr 2013 13:53:54 -0400 Message-ID: <51796D62.2090609@isdg.net> Date: Thu, 25 Apr 2013 13:52:34 -0400 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: Pete Resnick References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> In-Reply-To: <5179691B.50602@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org, =?ISO-8859-1?Q?M=E5ns_Nilsson?= , "dnsext@ietf.org Group" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 17:54:14 -0000 In my view, since I was the one who posted and asked questions about this very issue in IETF and DNSOP to get a feel about the unnamed RRTYPE and rfc3597 "Handling of Unknown DNS Resource Record (RR) Types", the current status quo, nine years later, what most preferred, I don't believe there was a consensus when you include the inputs from the other list to just stay with TXT. My concern was whether an RFC will be "sanctioned" as a proposed standard for what most experts believe, including myself, is a KLUDGE solution and not ideal in large scale and worst as more and more protocols are written using a TXT only solutions, its all limited. What I felt is that some were some key folks who were now more accepting of a TXT based record and possibly because DNS servers have failed to keep up with this need (support RFC3597 or something like it). That was the expectation in my view and we expected a long term migration to occur too. I would support keeping the RRTYPE. I believe it is be less of a cost issue - implementators don't have to "UPGRADE/KEEP UP" to BIS by removing RRTYPE overhead. By making it obsolete, you automatically make all SPF implementators "out of date." Anyway, I am not too sure if everyone will like this outside the SPF BIS group. I didn't get that feel. Only a selective few (key cogs) that are part of this work has began to show an acceptance to it. So if that matters, what is what I was trying to feel in IETF and DNSOP - who else agreed with that from an endorsement standpoint. -- HLS On 4/25/2013 1:34 PM, Pete Resnick wrote: > On 4/25/13 10:42 AM, Måns Nilsson wrote: >> And IMNSHO spfbis is out of scope prescribing TXT records, just because >> of this contagiousness. >> >> For the record: I think that the spfbis draft is unfit for publication >> as RFC unless TXT records are deprectaed as only carrier of data. > > SPFBIS AD hat on for this: > > We are *long* past this discussion. This discussion should have happened > at SPFBIS *chartering* time, as it is crystal clear from the charter > that existing features currently in use in SPF are not going away. > Indeed, the TXT record was specifically mentioned in the charter. > > I certainly have the same heartburn as everyone else about having used > TXT in this manner, but that ship has long sailed. This is running and > interoperable code and it is being documented on the standards track. > Unless you think there is a piece of information I missed in my > assessment that we had consensus to go forward with this work in the > first place, you are going to have a hard time convincing me that this > is not in the rough part of the consensus now. > > pr > From warren@kumari.net Thu Apr 25 11:16: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 91F3721F9642; Thu, 25 Apr 2013 11:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93XLqTskaQbR; Thu, 25 Apr 2013 11:16:19 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B25821F9692; Thu, 25 Apr 2013 11:16:18 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.117]) by vimes.kumari.net (Postfix) with ESMTPSA id 7DA0F1B405F4; Thu, 25 Apr 2013 14:16:17 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Warren Kumari In-Reply-To: <4F78BF49-73D6-4716-A3AA-CA94FA3BD310@kumari.net> Date: Thu, 25 Apr 2013 14:16:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <83A5592A-44F5-40AD-BA2C-05A5F0EBD100@kumari.net> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <4F78BF49-73D6-4716-A3AA-CA94FA3BD310@kumari.net> To: Pete Resnick X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Thu, 25 Apr 2013 11:22:30 -0700 Cc: spfbis@ietf.org, =?windows-1252?Q?M=E5ns_Nilsson?= , Warren Kumari , "dnsext@ietf.org Group" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 18:16:20 -0000 [ Whee, replying to my own message. Always a good sign=85]=20 On Apr 25, 2013, at 2:03 PM, Warren Kumari wrote: >=20 > On Apr 25, 2013, at 1:34 PM, Pete Resnick = wrote: >=20 >> On 4/25/13 10:42 AM, M=E5ns Nilsson wrote: >>> And IMNSHO spfbis is out of scope prescribing TXT records, just = because >>> of this contagiousness. >>>=20 >>> For the record: I think that the spfbis draft is unfit for = publication >>> as RFC unless TXT records are deprectaed as only carrier of data. >>>=20 >>=20 >> SPFBIS AD hat on for this: >>=20 >> We are *long* past this discussion. This discussion should have = happened at SPFBIS *chartering* time, as it is crystal clear from the = charter that existing features currently in use in SPF are not going = away. Indeed, the TXT record was specifically mentioned in the charter. >>=20 >> I certainly have the same heartburn as everyone else about having = used TXT in this manner, but that ship has long sailed. This is running = and interoperable code and it is being documented on the standards = track. Unless you think there is a piece of information I missed in my = assessment that we had consensus to go forward with this work in the = first place, you are going to have a hard time convincing me that this = is not in the rough part of the consensus now. >=20 > I would also recommend that folk actually go and read RFC6686 [0] - I = know that having actual measurements interferes with one's ability to = have a fun little rant, but, if you do, maybe you can avoid looking = silly (like I did with the RFC5507 discussion :-)). >=20 > Maybe stuffing stuff in a TXT record was a poor decision. Maybe it = wasn't. There are heaps more SPF in TXT than SPF in SPF, kvetcing won't = change that, and I'm sure we can find something else more fun to kvetch = about=85 >=20 Ever have one of those days when you just wake up ornery? Those are = probably the days when you shouldn't be responding to mail (or = interacting with people at all) :-P W >=20 > W >=20 > [0]: Yes, I know finding the documents can be hard. Here is a link: = http://tools.ietf.org/html/rfc6686 >=20 >=20 >=20 >> pr >>=20 >> --=20 >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >>=20 >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext >>=20 >=20 > -- > "When it comes to glittering objects, wizards have all the taste and = self-control of a deranged magpie." > -- Terry Pratchett >=20 >=20 >=20 >=20 --=20 A. No Q. Is it sensible to top-post? From paf@frobbit.se Thu Apr 25 13:00: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 688EA21F9457; Thu, 25 Apr 2013 13:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vEe2RFiokxB; Thu, 25 Apr 2013 13:00:05 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id DA5EF21F960E; Thu, 25 Apr 2013 12:59:58 -0700 (PDT) Received: from [172.20.10.2] (2.68.187.227.mobile.tre.se [2.68.187.227]) by mail.frobbit.se (Postfix) with ESMTPSA id 80BD921D7E; Thu, 25 Apr 2013 21:59:57 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4F78BF49-73D6-4716-A3AA-CA94FA3BD310@kumari.net> Date: Thu, 25 Apr 2013 21:59:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A096721-2C0E-450D-9EDF-E2971BD150CB@frobbit.se> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <4F78BF49-73D6-4716-A3AA-CA94FA3BD310@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Thu, 25 Apr 2013 13:09:43 -0700 Cc: spfbis@ietf.org, Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 20:00:05 -0000 On 25 apr 2013, at 20:03, Warren Kumari wrote: > Maybe stuffing stuff in a TXT record was a poor decision. What I tried to explain in RFC5507 was that the real pain(*) is when you = in an RRSet get back more data than what you want, so that you have to = parse the blob of data you get and do whatever you want to do. The selector of what you want can only be in one of the owner, class or = type, and we know the class is sort of not usable, so you are stuck with = type and owner. If now owner is TXT on everything,... The rest is left as an exercise for the reader. Patrik (*) Experience from too extensive use of NAPTR records in various = solutions, and the reason I came up with the URI RRType. From paf@frobbit.se Thu Apr 25 13:02: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 BC40921F9457; Thu, 25 Apr 2013 13:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQXW7q1rRTWh; Thu, 25 Apr 2013 13:02:08 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 3F60B21F93E5; Thu, 25 Apr 2013 13:02:08 -0700 (PDT) Received: from [172.20.10.2] (2.68.187.227.mobile.tre.se [2.68.187.227]) by mail.frobbit.se (Postfix) with ESMTPSA id 2708321CC1; Thu, 25 Apr 2013 22:02:07 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <2A096721-2C0E-450D-9EDF-E2971BD150CB@frobbit.se> Date: Thu, 25 Apr 2013 22:02:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CCE3691-CA30-4EF9-81AC-B1FA27FFE263@frobbit.se> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <4F78BF49-73D6-4716-A3AA-CA94FA3BD310@kumari.net> <2A096721-2C0E-450D-9EDF-E2971BD150CB@frobbit.se> To: Warren Kumari X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Thu, 25 Apr 2013 13:09:50 -0700 Cc: spfbis@ietf.org, Pete Resnick , "dnsext@ietf.org Group" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 20:02:08 -0000 On 25 apr 2013, at 21:59, Patrik F=E4ltstr=F6m wrote: > The selector of what you want can only be in one of the owner, class = or type, and we know the class is sort of not usable, so you are stuck = with type and owner. If now owner is TXT on everything,... Sigh...if now TYPE is TXT on everything...of course... Patrik -- going to bed now From dougb@dougbarton.us Thu Apr 25 13:54: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 ADCD221F9670; Thu, 25 Apr 2013 13:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndMKZJrB1YxO; Thu, 25 Apr 2013 13:54:40 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id F0E2521F965F; Thu, 25 Apr 2013 13:54:39 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:4c6a:66e4:b138:d86] (unknown [IPv6:2001:470:d:5e7:4c6a:66e4:b138:d86]) by dougbarton.us (Postfix) with ESMTPSA id 98B2622BA3; Thu, 25 Apr 2013 20:54:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366923279; bh=/lxC1rSFs1cM9IOfLanu8/jAulxNybK0yU4gHP6o6VA=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=SKCC7UKqWxyJg2AEwvd1B8DmNqDWfWPDKge3rJgDT9Uyb5pmJE8uj4NmY8PYksduh zDPWJJMx76ZKoIauzkOc211OvjTeIsxuNcduPieeAPg9e0c7rMPDSxiNq/PN8P2IXF S4su5rT8Z6b0pLKlb61NCwCFZUDtAVlBd85gZGr0= Message-ID: <5179980F.9090606@dougbarton.us> Date: Thu, 25 Apr 2013 13:54:39 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> In-Reply-To: <5179691B.50602@qti.qualcomm.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 25 Apr 2013 13:59:54 -0700 Cc: spfbis@ietf.org, presnick@qti.qualcomm.com Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 20:54:40 -0000 On 04/25/2013 10:34 AM, Pete Resnick wrote: > On 4/25/13 10:42 AM, Måns Nilsson wrote: >> And IMNSHO spfbis is out of scope prescribing TXT records, just because >> of this contagiousness. >> >> For the record: I think that the spfbis draft is unfit for publication >> as RFC unless TXT records are deprectaed as only carrier of data. > > SPFBIS AD hat on for this: > > We are *long* past this discussion. This discussion should have happened > at SPFBIS *chartering* time, as it is crystal clear from the charter > that existing features currently in use in SPF are not going away. > Indeed, the TXT record was specifically mentioned in the charter. As Ted pointed out, that seems not to be the case. Meanwhile, some of us have spoken long and loud about how deprecating the SPF record is the wrong path, which includes before, during, and after spfbis was chartered. Those concerns have consistently been shouted down, as you are doing now. The way forward is simple, spfbis should specify that compliant senders MUST publish the SPF record, and compliant receivers MUST query for it first. Then down the road at some point we can deprecate TXT for this purpose. If that had been done in the beginning we would be celebrating the deprecation of the TXT record right about now, instead of having another round of contentious arguments about doing it the right way in the first place. Everyone knows the history of how hard it was to get new RRtypes off the ground at the time SPF first came into being. A lot of lessons were learned from that, and the situation is much better now. Everyone also understands that the problem of upgrading 3rd party and/or web-based provisioning systems to accommodate new records is still a problem. But that problem doesn't get better by ignoring it. In short, the proponents of SPF (which by the way, I like and use) should be focusing on doing the right thing here, instead of the expedient thing. Doug From superuser@gmail.com Thu Apr 25 14:09: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 77D1221F96CB; Thu, 25 Apr 2013 14:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh0lkiJsjb-6; Thu, 25 Apr 2013 14:09:49 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4E621F96CA; Thu, 25 Apr 2013 14:09:48 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id l13so3927310wie.12 for ; Thu, 25 Apr 2013 14:09:48 -0700 (PDT) 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=ukdn7kuBj8BLAuYGR1MP0GzJdljV/bkcqGfU8UwwLZo=; b=lfj4Uc8an7FyDOAifeUo/6nhXjuLrxHW7ZM5zRYlGihMRCIdlMCAGtClSc4fTZDhtJ W1Adf+jRDvkva57kJkr7Ccp9QzdJFW0XxrTiUe5oFGjr+++t3J2/NltV8Qp9U3Gnh2zl nzff7gfipCKTLXht9X61F1P7szl+zHWp6KkWbfdmQqVUjuqBA/7Et9nIcMUjCnFHUBJY waWFhmcZVK87ud7VxgFT9F59PBqIxjGSg8LLzkhforNDr5XXajJXo2cjMTYWnJFtURDj 4VYrVTVguzTi9xSK4LHGIfTfbda/j4uBbR5cjiL7UvdBr7YiSxrHX6tu6MZ2A3fSghmU tB5Q== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr165478wic.32.1366924188225; Thu, 25 Apr 2013 14:09:48 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 25 Apr 2013 14:09:47 -0700 (PDT) In-Reply-To: <5179980F.9090606@dougbarton.us> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> Date: Thu, 25 Apr 2013 14:09:47 -0700 Message-ID: From: "Murray S. Kucherawy" To: Doug Barton Content-Type: multipart/alternative; boundary=001a11c34830ac988f04db35d64d Cc: "spfbis@ietf.org" , Pete Resnick , dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 21:09:50 -0000 --001a11c34830ac988f04db35d64d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton wrote: > The way forward is simple, spfbis should specify that compliant senders > MUST publish the SPF record, and compliant receivers MUST query for it > first. Then down the road at some point we can deprecate TXT for this > purpose. If that had been done in the beginning we would be celebrating the > deprecation of the TXT record right about now, instead of having another > round of contentious arguments about doing it the right way in the first > place. > > I fail to see how the word "simple" can be legitimately applied here given the breadth of the deployed base of SPF that's using TXT. It may be the right thing to do, but I don't think that's a mountain that's easy to move. Certainly it's easy to talk about it though. > > Everyone knows the history of how hard it was to get new RRtypes off the > ground at the time SPF first came into being. A lot of lessons were learned > from that, and the situation is much better now. Everyone also understands > that the problem of upgrading 3rd party and/or web-based provisioning > systems to accommodate new records is still a problem. But that problem > doesn't get better by ignoring it. > > In short, the proponents of SPF (which by the way, I like and use) should > be focusing on doing the right thing here, instead of the expedient thing. > I think that same history gives rise to another way forward. When SPF came into being, the RRtype issue prevented the right thing from happening. It was made worse by late insertion of a sloppy transition mechanism. It's much too late to fix that now, but we can take steps to prevent it from happening with future protocols. Thus: Take our licks and leave this one alone, but do good work on improving process and provisioning so that it can't happen again. -MSK --001a11c34830ac988f04db35d64d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton <dougb@dou= gbarton.us> wrote:
The way forward is s= imple, spfbis should specify that compliant senders MUST publish the SPF re= cord, and compliant receivers MUST query for it first. Then down the road a= t some point we can deprecate TXT for this purpose. If that had been done i= n the beginning we would be celebrating the deprecation of the TXT record r= ight about now, instead of having another round of contentious arguments ab= out doing it the right way in the first place.


I fail to see how the word "= ;simple" can be legitimately applied here given the breadth of the dep= loyed base of SPF that's using TXT.=A0 It may be the right thing to do,= but I don't think that's a mountain that's easy to move.=A0 Ce= rtainly it's easy to talk about it though.
=A0

Everyone knows the history of how hard it was to get new RRtypes off the gr= ound at the time SPF first came into being. A lot of lessons were learned f= rom that, and the situation is much better now. Everyone also understands t= hat the problem of upgrading 3rd party and/or web-based provisioning system= s to accommodate new records is still a problem. But that problem doesn'= ;t get better by ignoring it.

In short, the proponents of SPF (which by the way, I like and use) should b= e focusing on doing the right thing here, instead of the expedient thing.

I think that same history gives rise to another way for= ward.=A0 When SPF came into being, the RRtype issue prevented the right thi= ng from happening.=A0 It was made worse by late insertion of a sloppy trans= ition mechanism.=A0 It's much too late to fix that now, but we can take= steps to prevent it from happening with future protocols. Thus: Take our l= icks and leave this one alone, but do good work on improving process and pr= ovisioning so that it can't happen again.

-MSK
--001a11c34830ac988f04db35d64d-- From spf2@kitterman.com Thu Apr 25 14:40: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 3308921F9714 for ; Thu, 25 Apr 2013 14:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHPP7WEblZJ5 for ; Thu, 25 Apr 2013 14:40:17 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 59EFD21F9713 for ; Thu, 25 Apr 2013 14:40:17 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AE77E20E410F; Thu, 25 Apr 2013 17:40:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366926016; bh=Hh6LhZ0p0JD506GCvzEbwfCcKNyGqzU6XAv3xqMlFEw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=E9LKRmjwsmN+U8rv8H9ak56x0k4kTTmA221v1Ru7zH73kkXh3zMrtM0/jBgXnmR/v dHv9uf3OV/BuloAEOV4Gr+BoQ6fLoJQXMGJ7MMUGLKAgGyL3thW07Vs6Q2yroL3LEo 2jw2ui1268MZ0IzQp5eZKVGc+c6n4on53lbatoSE= 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 94A4E20E40BE; Thu, 25 Apr 2013 17:40:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 25 Apr 2013 17:40:15 -0400 Message-ID: <4261402.9fOGfQ789f@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <5179980F.9090606@dougbarton.us> References: <20130425013317.36729.qmail@joyce.lan> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 21:40:18 -0000 On Thursday, April 25, 2013 01:54:39 PM Doug Barton wrote: > On 04/25/2013 10:34 AM, Pete Resnick wrote: > > On 4/25/13 10:42 AM, M=E5ns Nilsson wrote: > >> And IMNSHO spfbis is out of scope prescribing TXT records, just be= cause > >> of this contagiousness. > >>=20 > >> For the record: I think that the spfbis draft is unfit for publica= tion > >> as RFC unless TXT records are deprectaed as only carrier of data. > >=20 > > SPFBIS AD hat on for this: > >=20 > > We are *long* past this discussion. This discussion should have hap= pened > > at SPFBIS *chartering* time, as it is crystal clear from the charte= r > > that existing features currently in use in SPF are not going away. > > Indeed, the TXT record was specifically mentioned in the charter. >=20 > As Ted pointed out, that seems not to be the case. >=20 > Meanwhile, some of us have spoken long and loud about how deprecating= > the SPF record is the wrong path, which includes before, during, and > after spfbis was chartered. Those concerns have consistently been > shouted down, as you are doing now. >=20 > The way forward is simple, spfbis should specify that compliant sende= rs > MUST publish the SPF record, and compliant receivers MUST query for i= t > first. Then down the road at some point we can deprecate TXT for this= > purpose. If that had been done in the beginning we would be celebrati= ng > the deprecation of the TXT record right about now, instead of having > another round of contentious arguments about doing it the right way i= n > the first place. >=20 > Everyone knows the history of how hard it was to get new RRtypes off = the > ground at the time SPF first came into being. A lot of lessons were > learned from that, and the situation is much better now. Everyone als= o > understands that the problem of upgrading 3rd party and/or web-based > provisioning systems to accommodate new records is still a problem. B= ut > that problem doesn't get better by ignoring it. >=20 > In short, the proponents of SPF (which by the way, I like and use) > should be focusing on doing the right thing here, instead of the > expedient thing. Type SPF has virtually no deployment and there's no incentive for peopl= e to=20 switch to it (words on paper in 4408bis won't do it). There are still=20= substantial real world barriers to deployment and no operational intere= st in=20 expending resources to resolve them. The BEST case scenario from not=20= deprecating is doubling the number of DNS queries associated with SPF. = That's=20 not a good thing. You might as well go back and get DKIM to create and use a new RR Type = while=20 you're at it. Scott K From dougb@dougbarton.us Thu Apr 25 14:39: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 A5F0C21F970F; Thu, 25 Apr 2013 14:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA3-fnPEGdP0; Thu, 25 Apr 2013 14:39:49 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id E542221F96CB; Thu, 25 Apr 2013 14:39:48 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:4c6a:66e4:b138:d86] (unknown [IPv6:2001:470:d:5e7:4c6a:66e4:b138:d86]) by dougbarton.us (Postfix) with ESMTPSA id 94FEA22BA3; Thu, 25 Apr 2013 21:39:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366925988; bh=RKKRNK/x9v4TndQFLyV8fb6Hl2P15u1iVKXKIVkBL9M=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=IZeTARzfAp4t1wY6R0190dKziyj36iC4mVntrnKObT7Si+fX/PrgoL6mcbKiXxSc0 wFH//2tHOGfWggMvKNz1awwfoj9ffbU+ocaAE4Hjke5hTRDGkg7AOcGWF5AscrltG0 f5uWBB81xGp1YaG7dpdjoGwQMHs8BTk2d7gwLQUE= Message-ID: <5179A2A4.1090606@dougbarton.us> Date: Thu, 25 Apr 2013 14:39:48 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 25 Apr 2013 14:45:48 -0700 Cc: "spfbis@ietf.org" , Pete Resnick , dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 21:39:49 -0000 On 04/25/2013 02:09 PM, Murray S. Kucherawy wrote: > On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton > wrote: > > The way forward is simple, spfbis should specify that compliant > senders MUST publish the SPF record, and compliant receivers MUST > query for it first. Then down the road at some point we can > deprecate TXT for this purpose. If that had been done in the > beginning we would be celebrating the deprecation of the TXT record > right about now, instead of having another round of contentious > arguments about doing it the right way in the first place. > > > I fail to see how the word "simple" can be legitimately applied here > given the breadth of the deployed base of SPF that's using TXT. I didn't say "Don't query for TXT records any more." I definitely didn't say, "Let's throw out SPF altogether." I said "change it to go the right way around in the first place." Obviously the transition will take time (as I also pointed out), but that doesn't mean that we shouldn't start doing it the right way now. And really, it IS simple. Tomorrow all the extant software that deals with SPF gets updated to query for SPF first. The next day all the docs for publishing SPF records tell people to publish both. Ok, tomorrow and the next day are probably not realistic, but how about next week? Or next month? This isn't brain surgery, it really is a very simple change. And sure it's going to take time to implement, time to upgrade the installed base, and time for the pendulum to swing from TXT being queried nearly universally to SPF instead. But it's a minimal amount of effort, and the time is going to pass anyway. There is simply no reason not to do this right, and to start doing it right now. > It may > be the right thing to do, but I don't think that's a mountain that's > easy to move. Certainly it's easy to talk about it though. We in the DNS world have a ton of experience with the long tail of an installed base that doesn't upgrade often. Maybe that's the difference in perspective that makes this look like an "easy" problem to us. > Everyone knows the history of how hard it was to get new RRtypes off > the ground at the time SPF first came into being. A lot of lessons > were learned from that, and the situation is much better now. > Everyone also understands that the problem of upgrading 3rd party > and/or web-based provisioning systems to accommodate new records is > still a problem. But that problem doesn't get better by ignoring it. > > In short, the proponents of SPF (which by the way, I like and use) > should be focusing on doing the right thing here, instead of the > expedient thing. > > > I think that same history gives rise to another way forward. When SPF > came into being, the RRtype issue prevented the right thing from > happening. I would argue that the situation at the time made doing the right thing more difficult than using the TXT record, not that it made it impossible. But I will agree to disagree on that point. :) > It was made worse by late insertion of a sloppy transition > mechanism. It's much too late to fix that now But it's not. That's the point. I realize that the course of action where we throw up our hands and say to ourselves, "better luck next time, hopefully this will become a lesson learned" is wildly attractive. But it's bad to do that. Bad for SPF, bad for the DNS in general, and bad for the Internet as a whole. And most importantly, it would be choosing to do the wrong thing when there is no reason not to do the right thing. Doug From hsantos@isdg.net Thu Apr 25 14:58: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 10CD721F9616 for ; Thu, 25 Apr 2013 14:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn34rsNgUhPF for ; Thu, 25 Apr 2013 14:58:32 -0700 (PDT) Received: from ntbbs.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D3E3521F8523 for ; Thu, 25 Apr 2013 14:58:31 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3517; t=1366927108; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=nVT6TLm UuQeN+oNuQZhnhH7E6BI=; b=k35/jp6OoDYp0SBcLvCrrUeuEZk19nW80+sZq7D myTTJKOHSubBDCrTkOiXrz8WTLxvKKIN+Xrldrzs3vPJIy+/jKNK/bd03Aa6yNbS U0bIfWUEdBujIDLGn7jp4Hg1baNIeFm6v+kEdrwBic++HND0PqWQxAhRSOq9s0Vd 6Wuo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 25 Apr 2013 17:58:28 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1425830138.615.4172; Thu, 25 Apr 2013 17:58:27 -0400 Message-ID: <5179A6B4.7030600@isdg.net> Date: Thu, 25 Apr 2013 17:57:08 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , Pete Resnick , Doug Barton , dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 21:58:33 -0000 I believe the right engineering design choice in MARID was made. The problem was the DNS Servers have not caught up with the very least of having a passthru concept with unnamed query types. It is was clearly known what the issues were in MARID, a migration path was provided with the protocol and we fully expected the DNS servers will eventually catch up and support unnamed types. [1] It was a long term migration path issue as Doug Barton pointed out. I still believe having a specific record is the right thing and path. Eliminating it will only encourage more TXT-based protocols. The question is whether the DNS servers will support it or at the very least a passthru. I suggest to keep it and to relax the requirements, and basically have developers keep it as an software design option, i.e. don't forget about it, comment it out, compiler directives, etc. It would be their choice to immediately support the ideal migration path that is currently described in 4408 (although I have a small issue with the parallel call idea, but that's a different issue), or leave the code ready but disable it for a TXT only query. Lets think ahead here now (again), not later and begin to encourage DNS server developers/vendors, DNS Managerment Software folks, etc, to support unnamed types processing. [1] -- HLS [1] http://tools.ietf.org/html/rfc3597 n 4/25/2013 5:09 PM, Murray S. Kucherawy wrote: > On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton wrote: > >> The way forward is simple, spfbis should specify that compliant senders >> MUST publish the SPF record, and compliant receivers MUST query for it >> first. Then down the road at some point we can deprecate TXT for this >> purpose. If that had been done in the beginning we would be celebrating the >> deprecation of the TXT record right about now, instead of having another >> round of contentious arguments about doing it the right way in the first >> place. >> >> > I fail to see how the word "simple" can be legitimately applied here given > the breadth of the deployed base of SPF that's using TXT. It may be the > right thing to do, but I don't think that's a mountain that's easy to > move. Certainly it's easy to talk about it though. > > >> >> Everyone knows the history of how hard it was to get new RRtypes off the >> ground at the time SPF first came into being. A lot of lessons were learned >> from that, and the situation is much better now. Everyone also understands >> that the problem of upgrading 3rd party and/or web-based provisioning >> systems to accommodate new records is still a problem. But that problem >> doesn't get better by ignoring it. >> >> In short, the proponents of SPF (which by the way, I like and use) should >> be focusing on doing the right thing here, instead of the expedient thing. >> > > I think that same history gives rise to another way forward. When SPF came > into being, the RRtype issue prevented the right thing from happening. It > was made worse by late insertion of a sloppy transition mechanism. It's > much too late to fix that now, but we can take steps to prevent it from > happening with future protocols. Thus: Take our licks and leave this one > alone, but do good work on improving process and provisioning so that it > can't happen again. > > -MSK > > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From presnick@qti.qualcomm.com Thu Apr 25 15:41: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 454B421F9707; Thu, 25 Apr 2013 15:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvoEVMp9Y+I3; Thu, 25 Apr 2013 15:41:21 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 46A6121F96FB; Thu, 25 Apr 2013 15:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1366929681; x=1398465681; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=a/AYLIclim3tXn690H0jl64Gk5TLsvK7/8PsPmbA7Tg=; b=F7aQZD3A/U4/cDwmzbKBJA69LDSodT3gNrWA1y6PhJR8HSXlONgk9rjg 6hOiyb5KaAexDnFRCikQTncMXgpQCBvMD0fsc0r7PSfVPLUWeIwB9FTgB WNu5tIuKLBbWPh5rIN2poEoxkH3c7T+Zbsff5zvXJOjupmq6a4LGgVFMj E=; X-IronPort-AV: E=Sophos;i="4.87,553,1363158000"; d="scan'208";a="36760509" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 25 Apr 2013 15:41:20 -0700 X-IronPort-AV: E=Sophos;i="4.87,553,1363158000"; d="scan'208";a="527920051" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Apr 2013 15:41:20 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 25 Apr 2013 15:41:20 -0700 Message-ID: <5179B10E.705@qti.qualcomm.com> Date: Thu, 25 Apr 2013 17:41:18 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Doug Barton References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> In-Reply-To: <5179980F.9090606@dougbarton.us> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 22:41:22 -0000 On 4/25/13 3:54 PM, Doug Barton wrote: > On 04/25/2013 10:34 AM, Pete Resnick wrote: >> On 4/25/13 10:42 AM, Måns Nilsson wrote: >>> And IMNSHO spfbis is out of scope prescribing TXT records, just because >>> of this contagiousness. >>> >>> For the record: I think that the spfbis draft is unfit for publication >>> as RFC unless TXT records are deprectaed as only carrier of data. >> >> SPFBIS AD hat on for this: >> >> We are *long* past this discussion. This discussion should have happened >> at SPFBIS *chartering* time, as it is crystal clear from the charter >> that existing features currently in use in SPF are not going away. >> Indeed, the TXT record was specifically mentioned in the charter. > > As Ted pointed out, that seems not to be the case. Ted and I just had a discussion about this offline, and just as Ted did, you have misread what I wrote. I responded to Måns's suggestion that spfbis can not "prescribe TXT records". And I responded that existing features currently in use in SPF (of which the use of TXT is such a feature) are out of charter to remove. And they are. The removal of the feature to use RR 99 was an option open to the WG if they determined that it was not on the forbidden list of "features currently in use". RFC 6686 and the discussion leading up to it document why it is, for all intents and purposes, unused. > Meanwhile, some of us have spoken long and loud about how deprecating > the SPF record is the wrong path, which includes before, during, and > after spfbis was chartered. Those concerns have consistently been > shouted down, as you are doing now. A few things on this point: 1. There is no doubt that the removal of the feature to use RR 99 engendered a protracted and contentious discussion. However, it was not specifically discussed before or during chartering as far as I can tell. I've looked through the IETF list, the IESG list, the DNSEXT list, and the SPFBIS list and I see nothing on this topic discussed prior to chartering. And importantly, I see not a single message from you in particular on this topic prior to this, and only a few messages in September of last year on any SPF topic. So I'm not clear on what you mean by "some of us" having "spoken long and loud" about this topic before or during SPFBIS being chartered. 2. There is also no doubt that during the long discussion in February of last year on the SPFBIS list, many folks expressed the view that the feature ought not be removed, including by at least one chair of the WG. (In fact, that argument drove some of the research that ended up in RFC 6686.) However, in the end, a consensus call was made that, although there were some outstanding objections, those concerns were sufficiently addressed *by reasoned technical argument* and that the consensus (with some roughness) was that the feature was to be removed. Though there may have been shouting at times, there was no "shouting down". 3. I do not intend, and hope I have not, "shouted down" any argument here. However, there is now a long record on this argument and how the consensus call was made. Though the chairs and I will review all discussion that comes out during Last Call (or now), it really is only polite for (if not incumbent on) those who might still have objections to do some research to see if their particular argument was not addressed in that lengthy discussion. My claim in my earlier message was (and remains) that it's going to take identifying some piece of information that was missed during that discussion to convince me that the consensus call was not correct. As I've said elsewhere, number of people saying something is not how consensus is judged; it's whether the issue itself was properly addressed. (See draft-resnick-on-consensus-02 for my musings on that.) Coming to consensus is hard work, and it shouldn't just be hard work for chairs and ADs; participants have to do their part too. In particular: > The way forward is simple, spfbis should specify that compliant > senders MUST publish the SPF record, and compliant receivers MUST > query for it first. Then down the road at some point we can deprecate > TXT for this purpose. This is *not* a new argument. It was one that was discussed at length on the SPFBIS list at the end of last February. If you think we missed something (and I'd really ask you to read through the discussion of issue #9 on the list), I'd encourage you to make that case. But simply saying, "MUST publish/MUST query/later deprecate TXT" is not a sufficient technical argument given all that has been discussed to date. > In short, the proponents of SPF (which by the way, I like and use) > should be focusing on doing the right thing here, instead of the > expedient thing. If, after reading the discussion, you think SPFBIS was being superficial in its treatment of this topic and can identify an argument that was missed, fine. But your presumption that this was done simply for expedience is at the very least premature. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From dougb@dougbarton.us Thu Apr 25 16:28: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 4D1F621F96A8; Thu, 25 Apr 2013 16:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18NbxykZoKl4; Thu, 25 Apr 2013 16:28:51 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 03E0521F968B; Thu, 25 Apr 2013 16:28:51 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:4c6a:66e4:b138:d86] (unknown [IPv6:2001:470:d:5e7:4c6a:66e4:b138:d86]) by dougbarton.us (Postfix) with ESMTPSA id ADFBA22BA3; Thu, 25 Apr 2013 23:28:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366932530; bh=7rYngVGG544ALrcvvGlrARPqPahX4hLmApm1qrQdTi8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=IjN8cU4qKtxU2Yz/JmlccsJerHcDmSNUNC1gT9uvHvvgQxJHN1F/phSdvqzl5rABi tIOI7WPS1xlbYtnWplAdv4/XawTvdC2VH21E1nBuP2lKDXqWGKl+r+maLTqSQzmxBy U7Iee5WML4MNls6qAi2YLHSzrfIeIEoSG5BsUcMQ= Message-ID: <5179BC32.8050205@dougbarton.us> Date: Thu, 25 Apr 2013 16:28:50 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pete Resnick References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> In-Reply-To: <5179B10E.705@qti.qualcomm.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 25 Apr 2013 16:30:20 -0700 Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 25 Apr 2013 23:28:52 -0000 On 04/25/2013 03:41 PM, Pete Resnick wrote: > On 4/25/13 3:54 PM, Doug Barton wrote: >> On 04/25/2013 10:34 AM, Pete Resnick wrote: >>> On 4/25/13 10:42 AM, Måns Nilsson wrote: >>>> And IMNSHO spfbis is out of scope prescribing TXT records, just because >>>> of this contagiousness. >>>> >>>> For the record: I think that the spfbis draft is unfit for publication >>>> as RFC unless TXT records are deprectaed as only carrier of data. >>> >>> SPFBIS AD hat on for this: >>> >>> We are *long* past this discussion. This discussion should have happened >>> at SPFBIS *chartering* time, as it is crystal clear from the charter >>> that existing features currently in use in SPF are not going away. >>> Indeed, the TXT record was specifically mentioned in the charter. >> >> As Ted pointed out, that seems not to be the case. > > Ted and I just had a discussion about this offline, and just as Ted did, > you have misread what I wrote. I responded to Måns's suggestion that > spfbis can not "prescribe TXT records". And I responded that existing > features currently in use in SPF (of which the use of TXT is such a > feature) are out of charter to remove. And they are. ... and for the Nth repetition, I did not propose to remove the TXT record at this time. > The removal of the feature to use RR 99 was an option open to the WG if > they determined that it was not on the forbidden list of "features > currently in use". RFC 6686 and the discussion leading up to it document > why it is, for all intents and purposes, unused. Yep, been there, done that. It was a bad decision then, and it's still a bad decision now. I realize that it's incredibly unpopular to bluntly call bad decisions "bad decisions," but not doing so doesn't make them any less bad. And, to make matters worse, not doing so has led to a non-trivial number of those bad decisions becoming de facto standards. This has at least 2 very bad side effects ... first, we have to live with the bad de facto standards; but more importantly we are providing encouragement to people who wish to make similar bad decisions down the road. The argument in 6686 boils down to, "We made a series of bad decisions, which have led to a bad result. We now want to codify that bad result instead of cleaning up our mess." I don't agree with that in principle, and I don't agree with that in regards to this particular case. Further, while cleaning up the SPF mess would require nothing more than a marginal amount of extra work now, plus the passage of time, there is no reason not to actually clean up the mess. >> Meanwhile, some of us have spoken long and loud about how deprecating >> the SPF record is the wrong path, which includes before, during, and >> after spfbis was chartered. Those concerns have consistently been >> shouted down, as you are doing now. > > A few things on this point: > > 1. There is no doubt that the removal of the feature to use RR 99 > engendered a protracted and contentious discussion. However, it was not > specifically discussed before or during chartering as far as I can tell. > I've looked through the IETF list, the IESG list, the DNSEXT list, and > the SPFBIS list and I see nothing on this topic discussed prior to > chartering. https://www.ietf.org/mail-archive/web/ietf/current/msg72024.html is where the thread starts. There is another parallel thread an a related topic around that same time. > And importantly, I see not a single message from you in > particular on this topic prior to this, https://www.ietf.org/mail-archive/web/ietf/current/msg72085.html > and only a few messages in > September of last year on any SPF topic. So I'm not clear on what you > mean by "some of us" having "spoken long and loud" about this topic > before or during SPFBIS being chartered. With respect, you clearly haven't been paying attention. That thread on ietf@ (and the one you referenced on dnsext) took me about 2 minutes to find. Admittedly, the ietf@ thread wasn't specifically about SPF, but it was about the same exact topic, at the time that the spfbis charter was being developed, so one would think that interested parties would have wanted to pay attention. The topic has been raised numerous times since day 1 of SPF, and the DNS folk who have said "the SPF RRtype should be the first (if not only) choice" have been consistently ignored. Meanwhile, who said what when isn't the interesting part of the discussion. The questions are simple: 1. What is the right thing to do? 2. Can we do it? We know the answer to 1, and the answer to 2 is yes. So why are we spending all of this time trying to find reasons not to do the right thing? If as much energy had gone into fixing the problem as has gone into justifying not fixing the problem, the problem would be fixed by now. :) > 2. There is also no doubt that during the long discussion in February of > last year on the SPFBIS list, many folks expressed the view that the > feature ought not be removed, including by at least one chair of the WG. > (In fact, that argument drove some of the research that ended up in RFC > 6686.) However, in the end, a consensus call was made that, although > there were some outstanding objections, those concerns were sufficiently > addressed *by reasoned technical argument* and that the consensus (with > some roughness) was that the feature was to be removed. Yes, I know the history. It was a bad decision. The great thing about life, especially life in the IETF, is that bad decisions can be revisited. > Though there may > have been shouting at times, there was no "shouting down". Others see the problem differently, but let's not quibble on that point. > 3. I do not intend, and hope I have not, "shouted down" any argument > here. However, there is now a long record on this argument and how the > consensus call was made. Though the chairs and I will review all > discussion that comes out during Last Call (or now), it really is only > polite for (if not incumbent on) those who might still have objections > to do some research to see if their particular argument was not > addressed in that lengthy discussion. My claim in my earlier message was > (and remains) that it's going to take identifying some piece of > information that was missed during that discussion to convince me that > the consensus call was not correct. As I've said elsewhere, number of > people saying something is not how consensus is judged; it's whether the > issue itself was properly addressed. (See draft-resnick-on-consensus-02 > for my musings on that.) Coming to consensus is hard work, and it > shouldn't just be hard work for chairs and ADs; participants have to do > their part too. > > In particular: > >> The way forward is simple, spfbis should specify that compliant >> senders MUST publish the SPF record, and compliant receivers MUST >> query for it first. Then down the road at some point we can deprecate >> TXT for this purpose. > > This is *not* a new argument. It was one that was discussed at length on > the SPFBIS list at the end of last February. If you think we missed > something (and I'd really ask you to read through the discussion of > issue #9 on the list), I'd encourage you to make that case. I'll give that a go, sure. > But simply > saying, "MUST publish/MUST query/later deprecate TXT" is not a > sufficient technical argument given all that has been discussed to date. But what if all of the previous discussion was wrong? Simply saying "we have discussed this extensively" doesn't refute sound technical arguments either. :) >> In short, the proponents of SPF (which by the way, I like and use) >> should be focusing on doing the right thing here, instead of the >> expedient thing. > > If, after reading the discussion, you think SPFBIS was being superficial > in its treatment of this topic and can identify an argument that was > missed, fine. But your presumption that this was done simply for > expedience is at the very least premature. While I didn't follow the spfbis group, I have followed SPF from the time before it was even a topic at the IETF. Given what I know of the history I stand by my assertion, but would be overjoyed to be proven wrong. Doug From dougb@dougbarton.us Thu Apr 25 17:15:46 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 1A27D21F9080; Thu, 25 Apr 2013 17:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcwSRjWKEGYJ; Thu, 25 Apr 2013 17:15:45 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id E140321F8AD5; Thu, 25 Apr 2013 17:15:44 -0700 (PDT) Received: from [192.168.0.102] (home [12.207.105.210]) by dougbarton.us (Postfix) with ESMTPSA id 3447822BA3; Fri, 26 Apr 2013 00:15:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366935344; bh=kI3CLRIafveYkF4joKnhr5ZSoqI3uB6Ma3lp8WR2LLo=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=wAv9Qf8yqQikJ/JPmlrlf3sApTY5SEdWwjy7G8S8rI5PRUbYqryZuz5JCYZuha56X thihi8RKhKZi6j9uM0IdzS9mbUEq3QZ91vVFuU7b1rhLROfC/niGdBrqLIBH+R9AL/ nQPhWbvaRQ0HqiaRAukuFmaR1GQ0re3u3UJfP0hY= Message-ID: <5179C72F.1070703@dougbarton.us> Date: Thu, 25 Apr 2013 17:15:43 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pete Resnick References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> In-Reply-To: <5179B10E.705@qti.qualcomm.com> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 25 Apr 2013 17:22:50 -0700 Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 00:15:46 -0000 On 04/25/2013 03:41 PM, Pete Resnick wrote: > and I'd really ask you to read through the discussion of issue #9 on the > list Ok, so I've read through those threads, and the antecedents. I saw the following: 1. Some reports of people who wrote code to use the new RRtype early on, and had problems, so they stopped. 2. A report that Perl's "Mail::SPF (which is used by Spamassassin) checks for Type SPF first by default." 3. Several folks pointing out the valid DNS protocol based reasons why overloading TXT is bad, and new RRtypes for new features are good. 4. Lots of messages along the lines of, "We've always used TXT for this, so we should keep using it." These arguments all seem focused around the concept that having 2 ways to do the same thing is kind of a pain, so let's just use the one that is most popular. 5. Some fairly persuasive technical arguments from Andrew Sullivan that putting SPF records into your zone is a good idea. Particularly this: https://www.ietf.org/mail-archive/web/spfbis/current/msg00544.html #1 was an expected result in the days prior to 3597 (2003), but should be little to no trouble now. #2 Speaks in favor of my proposal. #3 (Arguably one of the only "reasoned technical arguments" in the bunch) seems to have been ignored by the majority of list members. #4 Is not a "reasoned technical argument." #5 Is also a "reasoned technical argument," which was not only ignored, but twisted on its ear by at least one list member. It's also worth pointing out that a non-zero number of list members were ready (eager?) to shut down the SPF record prior to their being any actual discussion of it. So I stand by my original proposal. We should do the right thing here, not the expedient thing. And the fact that a significant piece of software is already doing that, and clearly it works, is a pretty big point in favor. Further, there were no "reasoned technical arguments" in that thread against doing what I proposed. As I mentioned in #4 above there was some whinging about having 2 ways to do the lookup, but as I pointed out previously if the switch had been flipped to do the SPF lookup first at some reasonable time post-3597, we'd be celebrating the deprecation of the TXT record right about now. And further than _that_, Andrew and a few other list members pointed out that with a theoretical v=spf3 on the horizon, that would be a perfect time to say "Use the SPF record only, don't use TXT at all." Of course that whole line of thought was shot down with the same, "But we've always used TXT" argument. Which is unfortunate because I think that would have been an excellent compromise position, which has valid technical grounds. Doug From sm@elandsys.com Thu Apr 25 17:53: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 AC9B521F9705; Thu, 25 Apr 2013 17:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY0z0ULKOctn; Thu, 25 Apr 2013 17:53:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E385721F96E7; Thu, 25 Apr 2013 17:53:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.138.130]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3Q0raWQ014562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Apr 2013 17:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366937629; bh=cEkPrjj/QJwjlEeXN1KSY9P6aKUsTJ0HlockEcSNFfI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mbQe6Mbg2qFQRqb5tQXhj8XZgrhk4yNlotwvN/HXYIqKhsr7+QphSQVydSFG0nEnR kATvuwsPd+9blYlTPc9VYEoZl7rR4hkq8cCvkWfO6hQyk8bcwSqd2T2BX0Sd+0WhDK n8YBLth1eyT90noZPtTS51tRiUOb1cDaKxu1ZEGs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366937629; i=@elandsys.com; bh=cEkPrjj/QJwjlEeXN1KSY9P6aKUsTJ0HlockEcSNFfI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=s/Xsu4JRyUKM6xlgWGS/8G6kkksxsGl6siN1wzNqInVGXAtHKqV9Dk/H1f8lCwwCm 1/EmlNFgXSoHkSMS8o9a1o2GotoDoo8jYY4ywERaezzL1qHc7f9OcYixEJ92fMstS5 y5w50z35bGXCpS3KW5t6Nx88+6Bp41FKnXwJt2Mg= Message-Id: <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 25 Apr 2013 17:22:25 -0700 To: Doug Barton From: S Moonesamy In-Reply-To: <5179BC32.8050205@dougbarton.us> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 00:53:52 -0000 Hi Doug, At 16:28 25-04-2013, Doug Barton wrote: >Yep, been there, done that. It was a bad decision then, and it's >still a bad decision now. I realize that it's incredibly unpopular >to bluntly call bad decisions "bad decisions," but not doing so >doesn't make them any less bad. And, to make matters worse, I am ok if anyone says that it a bad decision. The thread for the discussion started at http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html >The argument in 6686 boils down to, "We made a series of bad >decisions, which have led to a bad result. We now want to codify >that bad result instead of cleaning up our mess." I don't agree with >that in principle, and I don't agree with that in regards to this >particular case. I was the document shepherd for RFC 6686. There wasn't any comments during the Last Call. >https://www.ietf.org/mail-archive/web/ietf/current/msg72024.html is >where the thread starts. There is another parallel thread an a >related topic around that same time. I read the messages on that thread around the time they were posted. >https://www.ietf.org/mail-archive/web/ietf/current/msg72085.html I also read those messages. >The topic has been raised numerous times since day 1 of SPF, and the >DNS folk who have said "the SPF RRtype should be the first (if not >only) choice" have been consistently ignored. I have to respectfully mention that I read all the messages that were posted to the SPFBIS mailing list. I cannot take into consideration comments posted to ietf@ if they are not part of the Last Call. >But what if all of the previous discussion was wrong? Simply saying >"we have discussed this extensively" doesn't refute sound technical >arguments either. :) If all the previous discussions were wrong I hope that the future discussions will be right. :-) >While I didn't follow the spfbis group, I have followed SPF from the >time before it was You missed http://www.ietf.org/mail-archive/web/spfbis/current/msg01440.html :-) At 17:15 25-04-2013, Doug Barton wrote: >5. Some fairly persuasive technical arguments from Andrew Sullivan >that putting SPF records into your zone is a good idea. Particularly this: >https://www.ietf.org/mail-archive/web/spfbis/current/msg00544.html [snip] >#5 Is also a "reasoned technical argument," which was not only >ignored, but twisted on its ear by at least one list member. The SPFBIS WG Chairs are the persons making the determination for discussions within the working group. I happen to be one of the SPFBIS WG co-chairs and the other co-chair is Andrew Sullivan. I didn't ignore his comments. I didn't ask Andrew Sullivan whether he ignored his comments. If I misunderstood or misinterpreted his comments he would likely talk to me about that. That makes it unlikely that any twisting would reach my ears. :-) Regards, S. Moonesamy From spf2@kitterman.com Thu Apr 25 20:22: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 6D47E21F97C2 for ; Thu, 25 Apr 2013 20:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OcoRqUW5miz for ; Thu, 25 Apr 2013 20:22:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CB7EA21F97C0 for ; Thu, 25 Apr 2013 20:22:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 411B220E410F; Thu, 25 Apr 2013 23:22:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366946562; bh=F2Ik78FYaTbs7uEVqICTcss1J0BUGmfWE5G6F9UV2cE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZmXi3/ZwjETpQL5hdiYJI0joA5uB6W+BMo5f6iaisF4PoV4j4CV5qSY+8JMRyzgzW BIhk9ohY5QTxw8v4BjpeaWwxEBaAiSnMwbc9stI4/6sgJaTlvjWhHKxcClzdMIagLx BWr2g9eXwMK7i0VGCHpsYfK7gf6x5kXHEkjtFpmQ= 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 2606C20E40BE; Thu, 25 Apr 2013 23:22:41 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 25 Apr 2013 23:22:39 -0400 Message-ID: <1998649.x7xmPiSjvn@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <5179C72F.1070703@dougbarton.us> References: <20130425013317.36729.qmail@joyce.lan> <5179B10E.705@qti.qualcomm.com> <5179C72F.1070703@dougbarton.us> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 03:22:50 -0000 On Thursday, April 25, 2013 05:15:43 PM Doug Barton wrote: > 2. A report that Perl's "Mail::SPF (which is used by Spamassassin) > checks for Type SPF first by default." Mail::SPF is a library. The way that it makes SPF queries can (now) be controlled by the calling application. I maintain a small Perl application that acts as a Postfix policy server for doing SPF checks with Perl. Mail::SPF was written to be useful as a reference implementation and as a result, the author declined, initially to give calling applications the ability to control which types where queried for. This causes problems because not all DNS software will answer unknown query types. As a result, if you query for Type SPF first, you'll get a certain fraction of either timeouts or SERFVAIL responses while if you query for TXT, you get a response. It took quite some time to convince him to change it, but he did. Here's one bug report, to serve as an example: https://bugs.launchpad.net/postfix-policyd-spf-perl/+bug/161133 I report that a piece of software does something is interesting, however the fact that doing so causes interoperability problems supports the idea that it's a bad idea. Pushing for Type SPF queries first is only interesting if you're interested more in theoretical purism than actual interoperability. Scott K From superuser@gmail.com Thu Apr 25 20:29: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 AAFD121F9199; Thu, 25 Apr 2013 20:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3ukD6dX7rIj; Thu, 25 Apr 2013 20:29:16 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 640F721F9080; Thu, 25 Apr 2013 20:29:15 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id z53so3317417wey.9 for ; Thu, 25 Apr 2013 20:29:14 -0700 (PDT) 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=iCqwh+C9cFLLdVHFJpgFaPdNl1odqxj5zSBSviuQOAM=; b=aZ8Xs7PHzGWKoLka+oEFPW8FtPn7LOKZALTmqNdZOylb06pCp14fEPicVIkhmkSiWf ImEyv4b0lSRiZPVGdcpNAWgV5cmuHAJtUYbFDzHwmhQ6gowfBCAQj90m6KUQVwkm6kBH tM9FMDM0OmCVU1FMqlk5zO6dqAtFM7qvB0bQwcKblkLELSh6dR9zakiqj0DR5FXyQOIV SZYh00wb9LqzLy1n0LLeE7aTAhUS6rgalJPQfNdU5gkCaYO3kqV/b83IiyQjvoPjMmsr FaNQZg66VagoMnVrZr3hX/eARrxr+6WkPLVH2EcqsFKBmDnCXWlvpx2YZbWlRSEgdYtm VhXw== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr32118170wjb.17.1366946954561; Thu, 25 Apr 2013 20:29:14 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 25 Apr 2013 20:29:14 -0700 (PDT) In-Reply-To: <5179BC32.8050205@dougbarton.us> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> Date: Thu, 25 Apr 2013 20:29:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: Doug Barton Content-Type: multipart/alternative; boundary=047d7b5d8cffa74d6e04db3b2359 Cc: "spfbis@ietf.org" , Pete Resnick , dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 03:29:16 -0000 --047d7b5d8cffa74d6e04db3b2359 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 4:28 PM, Doug Barton wrote: > Yep, been there, done that. It was a bad decision then, and it's still a > bad decision now. I realize that it's incredibly unpopular to bluntly call > bad decisions "bad decisions," but not doing so doesn't make them any less > bad. And, to make matters worse, not doing so has led to a non-trivial > number of those bad decisions becoming de facto standards. This has at > least 2 very bad side effects ... first, we have to live with the bad de > facto standards; but more importantly we are providing encouragement to > people who wish to make similar bad decisions down the road. > > The argument in 6686 boils down to, "We made a series of bad decisions, > which have led to a bad result. We now want to codify that bad result > instead of cleaning up our mess." I don't agree with that in principle, and > I don't agree with that in regards to this particular case. > > Further, while cleaning up the SPF mess would require nothing more than a > marginal amount of extra work now, plus the passage of time, there is no > reason not to actually clean up the mess. I think this continues to trivialize exactly what it means to migrate the enormous deployed base of SPF in the manner you're pushing. I fully agree with your premise that it should've been "done right" in the beginning and I lament that it was not, but I don't agree that fixing this now is worth moving a mountain, especially when I don't believe the people saying that here will be among the people doing even a fraction of the moving. At least half of the reason we landed here is because of an environment that was basically hostile to doing it right in the first place. The rules for getting new RRtypes have been improved -- I think we all agree on that -- but, as you already conceded, there's still a large deployed base of faulty firewalls and DNS tools out there that don't exactly make use of uncommon RRtypes easy. So how much energy are the DNS experts going to put into cleaning up their house while demanding the mail people clean up theirs? I would even go so far as to say that the DNS part has to happen first, before any cleanup on the email side is practical to consider. The deployed SPF base probably won't give a damn if the IETF suddenly releases an RFC that exclaims "Everybody migrate to type 99!" From the perspective of large and small operators around the world, what's out there is working now, and messing with it is asking for pain; engineers' time to switch and debug costs a lot of money, so they have no incentive whatsoever to comply with a proposed change to "fix" a service that is philosophically broken but operationally just fine. Thus, I maintain that we take our licks on this one and just take steps to ensure that nobody follows this path again. -MSK --047d7b5d8cffa74d6e04db3b2359 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 4:28 PM, Doug Barton <dougb@dou= gbarton.us> wrote:
Yep, been there, done that. It was a bad dec= ision then, and it's still a bad decision now. I realize that it's = incredibly unpopular to bluntly call bad decisions "bad decisions,&quo= t; but not doing so doesn't make them any less bad. And, to make matter= s worse, not doing so has led to a non-trivial number of those bad decision= s becoming de facto standards. This has at least 2 very bad side effects ..= . first, we have to live with the bad de facto standards; but more importan= tly we are providing encouragement to people who wish to make similar bad d= ecisions down the road.

The argument in 6686 boils down to, "We made a series of bad decisions= , which have led to a bad result. We now want to codify that bad result ins= tead of cleaning up our mess." I don't agree with that in principl= e, and I don't agree with that in regards to this particular case.

Further, while cleaning up the SPF mess would require nothing more than a m= arginal amount of extra work now, plus the passage of time, there is no rea= son not to actually clean up the mess.

I think this continues to trivialize exactly what it means to migrate the e= normous deployed base of SPF in the manner you're pushing. I fully agre= e with your premise that it should've been "done right" in th= e beginning and I lament that it was not, but I don't agree that fixing= this now is worth moving a mountain, especially when I don't believe t= he people saying that here will be among the people doing even a fraction o= f the moving.

At least half of the reason we landed here is because of an = environment that was basically hostile to doing it right in the first place= .=A0 The rules for getting new RRtypes have been improved -- I think we all= agree on that -- but, as you already conceded, there's still a large d= eployed base of faulty firewalls and DNS tools out there that don't exa= ctly make use of uncommon RRtypes easy.=A0 So how much energy are the DNS e= xperts going to put into cleaning up their house while demanding the mail p= eople clean up theirs?=A0 I would even go so far as to say that the DNS par= t has to happen first, before any cleanup on the email side is practical to= consider.

The deployed SPF base probably won't give a damn if the = IETF suddenly releases an RFC that exclaims "Everybody migrate to type= 99!"=A0 From the perspective of large and small operators around the = world, what's out there is working now, and messing with it is asking f= or pain; engineers' time to switch and debug costs a lot of money, so t= hey have no incentive whatsoever to comply with a proposed change to "= fix" a service that is philosophically broken but operationally just f= ine.

Thus, I maintain that we take our licks on this one and just= take steps to ensure that nobody follows this path again.

-MSK
--047d7b5d8cffa74d6e04db3b2359-- From SRS0=u+bf7=ON==stuart@gathman.org Thu Apr 25 20:44: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 8972321E8040 for ; Thu, 25 Apr 2013 20:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 556vAGOO-Kbo for ; Thu, 25 Apr 2013 20:44:29 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id BBEDB21E803F for ; Thu, 25 Apr 2013 20:44:29 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (PLAIN sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1366947885; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=9S+Eon8wciQAHrZ2Cv+umLn47c9uD1eTugjfUukWw5Y=; b=mPeMYRH9ujXm1kXh6uaE0/5U1xgFAtutqukyWzzI9ndniMCY+9oRiHweizzMM5Gq0gpn/U /A7i0L2kDOTbP1D9ADRsZjkle7SyX3vjFuCumRI0dWTXbwxajhBmbvo0y6ybmdAe/ITC+NxE BEOKAN1Sg0ZNUiuu1L5eRnIyOK97Y= Received: from silver.gathman.org ([IPv6:2001:470:8:809:99bf:48b0:558b:1464]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3Q3idMO026063 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 25 Apr 2013 23:44:45 -0400 Message-ID: <5179F816.3080900@gathman.org> Date: Thu, 25 Apr 2013 23:44:22 -0400 From: Stuart Gathman Organization: BWI Corporation User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> In-Reply-To: <5179BC32.8050205@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 03:54:56 -0000 On 04/25/2013 07:28 PM, Doug Barton wrote: > > The topic has been raised numerous times since day 1 of SPF, and the > DNS folk who have said "the SPF RRtype should be the first (if not > only) choice" have been consistently ignored. > > Meanwhile, who said what when isn't the interesting part of the > discussion. The questions are simple: > > 1. What is the right thing to do? > 2. Can we do it? > > We know the answer to 1, and the answer to 2 is yes. So why are we > spending all of this time trying to find reasons not to do the right > thing? If as much energy had gone into fixing the problem as has gone > into justifying not fixing the problem, the problem would be fixed by > now. :) Unfortunately, the answer to 2 is no. There are still too many DNS servers out there that "hang" in response to a type 99 (or any other unexpected type) query. The only practical solution is to fire of both queries in parallel, and use the first to come back. But that *doubles* the DNS traffic, and I'm sure won't make the DNS people any happier. Here is something practical that might work: a "hall of shame" for DNS server/firewall vendors that hang on unexpected query types. When DNS servers actually work, then requiring a check of type 99 first makes sense. There is a chance to "do it right" with v=spf3 (a hypothetical future version of SPF - my favorite feature: a HELO mechanism that works like PTR but used the HELO name). From dougb@dougbarton.us Thu Apr 25 18:30: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 1698721F9731; Thu, 25 Apr 2013 18:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-PC6vWVnWcv; Thu, 25 Apr 2013 18:30:46 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [208.79.90.218]) by ietfa.amsl.com (Postfix) with ESMTP id 19AC321F9746; Thu, 25 Apr 2013 18:30:44 -0700 (PDT) Received: from [192.168.0.102] (home [12.207.105.210]) by dougbarton.us (Postfix) with ESMTPSA id D771922BAA; Fri, 26 Apr 2013 01:30:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1366939844; bh=U8WXo2UFoQyHjEDL+mg7IuRDArNSlCCCxqoXvER6ODE=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=excMj+QuChGFY+nJmvYfWftJOCPGS1WJCVExrX92ElhmsZolirxuR/SlTZ44n6fu6 rI9OGSeJrbTnLXIsmBZzdDRPq03bYkUmEVS2brwgtfqLriFWO1KP5U5+UBxdbolMX+ +ZJql+CCbZse3AJo8obNhHUu5XlIwcFji99SYRMQ= Message-ID: <5179D8C3.8090207@dougbarton.us> Date: Thu, 25 Apr 2013 18:30:43 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: S Moonesamy References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> In-Reply-To: <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 25 Apr 2013 22:34:09 -0700 Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 01:30:47 -0000 Note, I'm going to push back on some of the things you say below, but I don't want the main point I'm trying to make to get lost: 1. It's not too late to do the right thing, 2. So we should do that. Arguing about how we got here is fun and all, but not germane to the really important bit. On 04/25/2013 05:22 PM, S Moonesamy wrote: > Hi Doug, > At 16:28 25-04-2013, Doug Barton wrote: >> Yep, been there, done that. It was a bad decision then, and it's still >> a bad decision now. I realize that it's incredibly unpopular to >> bluntly call bad decisions "bad decisions," but not doing so doesn't >> make them any less bad. And, to make matters worse, > > I am ok if anyone says that it a bad decision. The thread for the > discussion started at > http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html > >> The argument in 6686 boils down to, "We made a series of bad >> decisions, which have led to a bad result. We now want to codify that >> bad result instead of cleaning up our mess." I don't agree with that >> in principle, and I don't agree with that in regards to this >> particular case. > > I was the document shepherd for RFC 6686. There wasn't any comments > during the Last Call. There are only so many times that people can say "this is a bad idea," then get ignored, and then have enthusiasm to come back and say the same thing again. I didn't follow the pre-publication of 6686, as I had other things to do at the time. However the volume of previous discussion over the last 8+ years should have been sufficient to render the idea of deprecating the SPF RRtype a non-starter. The fact that the draft got written in the first place said a lot about the chances of any objections being considered. >> https://www.ietf.org/mail-archive/web/ietf/current/msg72024.html is >> where the thread starts. There is another parallel thread an a related >> topic around that same time. > > I read the messages on that thread around the time they were posted. > >> https://www.ietf.org/mail-archive/web/ietf/current/msg72085.html > > I also read those messages. > >> The topic has been raised numerous times since day 1 of SPF, and the >> DNS folk who have said "the SPF RRtype should be the first (if not >> only) choice" have been consistently ignored. > > I have to respectfully mention that I read all the messages that were > posted to the SPFBIS mailing list. I cannot take into consideration > comments posted to ietf@ if they are not part of the Last Call. I have to respectfully point out that a) there is a wider world beyond spfbis, and b) the reasoned technical arguments that were presented on the list (not to mention the running code) should have been sufficient to push the group in the direction of preferring the SPF RRtype with an eye toward deprecating TXT in the future. I don't know why, specifically, that didn't happen; but I also don't care. What I want to see happen is that we do the right thing now. >> But what if all of the previous discussion was wrong? Simply saying >> "we have discussed this extensively" doesn't refute sound technical >> arguments either. :) > > If all the previous discussions were wrong I hope that the future > discussions will be right. :-) Voila! :) >> While I didn't follow the spfbis group, I have followed SPF from the >> time before it was > > You missed > http://www.ietf.org/mail-archive/web/spfbis/current/msg01440.html :-) > > At 17:15 25-04-2013, Doug Barton wrote: >> 5. Some fairly persuasive technical arguments from Andrew Sullivan >> that putting SPF records into your zone is a good idea. Particularly >> this: >> https://www.ietf.org/mail-archive/web/spfbis/current/msg00544.html > > [snip] > >> #5 Is also a "reasoned technical argument," which was not only >> ignored, but twisted on its ear by at least one list member. > > The SPFBIS WG Chairs are the persons making the determination for > discussions within the working group. I happen to be one of the SPFBIS > WG co-chairs and the other co-chair is Andrew Sullivan. I didn't ignore > his comments. I didn't ask Andrew Sullivan whether he ignored his > comments. If I misunderstood or misinterpreted his comments he would > likely talk to me about that. That makes it unlikely that any twisting > would reach my ears. :-) It wasn't any of your messages I was referring to. Doug From drc@virtualized.org Thu Apr 25 23:05: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 8987A21F97C7; Thu, 25 Apr 2013 23:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Quedfh9U5ke; Thu, 25 Apr 2013 23:05:23 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8BD21F97AF; Thu, 25 Apr 2013 23:05:23 -0700 (PDT) Received: from [10.0.1.2] (unknown [12.6.90.3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id B944E17166; Fri, 26 Apr 2013 06:05:22 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: Date: Fri, 26 Apr 2013 01:05:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Thu, 25 Apr 2013 23:12:20 -0700 Cc: spfbis@ietf.org, "dnsext@ietf.org Group" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 06:05:23 -0000 Murray, On Apr 25, 2013, at 10:29 PM, "Murray S. Kucherawy" = wrote: > I think this continues to trivialize exactly what it means to migrate = the enormous deployed base of SPF in the manner you're pushing. Out of curiosity, what do folks who follow SPF think the current = "enormous deployed base" is compared to the future deployed base? > At least half of the reason we landed here is because of an = environment that was basically hostile to doing it right in the first = place.=20 Well, deprecating the SPF RR will certainly teach the DNSEXT/IESG/IETF = community a good lesson. (Seriously?) > So how much energy are the DNS experts going to put into cleaning up = their house while demanding the mail people clean up theirs?=20 So, this is about revenge because it used to be hard to get RRtypes?=20 > The deployed SPF base probably won't give a damn if the IETF suddenly = releases an RFC that exclaims "Everybody migrate to type 99!"=20 Yep. This gets into projections about the future. If SPF has topped = out, it simply doesn't matter. If SPF is going to continue to grow, = then it probably does matter. > =46rom the perspective of large and small operators around the world, = what's out there is working now, and messing with it is asking for pain; = engineers' time to switch and debug costs a lot of money, so they have = no incentive whatsoever to comply with a proposed change to "fix" a = service that is philosophically broken but operationally just fine. The point is that it isn't just fine. It does have operational impacts, = from potentially increased fragmentation/fallback to TCP to increased = complexity in TXT RR parsers that have to distinguish between the myriad = of crap that's residing at the zone apex TXT RR, etc. Of course, most = of these negative impacts are hidden to the folks who are putting the = TXT RRs in the zone, so it's all good, right? > Thus, I maintain that we take our licks on this one and just take = steps to ensure that nobody follows this path again. And how do you propose that exactly, particularly given the precedent = set by SPFBIS? Regards, -drc From superuser@gmail.com Thu Apr 25 23:30: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 11AB621F91A2; Thu, 25 Apr 2013 23:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxMwzbcy2enj; Thu, 25 Apr 2013 23:30:15 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id C854C21F91B7; Thu, 25 Apr 2013 23:30:14 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hm14so213877wib.5 for ; Thu, 25 Apr 2013 23:30:13 -0700 (PDT) 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=qkKxxbS61c+29IzFzh2ux1pgevJn908JuLVXQ7A2hXg=; b=MbUqrqf1wE9/nNlZ08qaiyjcKrz1Ndwz0Qr8hZ2dmQcRG+5IbUl1IWQEAkqTw4xWbD u5kBnRR8RIqoQ2U91XUEeXyJtKz9V4Z7Eobj/P6knOSTO2aQ4vOKC0hrSIwK2pDRQ4Xe OQdysmlAvMPJHktVyNF+oQm+GcyR75jluMFcp5+fv9MjpeZoYp/SsOoxn+nKD2dC0Bio lYjqjZFAAtLApnHZvkiL75CiXl0TWGaExJJKhDT6SSfSebTnzN0W74T6k3ouagymeJAc vMtFGNknpP4QG4XRjCb1NW0NxA5bxdMFgSbogGhHY0bpQd+5Vomxvyb7eZld6K+AQkIB /m+A== MIME-Version: 1.0 X-Received: by 10.180.37.101 with SMTP id x5mr2317657wij.0.1366957813404; Thu, 25 Apr 2013 23:30:13 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 25 Apr 2013 23:30:13 -0700 (PDT) In-Reply-To: <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> Date: Thu, 25 Apr 2013 23:30:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: David Conrad Content-Type: multipart/alternative; boundary=e89a8f646ff3e4184a04db3daa27 Cc: "spfbis@ietf.org" , "dnsext@ietf.org Group" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 06:30:16 -0000 --e89a8f646ff3e4184a04db3daa27 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 25, 2013 at 11:05 PM, David Conrad wrote: > > So how much energy are the DNS experts going to put into cleaning up > their house while demanding the mail people clean up theirs? > > So, this is about revenge because it used to be hard to get RRtypes? > Did I really come across as that petty? No, what I'm saying is that the way things were ten years ago pushed the SPF community to the place it's in now, ugly as it is. SPF, in the interim, has become very widely deployed. Suddenly now we have a few voices from the ivory tower asserting that the same community needs to go out and re-do things the way they should have been done in the first place, now that we finally have a somewhat more reasonable perspective, even though some of the vestiges of ten years ago are in fact still around. My reaction to that is "You can't be serious." That doesn't sound like revenge at all to me, just pragmatism. > > The deployed SPF base probably won't give a damn if the IETF suddenly > releases an RFC that exclaims "Everybody migrate to type 99!" > > Yep. This gets into projections about the future. If SPF has topped out, > it simply doesn't matter. If SPF is going to continue to grow, then it > probably does matter. > I think it's much closer to the former. > The point is that it isn't just fine. It does have operational impacts, > from potentially increased fragmentation/fallback to TCP to increased > complexity in TXT RR parsers that have to distinguish between the myriad of > crap that's residing at the zone apex TXT RR, etc. Of course, most of > these negative impacts are hidden to the folks who are putting the TXT RRs > in the zone, so it's all good, right? > > > Thus, I maintain that we take our licks on this one and just take steps > to ensure that nobody follows this path again. > > And how do you propose that exactly, particularly given the precedent set > by SPFBIS? > Someone else (Joe, I think) has already referred to other RFCs that talk about things like IAB advice about how [not] to put application data into the DNS. Seems to me this is a perfectly good subject for another such project. One may counter that by saying nobody will pay attention to such a document, but I submit that it's our primary mechanism for making sure mistakes aren't re-made, so that's the tool we have to use or not use. If we do the opposite and somehow compel SPFBIS to favour type 99 over TXT, then I still think we'll be shouting that to an audience that will think we're nuts and simply go about their business. -MSK --e89a8f646ff3e4184a04db3daa27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2013 at 11:05 PM, David Conrad <drc@v= irtualized.org> wrote:
> So how much energy are the DNS experts = going to put into cleaning up their house while demanding the mail people c= lean up theirs?

So, this is about revenge because it used to be hard to get RRtypes?<= br>

Did I really come across as that petty?=

No, what I'm saying is that the way things were ten = years ago pushed the SPF community to the place it's in now, ugly as it= is.=A0 SPF, in the interim, has become very widely deployed.=A0 Suddenly n= ow we have a few voices from the ivory tower asserting that the same commun= ity needs to go out and re-do things the way they should have been done in = the first place, now that we finally have a somewhat more reasonable perspe= ctive, even though some of the vestiges of ten years ago are in fact still = around.=A0 My reaction to that is "You can't be serious."=A0 = That doesn't sound like revenge at all to me, just pragmatism.


> The deployed SPF base probably won't give a damn if the IETF sudde= nly releases an RFC that exclaims "Everybody migrate to type 99!"=

Yep. =A0This gets into projections about the future. =A0If SPF has to= pped out, it simply doesn't matter. =A0If SPF is going to continue to g= row, then it probably does matter.

I th= ink it's much closer to the former.
=A0
The point is that it isn't just fine. =A0It does have= operational impacts, from potentially increased fragmentation/fallback to = TCP to increased complexity in TXT RR parsers that have to distinguish betw= een the myriad of crap that's residing at the zone apex TXT RR, etc. = =A0Of course, most of these negative impacts are hidden to the folks who ar= e putting the TXT RRs in the zone, so it's all good, right?

> Thus, I maintain that we take our licks on this one and just take step= s to ensure that nobody follows this path again.

And how do you propose that exactly, particularly given the precedent= set by SPFBIS?

Someon= e else (Joe, I think) has already referred to other RFCs that talk about th= ings like IAB advice about how [not] to put application data into the DNS.= =A0 Seems to me this is a perfectly good subject for another such project.= =A0 One may counter that by saying nobody will pay attention to such a docu= ment, but I submit that it's our primary mechanism for making sure mist= akes aren't re-made, so that's the tool we have to use or not use.<= br>

If we do the opposite and someho= w compel SPFBIS to favour type 99 over TXT, then I still think we'll be= shouting that to an audience that will think we're nuts and simply go = about their business.

-MSK
--e89a8f646ff3e4184a04db3daa27-- From mansaxel@besserwisser.org Fri Apr 26 00:44: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 D733521F91BC for ; Fri, 26 Apr 2013 00:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fL+D7YUrA6f for ; Fri, 26 Apr 2013 00:44:17 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id BF19C21F8618 for ; Fri, 26 Apr 2013 00:44:16 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id A28B99EF0; Fri, 26 Apr 2013 09:44:14 +0200 (CEST) Date: Fri, 26 Apr 2013 09:44:14 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Scott Kitterman Message-ID: <20130426074414.GR23770@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <5179B10E.705@qti.qualcomm.com> <5179C72F.1070703@dougbarton.us> <1998649.x7xmPiSjvn@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ECF1u7dKBoUGhe3" Content-Disposition: inline In-Reply-To: <1998649.x7xmPiSjvn@scott-latitude-e6320> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 07:44:17 -0000 --4ECF1u7dKBoUGhe3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Thu, Apr 25, 2= 013 at 11:22:39PM -0400 Quoting Scott Kitterman (spf2@kitterman.com): > On Thursday, April 25, 2013 05:15:43 PM Doug Barton wrote: > > 2. A report that Perl's "Mail::SPF (which is used by Spamassassin)=20 > > checks for Type SPF first by default." >=20 > Mail::SPF is a library. The way that it makes SPF queries can (now) be= =20 > controlled by the calling application. I maintain a small Perl applicati= on=20 > that acts as a Postfix policy server for doing SPF checks with Perl. >=20 > Mail::SPF was written to be useful as a reference implementation and as a= =20 > result, the author declined, initially to give calling applications the= =20 > ability to control which types where queried for. This causes problems= =20 > because not all DNS software will answer unknown query types. As a resul= t, if=20 > you query for Type SPF first, you'll get a certain fraction of either tim= eouts=20 > or SERFVAIL responses while if you query for TXT, you get a response. >=20 > It took quite some time to convince him to change it, but he did. Here's= one=20 > bug report, to serve as an example: >=20 > https://bugs.launchpad.net/postfix-policyd-spf-perl/+bug/161133 >=20 > I report that a piece of software does something is interesting, however = the=20 > fact that doing so causes interoperability problems supports the idea tha= t=20 > it's a bad idea. Pushing for Type SPF queries first is only interesting = if=20 > you're interested more in theoretical purism than actual interoperability. Tl;dr: "Overloading TXT is bad, lets fix this mess once and for all" 1. Parsing TXT records and keeping a lookout for various almost SPF (but not) data (which is legal in TXT) is hard. In the way open-ended text parsing is. Lots of security holes in that problem vector. It makes sense to remove this scenario as much as possible. 2. Writing code to do the equivalent of:=20 if (exists SPF record) { parse and return verdict;=20 } else if ( exists TXT record ) { parse and return verdict;=20 } else {=20 return no data } =2E..is not very hard. Of course, we'll enter the open-ended parser quite often today, with this code, but given that That Vendor Which I'll Not Name gets its act together, that frequency will decrease. All the way, we'll maintain interoperability. Automatically. And this is if not pure (not doing TXT from the start would be pure, I'm trying to stop the silt =66rom clogging the drain here, so purity is long gone.) at least the proper way to clean up a mess. 3. As a DNS operator (and also running mail gw for employer and myself) I look at the SPF problem like this: 3a. Having to query twice (in the case of ask-for-SPF-first-and-then-TXT) is something that is -- to me -- bearable, more so since this is something that our friend the Computer can do automatically. Moore's law will make this less of a problem in the future, as code gets corrected. Also, think= =20 of caching. Sensible TTL will -- providing full-service resolvers are implemented to make use of caching -- in practice remove the expensive part of double-querying, at least where this could be a problem, in heavily loaded mail gateways. 3b. Not all uses of TXT records are automated. Having structured data in TXT records messes up my manual parsing of other TXT records that may exist on the same node. (or dig zone.tld. axfr |=C2=A0grep TXT) This usage does not benefit from the capacity increase according to Moore. 4. Having thus established that TXT overloading is bad, in this specific case, we must turn to the general case. In the general case, TXT overloading is bad. Why? Simply, because the above discussion applies to all those cases as well. (Ok, lots of handwaving here, but I'm right.) 5. Then with the conclusion that TXT overloading is bad, we can turn to the setting of a precedent. Which this discussion actually is all about; the presence of TXT records with alleged meaning and some syntax is undisputed. We already are are in damage-control mode here. Setting the precedent that caving in and ignoring the bad effects of overloading TXT because of reasons of defaitism is not how the IETF should do this. So: I oppose the publication of any text deprecating a specific RR type in favour of overloading a generic free-form RR. Because overloading TXT is bad. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 =2E.. I think I'd better go back to my DESK and toy with a few common MISAPPREHENSIONS ... --4ECF1u7dKBoUGhe3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF6ME4ACgkQ02/pMZDM1cV3pgCfQqeWHzw7HLFmQM1aKdQJO4jS 5ukAoJfhDXW1TJ/BRtAA3PziH6pRtAKb =xkFS -----END PGP SIGNATURE----- --4ECF1u7dKBoUGhe3-- From marka@isc.org Thu Apr 25 23:52: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 68C6B21F97D1; Thu, 25 Apr 2013 23:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9aaE7ipexBL; Thu, 25 Apr 2013 23:52:42 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6F05121F97BF; Thu, 25 Apr 2013 23:52:41 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 395FA5F98E9; Fri, 26 Apr 2013 06:52:29 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366959158; bh=7tJjS48HL6RtN7auaCrBHrzhQ3/OaPOuqXLKM23DvaY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=OelgbkhzB2FvIc9gpyVXS0g+mZW37M8wohD8b8z//jXHYr7qarKZTP4vGn/cgLk4w SckoHq6yGE/EGZ+XVB2lv0QWs4ZCsdggQIZuZB/nUnYn53WLOe39v3yrdNzqpA/GWX Qj3CTXVEOqoFiUzMg9uxrhkFSizKX4l72U0hpmf0= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4129:b64c:428a:9207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id BC395216C40; Fri, 26 Apr 2013 06:52:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id D8E8133032DC; Fri, 26 Apr 2013 16:52:21 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> In-reply-to: Your message of "Thu, 25 Apr 2013 20:29:14 -0700." Date: Fri, 26 Apr 2013 16:52:21 +1000 Message-Id: <20130426065221.D8E8133032DC@drugs.dv.isc.org> X-Mailman-Approved-At: Fri, 26 Apr 2013 01:04:18 -0700 Cc: "spfbis@ietf.org" , Pete Resnick , Doug Barton , dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 06:52:45 -0000 In message , "Murray S. Kucherawy" writes: > > On Thu, Apr 25, 2013 at 4:28 PM, Doug Barton wrote: > > > Yep, been there, done that. It was a bad decision then, and it's still a > > bad decision now. I realize that it's incredibly unpopular to bluntly call > > bad decisions "bad decisions," but not doing so doesn't make them any less > > bad. And, to make matters worse, not doing so has led to a non-trivial > > number of those bad decisions becoming de facto standards. This has at > > least 2 very bad side effects ... first, we have to live with the bad de > > facto standards; but more importantly we are providing encouragement to > > people who wish to make similar bad decisions down the road. > > > > The argument in 6686 boils down to, "We made a series of bad decisions, > > which have led to a bad result. We now want to codify that bad result > > instead of cleaning up our mess." I don't agree with that in principle, and > > I don't agree with that in regards to this particular case. > > > > Further, while cleaning up the SPF mess would require nothing more than a > > marginal amount of extra work now, plus the passage of time, there is no > > reason not to actually clean up the mess. > > > I think this continues to trivialize exactly what it means to migrate the > enormous deployed base of SPF in the manner you're pushing. I fully agree > with your premise that it should've been "done right" in the beginning and > I lament that it was not, but I don't agree that fixing this now is worth > moving a mountain, especially when I don't believe the people saying that > here will be among the people doing even a fraction of the moving. The installed base of SPF is miniscule. As for moving it, you really only need to update a couple MTA's to use the SPF libraries that look for SPF first and let time pass. If you want a hurry on one could add code to nameservers and zone signers to detected TXT style spf records and add SPF records if they are missing. > At least half of the reason we landed here is because of an environment > that was basically hostile to doing it right in the first place. The rules > for getting new RRtypes have been improved -- The rules were dead simple at the time, just nobody in the SPF camp was willing to try to go down that route. I know they were simple because I used them at the time for another type. > I think we all agree on that > -- but, as you already conceded, there's still a large deployed base of > faulty firewalls and DNS tools out there that don't exactly make use of > uncommon RRtypes easy. So how much energy are the DNS experts going to put > into cleaning up their house while demanding the mail people clean up > theirs? I would even go so far as to say that the DNS part has to happen > first, before any cleanup on the email side is practical to consider. The DNS had deployed support for UNKNOWN RR types at the time. Most resolvers have been able to lookup unknown types since RFC 1034 was published. For most resolvers it was simply a matter of using 99 rather than a symbolic name. > The deployed SPF base probably won't give a damn if the IETF suddenly > releases an RFC that exclaims "Everybody migrate to type 99!" From the > perspective of large and small operators around the world, what's out there > is working now, and messing with it is asking for pain; engineers' time to > switch and debug costs a lot of money, so they have no incentive whatsoever > to comply with a proposed change to "fix" a service that is philosophically > broken but operationally just fine. > > Thus, I maintain that we take our licks on this one and just take steps to > ensure that nobody follows this path again. > > -MSK -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@elandsys.com Fri Apr 26 02:03: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 E10EF21F97D3; Fri, 26 Apr 2013 02:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3owoQrR41GG; Fri, 26 Apr 2013 02:03:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4B621F97C9; Fri, 26 Apr 2013 02:03:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.115]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3Q92i2G007268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Apr 2013 02:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366966977; bh=gW+kdAjlRGcjp+2QjQjCLOnZbi3VKvHBRy5DmVRzSmg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W5mD3dD0DnhVS7iZs+q66/1c87YvnbiFLPpnf01y821QDTiBnxa55SuKP4R/QsJlH MHm9E0uo/2KYy04i1K5OwZj68xatXS1RNiTR6fdch5QKKgg872FUlLbTwFNOMCtrr6 MY7U/lLPS9oab0W3tu+bMorzcAcYF2GWTzO+yd2I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366966977; i=@elandsys.com; bh=gW+kdAjlRGcjp+2QjQjCLOnZbi3VKvHBRy5DmVRzSmg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3n5mf3CJbdJ963XByMCKp4qzK/13cKSjqWYzJ3fwx+BaX9f5ynhjaGsY4ss/TDJA7 5S4JEgrBjXoKcOtwqpkqEtFrACb+CIleeat2ldPfrkB22OEtey92otkYlzZpZlK9Mu SDeRZkSARwDOegCKJr3/5WCiPAQ4XGiz9V2w3RLM= Message-Id: <6.2.5.6.2.20130425230637.0d0010e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 26 Apr 2013 01:28:14 -0700 To: Doug Barton From: S Moonesamy In-Reply-To: <5179D8C3.8090207@dougbarton.us> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <5179D8C3.8090207@dougbarton.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 09:03:04 -0000 Hi Doug, At 18:30 25-04-2013, Doug Barton wrote: >Note, I'm going to push back on some of the things you say below, >but I don't want the main point I'm trying to make to get lost: > >1. It's not too late to do the right thing, >2. So we should do that. I'll comment below. >There are only so many times that people can say "this is a bad >idea," then get ignored, and then have enthusiasm to come back and >say the same thing again. I didn't follow the Ok. > pre-publication of 6686, as I had other things to do at the time. > However the volume of previous discussion over the last 8+ years > should have been sufficient to render the idea of deprecating the > SPF RRtype a non-starter. The fact that the draft got written in > the first place said a lot about the chances of any objections > being considered. When the work started nobody knew what to do. The following comment was made around a year ago: "the IESG would simply like to see the SPF *and* Sender-ID experiments wrapped up, and presumes that the charter is correct and the outcome of the experiment leads one to conclude that SPF should get advanced to Proposed Standard and Sender-ID should not". In easy terms, it would be good to have a conclusion to those experiments. There was an assumption, i.e. SPF would get advanced. My guess (not technically sound) was that there was a higher chance of that happening (e.g. see http://www.ietf.org/mail-archive/web/spfbis/current/msg00355.html ). There is a short discussion predating Issue #9 (see http://www.ietf.org/mail-archive/web/spfbis/current/msg00329.html ). Philip Gladstone provided some data (see http://www.ietf.org/mail-archive/web/spfbis/current/msg00354.html ). Issue #9 was opened based on the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00361.html draft-kucherawy-spfbis-experiment was posted after that (see http://www.ietf.org/mail-archive/web/spfbis/current/msg00405.html ). There were comments mentioning the ietf@ discussion ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00789.html ). Anyway, the working group decision about the protocol aspect was made based on the analysis. The question of whether to obsolete the SPF RRTYPE or not is an administrative issue. That is why it is in the IANA Considerations Section of draft-ietf-spfbis-4408bis-14. I am ok with whatever the IETF decides about that. There are several intermingled issues. If I understood correctly the main issue is which DNS RR to use to publish SPF information in the DNS. I suggest discussing about that during the Last Call for draft-ietf-spfbis-4408bis. >I have to respectfully point out that a) there is a wider world >beyond spfbis, and b) the reasoned technical arguments that were >presented on the list (not to mention the running code) should have >been sufficient to push the group in the direction of preferring the >SPF RRtype with an eye toward deprecating TXT in the future. I am aware of that. :-) There isn't much I can do about it. My task was to give due consideration to all the arguments that were presented on this mailing list. Technical arguments are obviously more compelling. If there are any new arguments which have been missed please let me know as I can include them in my write-up. If the argument is solely "do the right thing" I will decline including it in the write-up as it is, in my individual opinion, non-technical. I cannot comment on what arguments should be provided as I will then be biasing the outcome. Regards, S. Moonesamy From vesely@tana.it Fri Apr 26 03:13: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 47EA921F9605 for ; Fri, 26 Apr 2013 03:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8Gg65o+1vzC for ; Fri, 26 Apr 2013 03:13:27 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id EFD7721F93D7 for ; Fri, 26 Apr 2013 03:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366971205; bh=mllDew7atIMid5Q7GG/fuei0efptKHEZIjwUoegh+2k=; l=1353; h=Date:From:To:References:In-Reply-To; b=P0eL62UOAFbe6yi3f22LwqNbqIMB+sOV1wJKeRzFOe98kyeeT5IJXaf26F+zUfihT sXZgjDuL2/w5IqTZ3nkUbBDOiIFNfU4F06Lf6T6oDeBHYVmlyMGsTcdiAvLv1V8GWo 6vJZcl2+Da/klx6/xVoY9ODYu/9qzF9P3uKKqivw= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 26 Apr 2013 12:13:25 +0200 id 00000000005DC035.00000000517A5345.000010F7 Message-ID: <517A5345.8090008@tana.it> Date: Fri, 26 Apr 2013 12:13:25 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <20130424160954.GA31835@simplex.0x539.de> <517807E7.2050005@viagenie.ca> <1620648.vNPTWAe3vH@scott-latitude-e6320> <51780DCC.7020802@viagenie.ca> In-Reply-To: <51780DCC.7020802@viagenie.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 26 Apr 2013 10:13:28 -0000 On Wed 24/Apr/2013 18:52:28 +0200 Simon Perreault wrote: > Le 2013-04-24 18:46, Scott Kitterman a écrit : >> So from your perspective, we could remove that guidance and replace >> it with something along the lines of: >> >> Check_host() [that's our generic SPF validation function name >> we use in the document] should never see IPv4-mapped IPv6 >> addresses. The underlying layer needs to convert them to >> IPv4 addresses. >> >> Is that about right? > > Yes, that's perfect. > > Now, there's nothing specific to SPF here, but I don't know of any > general guidelines that you could reference, so feel free to go > ahead with that. It is not clear to me what underlying layer we'd refer to. The kernel obviously cannot do that if the socket is IPv6. If we remove from Section 5 the sentence: SPF implementations on IPv6 servers need to handle both "AAAA" and "A" secords, for clients on IPv4 mapped IPv6 addresses [RFC4291]. Then, IMHO, we should append to Section 4.3 *Initial Processing* a paragraph like: If the is an IPv4-mapped IPv6 address [RFC4291], substitute it with a true IPv4 address of that value. In that case, the sentence: IPv4 addresses are only listed in an SPF record using the "ip4" mechanism. should be moved from Section 5 to Section 5.6 *"ip4" and "ip6"* jm2c From vesely@tana.it Fri Apr 26 03:13: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 8CC0021F97EE for ; Fri, 26 Apr 2013 03:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXUfALvGCaLp for ; Fri, 26 Apr 2013 03:13:56 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E88B521F976A for ; Fri, 26 Apr 2013 03:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366971235; bh=1O9jLqLl2TzX5mMGdl5KAs2wzTVvuxZ9W90EWgEKKTY=; l=895; h=Date:From:To:References:In-Reply-To; b=Qgj9vGel3/XGbPg5jc+SXoWwUSCO43RAwIdXQ8bv/wg3OfTdwhUdu9tpPB8PDVgdy E2x89SOFPvDtNJPx5KaynDVBPbR/M6boPxZM2Dshpa0SzQZpsW/UbR+ZWozbq/rS3F 9MiqCzD3TBxn9MTTTgBdrzWFbIuUR8ufIcRiw5GE= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 26 Apr 2013 12:13:55 +0200 id 00000000005DC035.00000000517A5363.0000135E Message-ID: <517A5363.6060902@tana.it> Date: Fri, 26 Apr 2013 12:13:55 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <51726641.7070606@tana.it> <51791042.9030800@tana.it> <1818071.XgB9D1drlR@scott-latitude-e6320> In-Reply-To: <1818071.XgB9D1drlR@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 26 Apr 2013 10:13:56 -0000 On Thu 25/Apr/2013 16:05:04 +0200 Scott Kitterman wrote: > On Thursday, April 25, 2013 06:57:54 AM Murray S. Kucherawy wrote: >>> In fact, Section 4.3 already says: >>> If the has no local-part, substitute the string >>> "postmaster" for the local-part. >>> >>> How come it has no local part? We don't need to do it twice. The >>> former sentence is a "shortcut" to say that checking HELO is required >>> when MAIL FROM is null. >> >> What about macro evaluation? > > Macro evaluation is precisely why that's there. I still cannot figure out how it is possible to get a sender with no local part (except malformed MAIL FROM). Both Section 5.2 and 6.1 say: The and arguments remain the same as in the current evaluation of check_host(). So it seems that if has a local part initially, it will never go away. Any example to the contrary? From spf2@kitterman.com Fri Apr 26 05:38: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 EBD9521F983F for ; Fri, 26 Apr 2013 05:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slh0pt4z8Lft for ; Fri, 26 Apr 2013 05:38:34 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 24EB621F97E3 for ; Fri, 26 Apr 2013 05:38:34 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1DEEB20E40D5; Fri, 26 Apr 2013 08:38:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366979913; bh=/bpmKbW9Za2QDJb+EVWzgfahLmMntIY0k3DGKkDffUU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lBK6mqcTqU6fFrBAqO+CZhtcKwFNf6qOrgBjjjzsqSI4OOA7IKo3QAFwfPtN8qiCC sjgeDmYmZFlsmUHFbtpINwuONJ3Dj0TYH/rXdMe+BZAKKPJQ3RbDi3i2BcJ6V0zydT U5UOnvu8twY/nAtnrz1nBHWcd6ejMml3nn/vUFUU= 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 06CF920E40CF; Fri, 26 Apr 2013 08:38:22 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 08:38:21 -0400 Message-ID: <1845397.bn79S9oqEB@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <517A5363.6060902@tana.it> References: <51726641.7070606@tana.it> <1818071.XgB9D1drlR@scott-latitude-e6320> <517A5363.6060902@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] New issue: 8.4. Fail: rejection is not described explicitly 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, 26 Apr 2013 12:38:35 -0000 On Friday, April 26, 2013 12:13:55 PM Alessandro Vesely wrote: > On Thu 25/Apr/2013 16:05:04 +0200 Scott Kitterman wrote: > > On Thursday, April 25, 2013 06:57:54 AM Murray S. Kucherawy wrote: > >>> In fact, Section 4.3 already says: > >>> If the has no local-part, substitute the string > >>> "postmaster" for the local-part. > >>> > >>> How come it has no local part? We don't need to do it twice. The > >>> former sentence is a "shortcut" to say that checking HELO is required > >>> when MAIL FROM is null. > >> > >> What about macro evaluation? > > > > Macro evaluation is precisely why that's there. > > I still cannot figure out how it is possible to get a sender with no > local part (except malformed MAIL FROM). Both Section 5.2 and 6.1 say: > > The and arguments remain the same > as in the current evaluation of check_host(). > > So it seems that if has a local part initially, it will never > go away. Any example to the contrary? If mail from is null, you substitute HELO for mail from. Mail From has no localpart. You need to have something to use in case there is an "l" macro expansion in the record. Scott K From spf2@kitterman.com Fri Apr 26 05:48: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 4A92A21F9914 for ; Fri, 26 Apr 2013 05:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wIe7nuuU1KV for ; Fri, 26 Apr 2013 05:48:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 412B321F9907 for ; Fri, 26 Apr 2013 05:48:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AA94920E40D5; Fri, 26 Apr 2013 08:48:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366980521; bh=IBfw217CrbDsCx5LTTJe4QYtfXt9KmA1nPIsXnMSIdw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LLjUWPluJkI1nkTnkzvnvC+MX9a95Y/+13uOdijOuZB///UcH8HjciYIjGHbtEZIA /kX/aC8DwBBjTupSRUz+/DWsLpkDhUmCBJeg/KsEVogrvhfmzloDag6x1T1x+bhv9w dm5UpFK6hoFUpm7ENTT4PPgu1d6IgKMUsBm5uQ8A= 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 94CED20E40CF; Fri, 26 Apr 2013 08:48:41 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 08:48:40 -0400 Message-ID: <6703991.tZ8WHlYQKG@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <20130425013317.36729.qmail@joyce.lan> <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.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] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 12:48:43 -0000 On Thursday, April 25, 2013 11:30:13 PM Murray S. Kucherawy wrote: > On Thu, Apr 25, 2013 at 11:05 PM, David Conrad wrote: > > > So how much energy are the DNS experts going to put into cleaning up > > > > their house while demanding the mail people clean up theirs? > > > > So, this is about revenge because it used to be hard to get RRtypes? > > Did I really come across as that petty? > > No, what I'm saying is that the way things were ten years ago pushed the > SPF community to the place it's in now, ugly as it is. SPF, in the > interim, has become very widely deployed. Suddenly now we have a few > voices from the ivory tower asserting that the same community needs to go > out and re-do things the way they should have been done in the first place, > now that we finally have a somewhat more reasonable perspective, even > though some of the vestiges of ten years ago are in fact still around. My > reaction to that is "You can't be serious." That doesn't sound like > revenge at all to me, just pragmatism. > > > > The deployed SPF base probably won't give a damn if the IETF suddenly > > > > releases an RFC that exclaims "Everybody migrate to type 99!" > > > > Yep. This gets into projections about the future. If SPF has topped out, > > it simply doesn't matter. If SPF is going to continue to grow, then it > > probably does matter. > > I think it's much closer to the former. > > > The point is that it isn't just fine. It does have operational impacts, > > from potentially increased fragmentation/fallback to TCP to increased > > complexity in TXT RR parsers that have to distinguish between the myriad > > of > > crap that's residing at the zone apex TXT RR, etc. Of course, most of > > these negative impacts are hidden to the folks who are putting the TXT RRs > > in the zone, so it's all good, right? > > > > > Thus, I maintain that we take our licks on this one and just take steps > > > > to ensure that nobody follows this path again. > > > > And how do you propose that exactly, particularly given the precedent set > > by SPFBIS? > > Someone else (Joe, I think) has already referred to other RFCs that talk > about things like IAB advice about how [not] to put application data into > the DNS. Seems to me this is a perfectly good subject for another such > project. One may counter that by saying nobody will pay attention to such > a document, but I submit that it's our primary mechanism for making sure > mistakes aren't re-made, so that's the tool we have to use or not use. > > If we do the opposite and somehow compel SPFBIS to favour type 99 over TXT, > then I still think we'll be shouting that to an audience that will think > we're nuts and simply go about their business. I think it's also important to reflect on the interoperability issue that led us to seriously consider removing type SPF. In RFC 4408 you can publish either SPF or TXT and you can check either SPF or TXT and be compliant with the spec. There is no common format that is required to publish/check so it's possible based on just reading the document for some people to decide to check only one type and for publishers to only publish the other resulting in NO interoperability. The first step then was to consider this issue and conclude that specifying one of the two as mandatory to publish/check was essential for interoperability. The second step what to decide which. Looking at the deployed base it didn't take a great stretch to realize that trying to order the whole internet to change to type SPF was silly and that TXT was the only thing that made sense. The third step then was to consider if there was any point in maintaining duplicate data and doing duplicate checks for something that is known to (still) be problematic for interoperation and has effectively no deployment. We concluded it didn't. Scott K From spf2@kitterman.com Fri Apr 26 06:02: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 2A87A21F98F5 for ; Fri, 26 Apr 2013 06:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l3HLpZN0zVj for ; Fri, 26 Apr 2013 06:02:26 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E6EB821F98E4 for ; Fri, 26 Apr 2013 06:02:25 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 74D7D20E40D5; Fri, 26 Apr 2013 09:02:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366981342; bh=xyHFMtXYDQYtFtoSaqlapI4dUVpt0rBa2oYXvGNsWB4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KkDEFebGH9F/lYBqXCbhOVJ/+EmGt/XljyVRasiqnEyyTiizfW/RAqR6uWQsC+po4 BeJdQeLUChbdOazwRmI91304D4+FMue3bihWFXitGhfaD2SJBm40m3jqKUTdGbqid+ iV7+gEwfHHPfuk+Uwz2rlXkssoDP9bgH70NQZRj0= 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 5CBC620E40CF; Fri, 26 Apr 2013 09:02:21 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 09:02:21 -0400 Message-ID: <1638252.lDf4xVkYCO@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130426065221.D8E8133032DC@drugs.dv.isc.org> References: <20130425013317.36729.qmail@joyce.lan> <20130426065221.D8E8133032DC@drugs.dv.isc.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] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 13:02:27 -0000 On Friday, April 26, 2013 04:52:21 PM Mark Andrews wrote: > In message , "Murray S. Kucherawy" writes: > > On Thu, Apr 25, 2013 at 4:28 PM, Doug Barton wrote: > > > Yep, been there, done that. It was a bad decision then, and it's still a > > > bad decision now. I realize that it's incredibly unpopular to bluntly > > > call > > > bad decisions "bad decisions," but not doing so doesn't make them any > > > less > > > bad. And, to make matters worse, not doing so has led to a non-trivial > > > number of those bad decisions becoming de facto standards. This has at > > > least 2 very bad side effects ... first, we have to live with the bad de > > > facto standards; but more importantly we are providing encouragement to > > > people who wish to make similar bad decisions down the road. > > > > > > The argument in 6686 boils down to, "We made a series of bad decisions, > > > which have led to a bad result. We now want to codify that bad result > > > instead of cleaning up our mess." I don't agree with that in principle, > > > and > > > I don't agree with that in regards to this particular case. > > > > > > Further, while cleaning up the SPF mess would require nothing more than > > > a > > > marginal amount of extra work now, plus the passage of time, there is no > > > reason not to actually clean up the mess. > > > > I think this continues to trivialize exactly what it means to migrate the > > enormous deployed base of SPF in the manner you're pushing. I fully agree > > with your premise that it should've been "done right" in the beginning and > > I lament that it was not, but I don't agree that fixing this now is worth > > moving a mountain, especially when I don't believe the people saying that > > here will be among the people doing even a fraction of the moving. > > The installed base of SPF is miniscule. As for moving it, you > really only need to update a couple MTA's to use the SPF libraries > that look for SPF first and let time pass. If you look at the data in RFC 6686 it's 40 - 60% of domains being used for email. What does it take to be non-miniscule from your perspective? As for looking for SPF first, been there, done that. Doesn't work in the real world. Go fix all the broken DNS implementations and firewalls, provide some evidence to support your case and then there might be a basis for discussion. > If you want a hurry on one could add code to nameservers and zone > signers to detected TXT style spf records and add SPF records if > they are missing. Scripts to add SPF records if a TXT type SPF record is present in a zone have existed since roughly a week after type 99 was assigned to SPF. > > At least half of the reason we landed here is because of an environment > > that was basically hostile to doing it right in the first place. The > > rules > > for getting new RRtypes have been improved -- > > The rules were dead simple at the time, just nobody in the SPF camp > was willing to try to go down that route. I know they were simple > because I used them at the time for another type. Getting the type assignment was only the smallest part of the problem. We had a huge thread on this on the IETF main list last year. "I can hand edit a BIND zone file and do it" gets you about 1% of the way to deployment. See if you can spot the fallacy in "I'm one of the world's foremost experts on DNS and it's easy for me, therefore it's easy for everyone"? > > I think we all agree on that > > -- but, as you already conceded, there's still a large deployed base of > > faulty firewalls and DNS tools out there that don't exactly make use of > > uncommon RRtypes easy. So how much energy are the DNS experts going to > > put > > into cleaning up their house while demanding the mail people clean up > > theirs? I would even go so far as to say that the DNS part has to happen > > first, before any cleanup on the email side is practical to consider. > > The DNS had deployed support for UNKNOWN RR types at the time. Most > resolvers have been able to lookup unknown types since RFC 1034 was > published. For most resolvers it was simply a matter of using 99 > rather than a symbolic name. Yes. And there was library code to do this a week after type 99 was assigned. There were, in fact, a number of AUTH48 changes to the draft that became RFC 4408 because we were finally able to test using a real second RR type rather than just have a paper design. The SPF community jumped on the type 99 support bandwagon and most SPF libraries have had support for it for a LONG time. None of that helped deployment at all and there's no evidence that it's going to change. Ever. > > The deployed SPF base probably won't give a damn if the IETF suddenly > > releases an RFC that exclaims "Everybody migrate to type 99!" From the > > perspective of large and small operators around the world, what's out > > there > > is working now, and messing with it is asking for pain; engineers' time to > > switch and debug costs a lot of money, so they have no incentive > > whatsoever > > to comply with a proposed change to "fix" a service that is > > philosophically > > broken but operationally just fine. > > > > Thus, I maintain that we take our licks on this one and just take steps to > > ensure that nobody follows this path again. Since there wasn't the same screaming about DKIM, I wonder if this issue is really about the RR type at all or if it's really about the design decision on where to place the record? It seems that SPF is not being penalized in some form for having gone to the trouble of getting the type assignment and giving it a go. Scott K From spf2@kitterman.com Fri Apr 26 06:04: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 B128B21F97C2 for ; Fri, 26 Apr 2013 06:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dUB+Lfz20Kv for ; Fri, 26 Apr 2013 06:04:25 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4D221F97AA for ; Fri, 26 Apr 2013 06:04:25 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EBFBB20E40D5; Fri, 26 Apr 2013 09:04:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366981465; bh=0Nv+TSGRNJSshCcA7CT3BKFCsh1HyS6hiGwIkwS21Jw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=E0R2UVnqmWkqIvWVMbpnz3qMjnzEKyAK/Ee93VlBwd9NcsWqVivTWHOSfdu98TWak w27/CZdSPnlHkJ2zcCKd5SsHTv5BQ4q5TktK+CGUN2zwY/fVCPzDcxluN/8ebyyMuV hwcyw+BvJHAtI+SRT9Eltp3b7OSMXJzGc65uQBSQ= 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 D0E9D20E40CF; Fri, 26 Apr 2013 09:04:24 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 09:04:23 -0400 Message-ID: <1776105.5sjcmaeEPo@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130426074414.GR23770@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <1998649.x7xmPiSjvn@scott-latitude-e6320> <20130426074414.GR23770@besserwisser.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 13:04:26 -0000 On Friday, April 26, 2013 09:44:14 AM M=E5ns Nilsson wrote: > Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Thu, Apr= 25,=20 2013 at 11:22:39PM -0400 Quoting Scott Kitterman (spf2@kitterman.com): > > On Thursday, April 25, 2013 05:15:43 PM Doug Barton wrote: > > > 2. A report that Perl's "Mail::SPF (which is used by Spamassassin= ) > > > checks for Type SPF first by default." > >=20 > > Mail::SPF is a library. The way that it makes SPF queries can (now= ) be > > controlled by the calling application. I maintain a small Perl > > application > > that acts as a Postfix policy server for doing SPF checks with Perl= . > >=20 > > Mail::SPF was written to be useful as a reference implementation an= d as a > > result, the author declined, initially to give calling applications= the > > ability to control which types where queried for. This causes prob= lems > > because not all DNS software will answer unknown query types. As a= > > result, if you query for Type SPF first, you'll get a certain fract= ion of > > either timeouts or SERFVAIL responses while if you query for TXT, y= ou get > > a response. > >=20 > > It took quite some time to convince him to change it, but he did. = Here's > > one bug report, to serve as an example: > >=20 > > https://bugs.launchpad.net/postfix-policyd-spf-perl/+bug/161133 > >=20 > > I report that a piece of software does something is interesting, ho= wever > > the fact that doing so causes interoperability problems supports th= e idea > > that it's a bad idea. Pushing for Type SPF queries first is only > > interesting if you're interested more in theoretical purism than ac= tual > > interoperability. > Tl;dr: "Overloading TXT is bad, lets fix this mess once and for all" >=20 > 1. Parsing TXT records and keeping a lookout for various almost SPF > (but not) data (which is legal in TXT) is hard. In the way open-ended= > text parsing is. Lots of security holes in that problem vector. It ma= kes > sense to remove this scenario as much as possible. >=20 > 2. Writing code to do the equivalent of: >=20 > if (exists SPF record) { > =09parse and return verdict; > } else if ( exists TXT record ) { > =09parse and return verdict; > } else { > =09return no data > } >=20 > ...is not very hard. Of course, we'll enter the open-ended parser qui= te > often today, with this code, but given that That Vendor Which I'll No= t > Name gets its act together, that frequency will decrease. All the way= , > we'll maintain interoperability. Automatically. And this is if not pu= re > (not doing TXT from the start would be pure, I'm trying to stop the s= ilt > from clogging the drain here, so purity is long gone.) at least the p= roper > way to clean up a mess. >=20 > 3. As a DNS operator (and also running mail gw for employer and mysel= f) > I look at the SPF problem like this: >=20 > 3a. Having to query twice (in the case of ask-for-SPF-first-and-then-= TXT) > is something that is -- to me -- bearable, more so since this is some= thing > that our friend the Computer can do automatically. Moore's law will m= ake > this less of a problem in the future, as code gets corrected. Also, t= hink > of caching. Sensible TTL will -- providing full-service resolvers are= > implemented to make use of caching -- in practice remove the expensiv= e > part of double-querying, at least where this could be a problem, in > heavily loaded mail gateways. >=20 > 3b. Not all uses of TXT records are automated. Having structured data= > in TXT records messes up my manual parsing of other TXT records that > may exist on the same node. (or dig zone.tld. axfr | grep TXT) > This usage does not benefit from the capacity increase according to M= oore. >=20 > 4. Having thus established that TXT overloading is bad, in this > specific case, we must turn to the general case. In the general case,= > TXT overloading is bad. Why? Simply, because the above discussion app= lies > to all those cases as well. (Ok, lots of handwaving here, but I'm rig= ht.) >=20 > 5. Then with the conclusion that TXT overloading is bad, we can turn > to the setting of a precedent. Which this discussion actually is all > about; the presence of TXT records with alleged meaning and some synt= ax > is undisputed. We already are are in damage-control mode here. Settin= g > the precedent that caving in and ignoring the bad effects of overload= ing > TXT because of reasons of defaitism is not how the IETF should do thi= s. >=20 > So: I oppose the publication of any text deprecating a specific RR ty= pe > in favour of overloading a generic free-form RR. Because overloading > TXT is bad. My interpretation of this is "I have this theory that it should be easy= , so we=20 should do it, don't confuse me with facts." Scott K From Ted.Lemon@nominum.com Fri Apr 26 06:41: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 D894521F9981; Fri, 26 Apr 2013 06:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.179 X-Spam-Level: X-Spam-Status: No, score=-105.179 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb68rLZ4VbmT; Fri, 26 Apr 2013 06:41:46 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3F921F98C9; Fri, 26 Apr 2013 06:41:46 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUXqEGW8bjYsGk1wCZNNVp2M6r3tMOj4T@postini.com; Fri, 26 Apr 2013 06:41:46 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 934B41B80C4; Fri, 26 Apr 2013 06:41:45 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 619A9190061; Fri, 26 Apr 2013 06:41:45 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 06:41:33 -0700 From: Ted Lemon To: S Moonesamy Thread-Topic: [dnsext] [spfbis] Obsoleting SPF RRTYPE Thread-Index: AQHOQhiJDTN43HbFiUKXXg4sKsK6S5jo+K0A Date: Fri, 26 Apr 2013 13:41:33 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> In-Reply-To: <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <19FD30E1F7D6AD4284DBC4023708C9F0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" , Pete Resnick , "dnsext@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 13:41:49 -0000 [This is really long, because I've spent a lot of time thinking about this = and reading the discussion; the tl;dr is that I don't intend to contest the= obsoleting of the SPF RRtype any further, but would not fault = others for doing so, and I think there are lessons to be lear= ned about how the process went this time, which, if you are interested i= n that, might be a good reason to continue reading.] On Apr 25, 2013, at 8:22 PM, S Moonesamy wrote: > I am ok if anyone says that it a bad decision. The thread for the discus= sion started at http://www.ietf.org/mail-archive/web/spfbis/current/msg0042= 6.html I undertook the exercise of reading this thread, and it looks like there wa= s some very interesting data collection work done. I didn't find a point = at which a consensus was determined; I presume that happened later, on some= other thread. > I was the document shepherd for RFC 6686. There wasn't any comments duri= ng the Last Call. FWIW, and I do not intend this as a criticism of what you did, I just went = back to the datatracker and looked at the text of the IETF last call. The= re is nothing at all in this text that would indicate that the document sai= d anything at all about the continued use of the SPF DNS RRtype. I've als= o read the document, and even reading the conclusion of the document, there= 's very little there that would suggest to me that the spfbis working group= was about to deprecate the use of the SPF DNS RRtype. Of course someone who was already involved in the discussion on the mailing= list would know this, but there's no reason to think that anyone reading t= he dnsext mailing list would have felt it was their duty to review this par= ticular document during the IETF last call, and if they had reviewed it, th= ey might still have remained innocent of any understanding that spfbis inte= nded to deprecate the SPF RRtype in favor of the TXT record. > If there are any new arguments which have been missed please let me know = as I can include them in my write-up. If the argument is solely "do the ri= ght thing" I will decline including it in the write-up as it is, in my indi= vidual opinion, non-technical. I cannot comment on what arguments should b= e provided as I will then be biasing the outcome. It seems to me that the argument in favor of deprecating SPF is that nobody= is publishing SPF records, despite widespread support in software. This = results in unnecessary traffic, the elimination of which would have minimal= impact. On the other side, here are the arguments that I understand to have been ma= de: 1. TXT records are not specific to SPF, thus we can't assume that any given= TXT record is an SPF record. Rejoinder: doesn't seem to be an issue in practice=97no other TXT records a= re needed on the names to which SPF TXT records are typically attached. 2. Because TXT records aren't specific to SPF, a query for TXT records may = return an unexpectedly large result set, requiring fallback to TCP. Rejoinder: doesn't seem to be an issue in practice. 3. Using TXT records is a bad idea. Rejoinder: this isn't really a technical argument; if there is a technical = argument in here, it should be stated explicitly, but this argument per se = will be ignored. 4. Using TXT records sets a bad precedent. Rejoinder: the horse is already out of the barn. I think there's one possible benefit to be considered for using TXT records= for SPF: it gets in the way of other uses of TXT records, and acts as a so= und technical argument against adoption of TXT records on bare names in fut= ure protocols. Speaking entirely with my AD hat off, and merely as an armchair quarterback= , I don't think it's fair to say that the consensus call in spfbis on what = was to become RFC6686 and the IETF consensus call on that document, taken t= ogether, represent IETF consensus. I don't think the rejoinders to argume= nts 1 and 2 are very convincing, although they seem to have carried the day= in the spfbis working group, and I understand why. The reason I reacted the way I did when drc brought this up is that it was = a surprise to me that spfbis was eliminating the SPF record from the specif= ication. It is not surprising that it was a surprise=97the process that w= as followed, which I think was followed correctly and with the best intenti= ons, did not really have much chance of bringing this decision to my attent= ion while it was being discussed in spfbis. Having reviewed the discussion in spfbis, and argued with this at length wi= th Pete, I am remarkably ambivalent about it. I don't like the decision t= he spfbis working group has made. I don't agree with the decision. I unde= rstand why you made it, and don't fault you for having made it. It's prob= ably not worth my personal time to dispute it. I would rather work to hasten the demise of SMTP and all the anti-spam klud= ges that rode in on it. So, what do I think could have gone better here? First, it would have bee= n very helpful if the abstract for RFC 6686 had said that the reason the re= search was being done was to answer the question "should we continue suppor= ting the SPF RRtype, or drop it?" Authors of drafts that are trying to ad= dress issues like this might want to think carefully about how they write a= bstracts, since it's only the abstract that gets shown in the IETF last cal= l message. If your abstract doesn't attract the people who ought to be re= ading the document, it's going to be hard later to argue that the document = had a clear IETF consensus, even though it nominally has consensus. It may be that using the document abstract in the last call announcement is= not sufficient=97if authors phrased the abstract the way I've suggested, i= t might be the wrong thing for the document once it's published. I don't = know the answer to this=97it might also be the right thing. I think it's clear that early in this discussion, all present, including th= e responsible AD, were aware that it was going to be contentious. I think= if a message like the one drc sent to the mailing list yesterday had gone = out in February of 2012, you would have gotten the exact same response. T= his probably would have created additional hassle on the spfbis mailing lis= t as a bunch of dnsext people dogpiled there, but we wouldn't be having _th= is_ conversation _now_, so it actually would have been better, despite the = short-term hassle. Andrew did raise this issue to the dnsop working group; he didn't mention r= aising it on dnsext. I don't remember seeing it on the dnsop mailing list= , and I'm not finding it in the archive; I don't see it in the minutes eith= er. This doesn't mean it isn't there; it just means that it didn't stand = out the way drc's message did. This ought to be a valuable lesson for wor= king group chairs; if you know something is going to be contentious, rip th= e bandaid off=97don't be quiet about it. Make sure the people who you kno= w are going to kick up a fuss do it at the right time. I know Andrew didn= 't intend to not rip off this bandaid, so I'm not sure how this failed to h= appen, but it's something to think about. The responsible AD also knew this was going to be contentious (I think!). = I don't know if he talked this over with Ralph (who was then the responsib= le AD for dnsext) or not. If he did, that was the right thing to do, and = it's worth considering why it didn't work. If he didn't, this might be a = lesson to remember for the future. Same thing should have happened with t= he responsible AD for dnsop; I don't know who that was. Of course, ADs don't always know that what's being raised in the working gr= oup is going to be contentious in other areas. Working group chairs need = to be proactive about this. ADs can definitely be a resource in spreading= the word, though, whether they do it on their own or at the request of wor= king group chairs. And of course working group chairs may not always know= that something will be contentious, but there's nothing we can do about th= at case other than live with the late surprise. I hasten to emphasize that I don't really know what went wrong here. It m= ay be that even if all the remedies I've discussed above had happened, we'd= still be having a big kerfuffle about this on the dnsext mailing list. M= y motivation for suggesting that more could have been done is simply my exp= erience as a participant: I really think I would have participated in the d= iscussion about this if I'd realized it was happening last February. I get= the impression from several other participants in the discussion now that = they weren't aware of it either. I don't have a sense of whether the disc= ussion would have come out differently if we'd participated. As for how to participate now, the right thing to do for people who feel th= ey were left out of the discussion before is to read the draft, read the hi= storical discussion (to which pointers have already been given) and then pa= rticipate constructively on the spfbis working group mailing list. "Tromping" on this in IETF last call would not be constructive given that i= t has not passed a working group last call. I'm sorry for having suggested= that=97I understood the document to have already passed WGLC, and stupidly= didn't go check to see if my impression was correct. And, by the way, internet dating is quite a lucrative industry, so it's pro= bably a bad example of a hopeless task. :) From Ted.Lemon@nominum.com Fri Apr 26 07:00: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 AC8C321F9955; Fri, 26 Apr 2013 07:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.016 X-Spam-Level: X-Spam-Status: No, score=-106.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URTHp-rGY6Du; Fri, 26 Apr 2013 07:00:59 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 03B8E21F994E; Fri, 26 Apr 2013 07:00:58 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUXqImjAQxeTP21ZZVCfUgyEIFpPfYsm1@postini.com; Fri, 26 Apr 2013 07:00:59 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AC1221B80CF; Fri, 26 Apr 2013 07:00:58 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A59FF190061; Fri, 26 Apr 2013 07:00:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 07:00:58 -0700 From: Ted Lemon To: S Moonesamy Thread-Topic: [dnsext] [spfbis] Obsoleting SPF RRTYPE Thread-Index: AQHOQhiJDTN43HbFiUKXXg4sKsK6S5jo+K0AgAAFbYA= Date: Fri, 26 Apr 2013 14:00:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077515FF39@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <053DFE13F90022448D6BBD3757DD2243@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" , Pete Resnick , "dnsext@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 14:00:59 -0000 On Apr 26, 2013, at 9:41 AM, Ted Lemon wrote: > Speaking entirely with my AD hat off, and merely as an armchair quarterba= ck, I don't think it's fair to say that the consensus call in spfbis on wha= t was to become RFC6686 and the IETF consensus call on that document, taken= together, represent IETF consensus. I don't think the rejoinders to argu= ments 1 and 2 are very convincing, although they seem to have carried the d= ay in the spfbis working group, and I understand why. Argh. I can't say anything right, apparently. What I mean here is that = the consensus call in the working group and the subsequent consensus call o= n the IETF mailing list do not mean that the IETF definitely has consensus = to deprecate the SPF RRtype. They do mean that the IETF had consensus to = publish the document. Sorry for putting that so badly. From superuser@gmail.com Fri Apr 26 07:52: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 ED50B21F9A3C; Fri, 26 Apr 2013 07:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfJoYPJvOC-d; Fri, 26 Apr 2013 07:52:32 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9002F21F9A2B; Fri, 26 Apr 2013 07:52:31 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id m1so3627768wea.40 for ; Fri, 26 Apr 2013 07:52:30 -0700 (PDT) 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=GZW0tvEsKM9+oW8N9592+eGj2eQxxaULB5tSdDWJ9bE=; b=kp4+f/etl6gT3lTOYIgjXY4uUuHT+oNVvnHtPBUvlDv4mJpdbLoWJdO2MyyB93hedj CkXuApxVtxjCMQbodo3zZn+Cwx/yY7oWwavOL7xLL+bzDw90vzYEyQQk86nuY6sF7bv3 HbF7Z+cyLuXOL80st+/EwX0nEhD7GjfSZ1AeOE+2/iexsLJDXEt84BRMerw36DDqgXTL jECJKyeThkl33HVbt2Bh8eDacH/fo8AxCSvjzfhuMhfjVbiDIByH0I+mWCFlxpwdCreA idDdVvXbWExqu2Iii8gzSm9AOhNEqQtmnZOQI7mQIw0ifxkwfG8ySOcRvD0fvs5x+tjC 8lgw== MIME-Version: 1.0 X-Received: by 10.180.80.3 with SMTP id n3mr4498560wix.20.1366987949493; Fri, 26 Apr 2013 07:52:29 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Fri, 26 Apr 2013 07:52:29 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> Date: Fri, 26 Apr 2013 07:52:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ted Lemon Content-Type: multipart/alternative; boundary=f46d041825382454fb04db44af4d Cc: "spfbis@ietf.org" , Pete Resnick , S Moonesamy , "dnsext@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 14:52:33 -0000 --f46d041825382454fb04db44af4d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Apr 26, 2013 at 6:41 AM, Ted Lemon wrote: > FWIW, and I do not intend this as a criticism of what you did, I just wen= t > back to the datatracker and looked at the text of the IETF last call. > There is nothing at all in this text that would indicate that the documen= t > said anything at all about the continued use of the SPF DNS RRtype. I'v= e > also read the document, and even reading the conclusion of the document, > there's very little there that would suggest to me that the spfbis workin= g > group was about to deprecate the use of the SPF DNS RRtype. > RFC6686 never set out to make a conclusion about the RRtype question, but rather to determine which of the four protocols MARID discussed appear to have enough traction to warrant advancement along the standards track, thus concluding "the experiment". Accordingly, the abstract for that document doesn't say anything about this matter. In the process of collecting data to answer that question, we realized that the numbers also highlight the non-use of type 99 by both senders and receivers. We were very careful in our wording of RFC6686 to point out that type 99, though supported both in protocol and software, is actually not very useful, and said nothing at all about what we planned to do with it. RFC6686 provides supporting evidence for what the main spfbis draft is doing, but does not itself introduce those actions. I don't think there was process breakage here. > > It seems to me that the argument in favor of deprecating SPF is that > nobody is publishing SPF records, despite widespread support in software. > This results in unnecessary traffic, the elimination of which would have > minimal impact. > That's not the complete argument I and others have been making. Widespread support in DNS software and SPF libraries exists, but there are also existing components of the infrastructure that interfere with either publication or handling of type 99 queries and replies, long after the type was assigned. RFC6686 calls this out. The rejoinder we're hearing to this is merely the gainsay of that position despite both anecdotal and empirical evidence to the contrary. On the other side, here are the arguments that I understand to have been > made: > > 1. TXT records are not specific to SPF, thus we can't assume that any > given TXT record is an SPF record. > Rejoinder: doesn't seem to be an issue in practice=97no other TXT records > are needed on the names to which SPF TXT records are typically attached. > Moreover, parsing TXT records is not hard, nor is answering the question "Does this one start with the string 'v=3Dspf1'?". We saw one case in our survey of a zone that had 37 TXT records at the same query point; SPF code is able to pull out the applicable one just fine. > > 2. Because TXT records aren't specific to SPF, a query for TXT records ma= y > return an unexpectedly large result set, requiring fallback to TCP. > Rejoinder: doesn't seem to be an issue in practice. > That's not correct; there are still packet filters out there configured by default to disallow TCP over port 53. We discovered this during the RFC6686 surveys. -MSK --f46d041825382454fb04db44af4d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 26, 2013 at 6:41 AM, Ted Lemon <Ted.Lemon= @nominum.com> wrote:
FWIW, and I do not intend= this as a criticism of what you did, I just went back to the datatracker a= nd looked at the text of the IETF last call. =A0 There is nothing at all in= this text that would indicate that the document said anything at all about= the continued use of the SPF DNS RRtype. =A0 I've also read the docume= nt, and even reading the conclusion of the document, there's very littl= e there that would suggest to me that the spfbis working group was about to= deprecate the use of the SPF DNS RRtype.

RFC6686 never set out to make a conclusion= about the RRtype question, but rather to determine which of the four proto= cols MARID discussed appear to have enough traction to warrant advancement = along the standards track, thus concluding "the experiment".=A0 A= ccordingly, the abstract for that document doesn't say anything about t= his matter.

In the process of collecting data to answer that question, we realized = that the numbers also highlight the non-use of type 99 by both senders and = receivers.=A0 We were very careful in our wording of RFC6686 to point out t= hat type 99, though supported both in protocol and software, is actually no= t very useful, and said nothing at all about what we planned to do with it.= =A0 RFC6686 provides supporting evidence for what the main spfbis draft is = doing, but does not itself introduce those actions.

I don't think there was process breakage here.=A0
=A0

It seems to me that the argument in favor of deprecating SPF is that nobody= is publishing SPF records, despite widespread support in software. =A0 Thi= s results in unnecessary traffic, the elimination of which would have minim= al impact.

That's not the complete argument I and othe= rs have been making.=A0 Widespread support in DNS software and SPF librarie= s exists, but there are also existing components of the infrastructure that= interfere with either publication or handling of type 99 queries and repli= es, long after the type was assigned.=A0 RFC6686 calls this out.=A0 The rej= oinder we're hearing to this is merely the gainsay of that position des= pite both anecdotal and empirical evidence to the contrary.

On the other side, here are the arguments that I understand to have been ma= de:

1. TXT records are not specific to SPF, thus we can't assume that any g= iven TXT record is an SPF record.
Rejoinder: doesn't seem to be an issue in practice=97no other TXT recor= ds are needed on the names to which SPF TXT records are typically attached.=

Moreover, parsing TXT records is not h= ard, nor is answering the question "Does this one start with the strin= g 'v=3Dspf1'?".=A0 We saw one case in our survey of a zone tha= t had 37 TXT records at the same query point; SPF code is able to pull out = the applicable one just fine.
=A0

2. Because TXT records aren't specific to SPF, a query for TXT records = may return an unexpectedly large result set, requiring fallback to TCP.
Rejoinder: doesn't seem to be an issue in practice.

That's not correct; there are still packet filters out= there configured by default to disallow TCP over port 53.=A0 We discovered= this during the RFC6686 surveys.
=A0
-MSK
--f46d041825382454fb04db44af4d-- From spf2@kitterman.com Fri Apr 26 08:09: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 70DFC21F97F7; Fri, 26 Apr 2013 08:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCYQd4M9wU8A; Fri, 26 Apr 2013 08:09:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E102C21F974E; Fri, 26 Apr 2013 08:09:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2C97C20E40D5; Fri, 26 Apr 2013 11:09:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366988968; bh=V7gYHjwxQx5871aR/yjpbS0s3EHEo+Rial4rbIICB2Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a9ff8vNpZ1Y5Fx/woHK6UmcWRWAIS9vy9yt9pxNKpBOp1IyBNA1ylRELp6BDc9Nr3 XMwUNnVJUdmYyoFaHyC29gZzQuCdNHjk6J5H1HwPz3ziuPxWpp7TXWnkSPoxNm2KEQ q/UpXTYQhGXCHMBhHC/a6+Zh7C6Fl4TsNFQqVg40= 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 10A0520E40CF; Fri, 26 Apr 2013 11:09:17 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org, "dnsext@ietf.org" Date: Fri, 26 Apr 2013 11:09:17 -0400 Message-ID: <4261639.Sk6X1reqIa@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <20130425013317.36729.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: Ted Lemon Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 15:09:29 -0000 On Friday, April 26, 2013 07:52:29 AM Murray S. Kucherawy wrote: > > 2. Because TXT records aren't specific to SPF, a query for TXT records may > > return an unexpectedly large result set, requiring fallback to TCP. > > Rejoinder: doesn't seem to be an issue in practice. > > That's not correct; there are still packet filters out there configured by > default to disallow TCP over port 53. We discovered this during the > RFC6686 surveys. And, in the event a domain needs enough other TXT data that an SPF record would cause it to spill over into TCP, it's trivially solvable. For example.com: example.com. 3600 IN TXT "v=spf1 redirect=_spf.example.com" _spf.example.com. 3600 IN TXT "v=spf1 [record content] -all" It needn't ever be more impact than that. Scott K From Ted.Lemon@nominum.com Fri Apr 26 08: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 6C62B21F990F; Fri, 26 Apr 2013 08:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.124 X-Spam-Level: X-Spam-Status: No, score=-106.124 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1brJvkezOkst; Fri, 26 Apr 2013 08:13:18 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 020B221F988B; Fri, 26 Apr 2013 08:13:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUXqZjfIHjWRvXKTyCgTsHo/nlR6x4HJm@postini.com; Fri, 26 Apr 2013 08:13:18 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 878901B80DF; Fri, 26 Apr 2013 08:13:17 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7AA1E190061; Fri, 26 Apr 2013 08:13:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 08:13:17 -0700 From: Ted Lemon To: "Murray S. Kucherawy" Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQo2uaOnySfcNYkaWBgVmragk3ZjpEWOA Date: Fri, 26 Apr 2013 15:13:16 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775160234@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B630775160234mbx01winnominum_" MIME-Version: 1.0 Cc: "spfbis@ietf.org" , Pete Resnick , S Moonesamy , "dnsext@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 15:13:19 -0000 --_000_8D23D4052ABE7A4490E77B1A012B630775160234mbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Apr 26, 2013, at 10:52 AM, Murray S. Kucherawy > wrote: RFC6686 never set out to make a conclusion about the RRtype question, but r= ather to determine which of the four protocols MARID discussed appear to ha= ve enough traction to warrant advancement along the standards track, thus c= oncluding "the experiment". Accordingly, the abstract for that document do= esn't say anything about this matter. In the process of collecting data to answer that question, we realized that= the numbers also highlight the non-use of type 99 by both senders and rece= ivers. We were very careful in our wording of RFC6686 to point out that ty= pe 99, though supported both in protocol and software, is actually not very= useful, and said nothing at all about what we planned to do with it. RFC6= 686 provides supporting evidence for what the main spfbis draft is doing, b= ut does not itself introduce those actions. I don't think there was process breakage here. Okay, fair enough. Please do note that I didn't say that there was proces= s breakage=97I said the process seemed to have been followed correctly, but= produced a less than perfect outcome. The sense in which I mean that with respect to RFC 6686 is that several peo= ple have mentioned the IETF last call on RFC 6686 as if it means that the I= ETF now has an opinion on whether to deprecate SPF. It sounds like we bot= h agree that it does not, so this wouldn't be an example of process breakag= e. However, if people came to the conclusion that it did mean that, it's = worth talking about. That's not the complete argument I and others have been making. Widespread= support in DNS software and SPF libraries exists, but there are also exist= ing components of the infrastructure that interfere with either publication= or handling of type 99 queries and replies, long after the type was assign= ed. RFC6686 calls this out. The rejoinder we're hearing to this is merely= the gainsay of that position despite both anecdotal and empirical evidence= to the contrary. OK. But presumably these parts of the internet are going to start really = seriously breaking as IPv6 and DNSSEC deployment increase. So this doesn'= t _seem_ like a long-term concern. What am I missing? On the other side, here are the arguments that I understand to have been ma= de: 1. TXT records are not specific to SPF, thus we can't assume that any given= TXT record is an SPF record. Rejoinder: doesn't seem to be an issue in practice=97no other TXT records a= re needed on the names to which SPF TXT records are typically attached. Moreover, parsing TXT records is not hard, nor is answering the question "D= oes this one start with the string 'v=3Dspf1'?". Sure, and a base-64 encoded string will never have an equals sign in that p= osition, so we don't have to worry too much about a random collision. We saw one case in our survey of a zone that had 37 TXT records at the sa= me query point; SPF code is able to pull out the applicable one just fine. 2. Because TXT records aren't specific to SPF, a query for TXT records may = return an unexpectedly large result set, requiring fallback to TCP. Rejoinder: doesn't seem to be an issue in practice. That's not correct; there are still packet filters out there configured by = default to disallow TCP over port 53. We discovered this during the RFC668= 6 surveys. These two points taken together seem like a pretty strong argument in favor= of _not_ deprecating the SPF record; in this case, only the SPF record wou= ld have made it back to the MTA. --_000_8D23D4052ABE7A4490E77B1A012B630775160234mbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: <24FD6E35C2265D489ABE512883EFE458@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 26, 2013, at 10:52 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
RFC6686 never set out to make a conclusion about the RRtype question, = but rather to determine which of the four protocols MARID discussed appear = to have enough traction to warrant advancement along the standards track, t= hus concluding "the experiment".  Accordingly, the abstract for that document doesn't say anything about thi= s matter.

In the process of collecting data to answer that question, we realized that= the numbers also highlight the non-use of type 99 by both senders and rece= ivers.  We were very careful in our wording of RFC6686 to point out th= at type 99, though supported both in protocol and software, is actually not very useful, and said nothing at al= l about what we planned to do with it.  RFC6686 provides supporting ev= idence for what the main spfbis draft is doing, but does not itself introdu= ce those actions.

I don't think there was process breakage here. 

Okay, fair enough.   Please do note that I didn't say that there was p= rocess breakage=97I said the process seemed to have been followed correctly= , but produced a less than perfect outcome.

The sense in which I mean that with respect to RFC 6686 is that severa= l people have mentioned the IETF last call on RFC 6686 as if it means that = the IETF now has an opinion on whether to deprecate SPF.   It sounds l= ike we both agree that it does not, so this wouldn't be an example of process breakage.   However, if people= came to the conclusion that it did mean that, it's worth talking about.

That's not the complete argument I and others have been making.  = Widespread support in DNS software and SPF libraries exists, but there are = also existing components of the infrastructure that interfere with either p= ublication or handling of type 99 queries and replies, long after the type was assigned.  RFC6686 calls this ou= t.  The rejoinder we're hearing to this is merely the gainsay of that = position despite both anecdotal and empirical evidence to the contrary.

OK.   But presumably these parts of the internet are going to start re= ally seriously breaking as IPv6 and DNSSEC deployment increase.   So t= his doesn't _seem_ like a long-term concern.   What am I missing?

On the other side, here are the arguments that I understand to have been ma= de:

1. TXT records are not specific to SPF, thus we can't assume that any given= TXT record is an SPF record.
Rejoinder: doesn't seem to be an issue in practice=97no other TXT records a= re needed on the names to which SPF TXT records are typically attached.

Moreover, parsing TXT records is not hard, nor is answering the questi= on "Does this one start with the string 'v=3Dspf1'?".

Sure, and a base-64 encoded string will never have an equals sign in that p= osition, so we don't have to worry too much about a random collision.

  We saw one case in our survey of a zone that had 37 TXT records= at the same query point; SPF code is able to pull out the applicable one j= ust fine.


 

2. Because TXT records aren't specific to SPF, a query for TXT records may = return an unexpectedly large result set, requiring fallback to TCP.
Rejoinder: doesn't seem to be an issue in practice.

That's not correct; there are still packet filters out there configure= d by default to disallow TCP over port 53.  We discovered this during = the RFC6686 surveys.

These two points taken together seem like a pretty strong argument in = favor of _not_ deprecating the SPF record; in this case, only the SPF recor= d would have made it back to the MTA.


--_000_8D23D4052ABE7A4490E77B1A012B630775160234mbx01winnominum_-- From nweaver@icsi.berkeley.edu Fri Apr 26 08:02: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 C1A6721F996E; Fri, 26 Apr 2013 08:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ7SpwfwcMPO; Fri, 26 Apr 2013 08:02:59 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 562E421F9955; Fri, 26 Apr 2013 08:02:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 308992C400B; Fri, 26 Apr 2013 08:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5z-VsHBJwKLy; Fri, 26 Apr 2013 08:02:58 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id DFBA72C4007; Fri, 26 Apr 2013 08:02:58 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Nicholas Weaver In-Reply-To: Date: Fri, 26 Apr 2013 08:02:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <803526C6-6812-45CC-AEFF-2336B1247F93@icsi.berkeley.edu> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Fri, 26 Apr 2013 08:13:42 -0700 Cc: Nicholas Weaver , Pete Resnick , "dnsext@ietf.org" , S Moonesamy , "spfbis@ietf.org" , Ted Lemon Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 15:02:59 -0000 On Apr 26, 2013, at 7:52 AM, Murray S. Kucherawy = wrote: > 2. Because TXT records aren't specific to SPF, a query for TXT records = may return an unexpectedly large result set, requiring fallback to TCP. > Rejoinder: doesn't seem to be an issue in practice. >=20 > That's not correct; there are still packet filters out there = configured by default to disallow TCP over port 53. We discovered this = during the RFC6686 surveys. This is pretty rare but not nonexistent. If anyone cares, we have some names that test resolver->authority path = for truncation, and client->resolver path for proper truncation support. From Ted.Lemon@nominum.com Fri Apr 26 08:32: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 094EB21F99E4; Fri, 26 Apr 2013 08:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.177 X-Spam-Level: X-Spam-Status: No, score=-106.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4-GXH2Zq4Uz; Fri, 26 Apr 2013 08:32:01 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6E04E21F99BB; Fri, 26 Apr 2013 08:32:01 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUXqd8XlTOTiex1mgGcShHgwTVs97z8IT@postini.com; Fri, 26 Apr 2013 08:32:01 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0DF791B8152; Fri, 26 Apr 2013 08:32:01 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id F1A5A190061; Fri, 26 Apr 2013 08:32:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 08:32:01 -0700 From: Ted Lemon To: Nicholas Weaver Thread-Topic: [dnsext] [spfbis] Obsoleting SPF RRTYPE Thread-Index: AQHOQpEXYsxqRLAjJkK9cjiqS/EnTJjpFpiA Date: Fri, 26 Apr 2013 15:32:00 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751603CA@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775160234@mbx-01.win.nominum.com> <5E14F91D-5E46-4F21-AAC4-93E9C66528BC@icsi.berkeley.edu> In-Reply-To: <5E14F91D-5E46-4F21-AAC4-93E9C66528BC@icsi.berkeley.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <436DC312E1B0264E9F948509D099AA0B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" , Pete Resnick , "Murray S. Kucherawy" , S Moonesamy , "dnsext@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 15:32:02 -0000 On Apr 26, 2013, at 11:16 AM, Nicholas Weaver w= rote: > IF the string is random, thats a 1 in 2^36 chance. Yawn. >=20 > And if the string is "malicious" and deliberately constructed to be a bad= record starting with v=3Dspf1, it only screws up the domain owner's SPF re= cord, so who gives a flying fig? The domain owner can correct it, be done = with it, and move on. Right. > If you want DNSSEC, you got to fix THAT problem anyway. This is a non-sequitur. From marka@isc.org Fri Apr 26 08:39: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 1F50421F9A02 for ; Fri, 26 Apr 2013 08:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmtlZHPY4il6 for ; Fri, 26 Apr 2013 08:39:17 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id C2A8621F9A00 for ; Fri, 26 Apr 2013 08:39:16 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id DC0495F9905; Fri, 26 Apr 2013 15:39:05 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366990756; bh=H91Cg1P0hY2K2rR2jBl40HoZEvz2zOUje1UPqJvqmyM=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=QB3jWqIGskl5VPcOSYD+wflU7oNLtl05y09g2G1+PqBeda68srROOMiGpTgszagkq p/yCl5UsaWrIEH83rw9IzaOFCaS+/yRZVBGxCGGZXuEbfvBlPBsfIeSgwiQpYWc5R0 h4NnBbS4hWuba6A42b0wKTI9SlCWkdPyU45bxeOY= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 8BAC9216C43; Fri, 26 Apr 2013 15:39:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id E2DD133105A9; Sat, 27 Apr 2013 01:38:16 +1000 (EST) To: Scott Kitterman From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> <6703991.tZ8WHlYQKG@scott-latitude-e6320> In-reply-to: Your message of "Fri, 26 Apr 2013 08:48:40 -0400." <6703991.tZ8WHlYQKG@scott-latitude-e6320> Date: Sat, 27 Apr 2013 01:38:14 +1000 Message-Id: <20130426153816.E2DD133105A9@drugs.dv.isc.org> Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 15:39:18 -0000 In message <6703991.tZ8WHlYQKG@scott-latitude-e6320>, Scott Kitterman writes: > On Thursday, April 25, 2013 11:30:13 PM Murray S. Kucherawy wrote: > > On Thu, Apr 25, 2013 at 11:05 PM, David Conrad wrote: > > > > So how much energy are the DNS experts going to put into cleaning up > > > > > > their house while demanding the mail people clean up theirs? > > > > > > So, this is about revenge because it used to be hard to get RRtypes? > > > > Did I really come across as that petty? > > > > No, what I'm saying is that the way things were ten years ago pushed the > > SPF community to the place it's in now, ugly as it is. SPF, in the > > interim, has become very widely deployed. Suddenly now we have a few > > voices from the ivory tower asserting that the same community needs to go > > out and re-do things the way they should have been done in the first place, > > now that we finally have a somewhat more reasonable perspective, even > > though some of the vestiges of ten years ago are in fact still around. My > > reaction to that is "You can't be serious." That doesn't sound like > > revenge at all to me, just pragmatism. > > > > > > The deployed SPF base probably won't give a damn if the IETF suddenly > > > > > > releases an RFC that exclaims "Everybody migrate to type 99!" > > > > > > Yep. This gets into projections about the future. If SPF has topped out, > > > it simply doesn't matter. If SPF is going to continue to grow, then it > > > probably does matter. > > > > I think it's much closer to the former. > > > > > The point is that it isn't just fine. It does have operational impacts, > > > from potentially increased fragmentation/fallback to TCP to increased > > > complexity in TXT RR parsers that have to distinguish between the myriad > > > of > > > crap that's residing at the zone apex TXT RR, etc. Of course, most of > > > these negative impacts are hidden to the folks who are putting the TXT RRs > > > in the zone, so it's all good, right? > > > > > > > Thus, I maintain that we take our licks on this one and just take steps > > > > > > to ensure that nobody follows this path again. > > > > > > And how do you propose that exactly, particularly given the precedent set > > > by SPFBIS? > > > > Someone else (Joe, I think) has already referred to other RFCs that talk > > about things like IAB advice about how [not] to put application data into > > the DNS. Seems to me this is a perfectly good subject for another such > > project. One may counter that by saying nobody will pay attention to such > > a document, but I submit that it's our primary mechanism for making sure > > mistakes aren't re-made, so that's the tool we have to use or not use. > > > > If we do the opposite and somehow compel SPFBIS to favour type 99 over TXT, > > then I still think we'll be shouting that to an audience that will think > > we're nuts and simply go about their business. > > I think it's also important to reflect on the interoperability issue that led > us to seriously consider removing type SPF. In RFC 4408 you can publish > either SPF or TXT and you can check either SPF or TXT and be compliant with > the spec. There is no common format that is required to publish/check so it's > possible based on just reading the document for some people to decide to check > only one type and for publishers to only publish the other resulting in NO > interoperability. An SPF-compliant domain name SHOULD have SPF records of both RR types. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Now if your nameserver doesn't support type SPF that is a good reason not to publish it but otherwise I can't think of a reason that meets SHOULD for not publishing type SPF if you are publishing TXT spf record. As for publishing a SPF record without a TXT record. That is the expected end state but it was still a while off and would be a judgement call for as to when to do this as it will result in some additional blow back / forged mail getting through. This is similar as to when one decided to go MX only for email and not supply fallback A records. A similar decision about when to stop adverting A records and just rely on AAAA records is also in the future. As for looking up SPF and not falling back to TXT when it is not available is just a broken implementation. Similarly if you only look up TXT you are not conforment and will at some point not interoperate with those that choose to only publish SPF records. So as far as I can see the entire interop arguement was a load of garbage. > The first step then was to consider this issue and conclude that specifying one > of the two as mandatory to publish/check was essential for interoperability. > The second step what to decide which. Looking at the deployed base it didn't > take a great stretch to realize that trying to order the whole internet to > change to type SPF was silly and that TXT was the only thing that made sense. > The third step then was to consider if there was any point in maintaining > duplicate data and doing duplicate checks for something that is known to > (still) be problematic for interoperation and has effectively no deployment. > We concluded it didn't. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nweaver@icsi.berkeley.edu Fri Apr 26 08:16: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 EA14F21F99A4; Fri, 26 Apr 2013 08:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDXdZR0Wt-o8; Fri, 26 Apr 2013 08:16:56 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 214AF21F998C; Fri, 26 Apr 2013 08:16:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 0B5F52C400C; Fri, 26 Apr 2013 08:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3HBYOt3KLgTP; Fri, 26 Apr 2013 08:16:55 -0700 (PDT) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A38242C400B; Fri, 26 Apr 2013 08:16:55 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Nicholas Weaver In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160234@mbx-01.win.nominum.com> Date: Fri, 26 Apr 2013 08:16:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E14F91D-5E46-4F21-AAC4-93E9C66528BC@icsi.berkeley.edu> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775160234@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Fri, 26 Apr 2013 08:55:18 -0700 Cc: Nicholas Weaver , Pete Resnick , S Moonesamy , "dnsext@ietf.org" , "spfbis@ietf.org" , "Murray S. Kucherawy" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 15:16:57 -0000 On Apr 26, 2013, at 8:13 AM, Ted Lemon wrote: >> On the other side, here are the arguments that I understand to have = been made: >>=20 >> 1. TXT records are not specific to SPF, thus we can't assume that any = given TXT record is an SPF record. >> Rejoinder: doesn't seem to be an issue in practice=97no other TXT = records are needed on the names to which SPF TXT records are typically = attached. >>=20 >> Moreover, parsing TXT records is not hard, nor is answering the = question "Does this one start with the string 'v=3Dspf1'?". >=20 > Sure, and a base-64 encoded string will never have an equals sign in = that position, so we don't have to worry too much about a random = collision. Yeah, we don't. =20 IF the string is random, thats a 1 in 2^36 chance. Yawn. And if the string is "malicious" and deliberately constructed to be a = bad record starting with v=3Dspf1, it only screws up the domain owner's = SPF record, so who gives a flying fig? The domain owner can correct it, = be done with it, and move on. >> 2. Because TXT records aren't specific to SPF, a query for TXT = records may return an unexpectedly large result set, requiring fallback = to TCP. >> Rejoinder: doesn't seem to be an issue in practice. >>=20 >> That's not correct; there are still packet filters out there = configured by default to disallow TCP over port 53. We discovered this = during the RFC6686 surveys. >=20 > These two points taken together seem like a pretty strong argument in = favor of _not_ deprecating the SPF record; in this case, only the SPF = record would have made it back to the MTA. If you want DNSSEC, you got to fix THAT problem anyway. From hsantos@isdg.net Fri Apr 26 08:56: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 0A06B21F9A1D for ; Fri, 26 Apr 2013 08:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.867 X-Spam-Level: X-Spam-Status: No, score=-100.867 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jegX1uqOk8wz for ; Fri, 26 Apr 2013 08:56:49 -0700 (PDT) Received: from winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C588421F9A1A for ; Fri, 26 Apr 2013 08:56:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5764; t=1366991800; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=Mk0DVm1 YTmZnRjBADRO3HGF1kBM=; b=pE7jyZUj1Crdcm4AotRXzdzALBwzHoUQVWATvHI PWC2SX1hxiPd9i5VHvaTFIxHcmr3ZFiPK1JY3vkcIrHh1PSkbi8SZYAXz6ZFc+bb 1u1wBx2jSTCWCcLjzSPrLE5O4ueFPeBd50MvWHKnuPMkXLulGlPIKogf0gLvSMn8 lbzk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 26 Apr 2013 11:56:40 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1490521538.1698.5496; Fri, 26 Apr 2013 11:56:40 -0400 Message-ID: <517AA367.4020007@isdg.net> Date: Fri, 26 Apr 2013 11:55:19 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> <6703991.tZ8WHlYQKG@scott-latitude-e6320> <20130426153816.E2DD133105A9@drugs.dv.isc.org> In-Reply-To: <20130426153816.E2DD133105A9@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 15:56:50 -0000 +1 On 4/26/2013 11:38 AM, Mark Andrews wrote: > > In message <6703991.tZ8WHlYQKG@scott-latitude-e6320>, Scott Kitterman writes: >> On Thursday, April 25, 2013 11:30:13 PM Murray S. Kucherawy wrote: >>> On Thu, Apr 25, 2013 at 11:05 PM, David Conrad wrote: >>>>> So how much energy are the DNS experts going to put into cleaning up >>>> >>>> their house while demanding the mail people clean up theirs? >>>> >>>> So, this is about revenge because it used to be hard to get RRtypes? >>> >>> Did I really come across as that petty? >>> >>> No, what I'm saying is that the way things were ten years ago pushed the >>> SPF community to the place it's in now, ugly as it is. SPF, in the >>> interim, has become very widely deployed. Suddenly now we have a few >>> voices from the ivory tower asserting that the same community needs to go >>> out and re-do things the way they should have been done in the first place, >>> now that we finally have a somewhat more reasonable perspective, even >>> though some of the vestiges of ten years ago are in fact still around. My >>> reaction to that is "You can't be serious." That doesn't sound like >>> revenge at all to me, just pragmatism. >>> >>>>> The deployed SPF base probably won't give a damn if the IETF suddenly >>>> >>>> releases an RFC that exclaims "Everybody migrate to type 99!" >>>> >>>> Yep. This gets into projections about the future. If SPF has topped out, >>>> it simply doesn't matter. If SPF is going to continue to grow, then it >>>> probably does matter. >>> >>> I think it's much closer to the former. >>> >>>> The point is that it isn't just fine. It does have operational impacts, >>>> from potentially increased fragmentation/fallback to TCP to increased >>>> complexity in TXT RR parsers that have to distinguish between the myriad >>>> of >>>> crap that's residing at the zone apex TXT RR, etc. Of course, most of >>>> these negative impacts are hidden to the folks who are putting the TXT RRs >>>> in the zone, so it's all good, right? >>>> >>>>> Thus, I maintain that we take our licks on this one and just take steps >>>> >>>> to ensure that nobody follows this path again. >>>> >>>> And how do you propose that exactly, particularly given the precedent set >>>> by SPFBIS? >>> >>> Someone else (Joe, I think) has already referred to other RFCs that talk >>> about things like IAB advice about how [not] to put application data into >>> the DNS. Seems to me this is a perfectly good subject for another such >>> project. One may counter that by saying nobody will pay attention to such >>> a document, but I submit that it's our primary mechanism for making sure >>> mistakes aren't re-made, so that's the tool we have to use or not use. >>> >>> If we do the opposite and somehow compel SPFBIS to favour type 99 over TXT, >>> then I still think we'll be shouting that to an audience that will think >>> we're nuts and simply go about their business. >> >> I think it's also important to reflect on the interoperability issue that led >> us to seriously consider removing type SPF. In RFC 4408 you can publish >> either SPF or TXT and you can check either SPF or TXT and be compliant with >> the spec. There is no common format that is required to publish/check so it's >> possible based on just reading the document for some people to decide to check >> only one type and for publishers to only publish the other resulting in NO >> interoperability. > > An SPF-compliant domain name SHOULD have SPF records of both RR > types. > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > Now if your nameserver doesn't support type SPF that is a good > reason not to publish it but otherwise I can't think of a reason > that meets SHOULD for not publishing type SPF if you are publishing > TXT spf record. > > As for publishing a SPF record without a TXT record. That is the > expected end state but it was still a while off and would be a > judgement call for as to when to do this as it will result in some > additional blow back / forged mail getting through. > > This is similar as to when one decided to go MX only for email and > not supply fallback A records. A similar decision about when to > stop adverting A records and just rely on AAAA records is also in > the future. > > As for looking up SPF and not falling back to TXT when it is not > available is just a broken implementation. Similarly if you only > look up TXT you are not conforment and will at some point not > interoperate with those that choose to only publish SPF records. > > So as far as I can see the entire interop arguement was a load of > garbage. > >> The first step then was to consider this issue and conclude that specifying one >> of the two as mandatory to publish/check was essential for interoperability. >> The second step what to decide which. Looking at the deployed base it didn't >> take a great stretch to realize that trying to order the whole internet to >> change to type SPF was silly and that TXT was the only thing that made sense. >> The third step then was to consider if there was any point in maintaining >> duplicate data and doing duplicate checks for something that is known to >> (still) be problematic for interoperation and has effectively no deployment. >> We concluded it didn't. >> >> Scott K >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis From marka@isc.org Fri Apr 26 09:39: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 7B8F321F9A60 for ; Fri, 26 Apr 2013 09:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUbcNeQTjsZR for ; Fri, 26 Apr 2013 09:39:36 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 1C83221F9A67 for ; Fri, 26 Apr 2013 09:39:35 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id C8E455F9923; Fri, 26 Apr 2013 16:39:25 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366994374; bh=YtkXSdlr0Qk2w5z518lKE8jrQvZCAHk92v2ZqtLG3ls=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=UsJka8KaeYmRGJgB3BgX18fex5YuDHqL4Yvh4Gs7JAlvId/w+brGK2FchikqhY1fL Cw7n7DjazQX/1zzP9oXrFGyPwg/GB3ICyJbZGdE9q9AfAbfEVWXte2cqE36ntJN0hd YWLLJ7qgWyDkob2aODRo6WETZryBgr5Qv5Oseres= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 89300216C43; Fri, 26 Apr 2013 16:39:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 24ADC3310B51; Sat, 27 Apr 2013 02:39:09 +1000 (EST) To: Scott Kitterman From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <20130426065221.D8E8133032DC@drugs.dv.isc.org> <1638252.lDf4xVkYCO@scott-latitude-e6320> In-reply-to: Your message of "Fri, 26 Apr 2013 09:02:21 -0400." <1638252.lDf4xVkYCO@scott-latitude-e6320> Date: Sat, 27 Apr 2013 02:39:07 +1000 Message-Id: <20130426163909.24ADC3310B51@drugs.dv.isc.org> Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 16:39:37 -0000 In message <1638252.lDf4xVkYCO@scott-latitude-e6320>, Scott Kitterman writes: > On Friday, April 26, 2013 04:52:21 PM Mark Andrews wrote: > > In message tLaUwG4vm_BQ@mail.gmail.com>, "Murray S. Kucherawy" writes: > > > On Thu, Apr 25, 2013 at 4:28 PM, Doug Barton wrote: > > > > Yep, been there, done that. It was a bad decision then, and it's still a > > > > bad decision now. I realize that it's incredibly unpopular to bluntly > > > > call > > > > bad decisions "bad decisions," but not doing so doesn't make them any > > > > less > > > > bad. And, to make matters worse, not doing so has led to a non-trivial > > > > number of those bad decisions becoming de facto standards. This has at > > > > least 2 very bad side effects ... first, we have to live with the bad de > > > > facto standards; but more importantly we are providing encouragement to > > > > people who wish to make similar bad decisions down the road. > > > > > > > > The argument in 6686 boils down to, "We made a series of bad decisions, > > > > which have led to a bad result. We now want to codify that bad result > > > > instead of cleaning up our mess." I don't agree with that in principle, > > > > and > > > > I don't agree with that in regards to this particular case. > > > > > > > > Further, while cleaning up the SPF mess would require nothing more than > > > > a > > > > marginal amount of extra work now, plus the passage of time, there is no > > > > reason not to actually clean up the mess. > > > > > > I think this continues to trivialize exactly what it means to migrate the > > > enormous deployed base of SPF in the manner you're pushing. I fully agree > > > with your premise that it should've been "done right" in the beginning and > > > I lament that it was not, but I don't agree that fixing this now is worth > > > moving a mountain, especially when I don't believe the people saying that > > > here will be among the people doing even a fraction of the moving. > > > > The installed base of SPF is miniscule. As for moving it, you > > really only need to update a couple MTA's to use the SPF libraries > > that look for SPF first and let time pass. > > If you look at the data in RFC 6686 it's 40 - 60% of domains being used for > email. What does it take to be non-miniscule from your perspective? It is still miniscule compared to the number of email domains that will exist in 10 years time. > As for looking for SPF first, been there, done that. Doesn't work in the real > world. Go fix all the broken DNS implementations and firewalls, provide some > evidence to support your case and then there might be a basis for discussion. We have nameservers that support type SPF (Feb 2007), we have resolvers that support type SPF (1980), we have registrars that support type SPF, we have spf libraries that support type SPF (Oct 2008). As for fixing firewalls that can be done. We bitched to the vendors about EDNS, we bitched to the vendors about DNSSEC. Their new code is both EDNS and DNSSEC aware. > > If you want a hurry on one could add code to nameservers and zone > > signers to detected TXT style spf records and add SPF records if > > they are missing. > > Scripts to add SPF records if a TXT type SPF record is present in a zone have > existed since roughly a week after type 99 was assigned to SPF. Script != nameserver. > > > At least half of the reason we landed here is because of an environment > > > that was basically hostile to doing it right in the first place. The > > > rules > > > for getting new RRtypes have been improved -- > > > > The rules were dead simple at the time, just nobody in the SPF camp > > was willing to try to go down that route. I know they were simple > > because I used them at the time for another type. > > Getting the type assignment was only the smallest part of the problem. We had > a huge thread on this on the IETF main list last year. "I can hand edit a > BIND zone file and do it" gets you about 1% of the way to deployment. As for hand editing a zone file, I haven't done that in ages except for writing test code. I use nsupdate to update the master server on another machine (signed with TSIG for authentication) which may or may not know the details of the type of the record I am updating. The slave servers all support unknown records since 2003 so I can add any new type I care about without having to worry about whether they have been upgraded to know about the new type. If I'm using a machine which doesn't have a nsupdate that doesn't know about type SPF I can fallback to unknown. I could also write a custom tool that uses the existing libraries on the system to add new record types if I didn't want to use nsupdate. Note none of this was beyond the capabilities of the people who wrote libspf or libspf2 and integrated these into the MTA. Adding support to return the SPF record in unknown format wasn't beyound the capabilities of the web developers that wrote tools to construct SPF records. > See if you can spot the fallacy in "I'm one of the world's foremost experts on > DNS and it's easy for me, therefore it's easy for everyone"? Adding new types to the dns library is relatively easy for anyone with a little knowledge of C. We get the occasional submission of new records types with requests to add them. Once they are added to the library they are available to all the applications that want to use them. > > > I think we all agree on that > > > -- but, as you already conceded, there's still a large deployed base of > > > faulty firewalls and DNS tools out there that don't exactly make use of > > > uncommon RRtypes easy. So how much energy are the DNS experts going to > > > put > > > into cleaning up their house while demanding the mail people clean up > > > theirs? I would even go so far as to say that the DNS part has to happen > > > first, before any cleanup on the email side is practical to consider. > > > > The DNS had deployed support for UNKNOWN RR types at the time. Most > > resolvers have been able to lookup unknown types since RFC 1034 was > > published. For most resolvers it was simply a matter of using 99 > > rather than a symbolic name. > > Yes. And there was library code to do this a week after type 99 was assigned. > There were, in fact, a number of AUTH48 changes to the draft that became RFC > 4408 because we were finally able to test using a real second RR type rather > than just have a paper design. The SPF community jumped on the type 99 > support bandwagon and most SPF libraries have had support for it for a LONG > time. > > None of that helped deployment at all and there's no evidence that it's going > to change. Ever. Except for the fact that type SPF support still continues to increase. > > > The deployed SPF base probably won't give a damn if the IETF suddenly > > > releases an RFC that exclaims "Everybody migrate to type 99!" From the > > > perspective of large and small operators around the world, what's out > > > there > > > is working now, and messing with it is asking for pain; engineers' time to > > > switch and debug costs a lot of money, so they have no incentive > > > whatsoever > > > to comply with a proposed change to "fix" a service that is > > > philosophically > > > broken but operationally just fine. > > > > > > Thus, I maintain that we take our licks on this one and just take steps to > > > ensure that nobody follows this path again. > > Since there wasn't the same screaming about DKIM, I wonder if this issue is > really about the RR type at all or if it's really about the design decision on > where to place the record? It seems that SPF is not being penalized in some > form for having gone to the trouble of getting the type assignment and giving > it a go. Well DKIM used namespace to make its lookups unique. As for giving the new type a go, no you really didn't. Type SPF support was about where any DNS person would have expected it to be. > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Fri Apr 26 09: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 1B30221F9A78 for ; Fri, 26 Apr 2013 09:46:10 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMD+Pu9yAcTI for ; Fri, 26 Apr 2013 09:46:09 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A5BF621F9A7A for ; Fri, 26 Apr 2013 09:46:09 -0700 (PDT) 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 F29C18A031 for ; Fri, 26 Apr 2013 16:46:08 +0000 (UTC) Date: Fri, 26 Apr 2013 12:46:07 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130426164607.GO349@mx1.yitter.info> References: <20130425013317.36729.qmail@joyce.lan> <20130426065221.D8E8133032DC@drugs.dv.isc.org> <1638252.lDf4xVkYCO@scott-latitude-e6320> <20130426163909.24ADC3310B51@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130426163909.24ADC3310B51@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 16:46:10 -0000 Mark, No hat. On Sat, Apr 27, 2013 at 02:39:07AM +1000, Mark Andrews wrote: > > Except for the fact that type SPF support still continues to increase. You assert this, but I don't see the evidence you're presenting. I would encourage you to read the archives to see the discussion of the evidence the participants in this working group _did_ collect. It didn't support your claim. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From barryleiba.mailing.lists@gmail.com Fri Apr 26 09:53: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 D5AC921F9653; Fri, 26 Apr 2013 09:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmiH+GogDnxy; Fri, 26 Apr 2013 09:53:30 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 297DF21F992B; Fri, 26 Apr 2013 09:53:30 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id ia10so2673739vcb.32 for ; Fri, 26 Apr 2013 09:53:29 -0700 (PDT) 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 :content-transfer-encoding; bh=jS1z0glCyII8ThtjIaD8QyildjjHMKmnbrC4E2nCZjI=; b=GC6tQAOm+D14ukRsT6BWNRgG8Ge6ejs2VP+k/OIqbhOF06H/0HCVlEzhI7N/TawqoF W2TfcYJFV11kZcFrJvML6jHdvaJaZJQwdnmeN3Tth6JH1yGJhKsPIlQjx5lM+vCOvB5q sDUwL0e261d14keAXdjMIWsHfhsaDW2XFIKXeUSlT6xUafWv1lPV+nTy0A1Gjto88ZRm 4i9FpctTnPaUN+dl2Avcd288uAVTAvUS2CGpCQhYDv3Q1Bau3YYWVz6TAv6OZss8Rg2A oBWD4IPLtSSYVJY1O3UCmPOgrid0jn35geBN40cAGLk2/kgMAEpUcfYoFGpn098ARqm5 +UcQ== MIME-Version: 1.0 X-Received: by 10.220.177.69 with SMTP id bh5mr13496031vcb.22.1366995209160; Fri, 26 Apr 2013 09:53:29 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Fri, 26 Apr 2013 09:53:28 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> Date: Fri, 26 Apr 2013 12:53:28 -0400 X-Google-Sender-Auth: 6_T1uduq3D_8TpysXFvviwrb5tY Message-ID: From: Barry Leiba To: Ted Lemon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" , Pete Resnick , "dnsext@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 16:53:37 -0000 > FWIW, and I do not intend this as a criticism of what you did, I just wen= t back > to the datatracker and looked at the text of the IETF last call. There = is nothing > at all in this text that would indicate that the document said anything a= t all about > the continued use of the SPF DNS RRtype. I've also read the document, a= nd > even reading the conclusion of the document, there's very little there th= at would > suggest to me that the spfbis working group was about to deprecate the us= e of > the SPF DNS RRtype. As Murray's already responded, the intent of the document that became RFC 6686 was simply to report on the SPF/Sender-ID experiment. That document never meant to recommend a specific course, and didn't -- so any cross-area review of that document wouldn't have been likely to raise this discussion, and no text in that document relating to this issue would have been appropriate. That said, there is a general need for chairs, shepherds, and responsible ADs to be aware of these sorts of things. Chairs/shepherds need to make sure something about them gets put into shepherd writeups, at least, and ideally gets sent out to relevant lists earlier. Best I can tell, there *was* a discussion of this earlier, but it didn't get this level of attention. It would also be good for ADs to put things into the last call notices, pointing out things that participants in other areas might want to look at. We don't have a habit of doing that, and we should. Even something like, "This specification involves aspects of [technology X] and [technology Y]; experts in those technologies should pay particular attention and provide reviews and comments," might make a big difference. > On the other side, here are the arguments that I understand to have been = made: > > 1. TXT records are not specific to SPF, thus we can't assume that any giv= en TXT > record is an SPF record. > > Rejoinder: doesn't seem to be an issue in practice=97no other TXT records= are > needed on the names to which SPF TXT records are typically attached. Right: the underscore-prefix technique has been vetted before, and as far as I can tell this issue and its variants are settled. > 3. Using TXT records is a bad idea. > > Rejoinder: this isn't really a technical argument; if there is a technica= l argument > in here, it should be stated explicitly, but this argument per se will be= ignored. Actually, I don't agree that it's not a technical argument. The second part of that sentence is operative, and I want to drill down on that: if there's a technical argument in here, let's tease out what it is. We really have two issues that really seem to matter here: 1. Should we be working on a transition to type=3D99 only, rather than deprecating type=3D99? 2. Claim (quoting M=E5ns here): overloading TXT is bad. (1) is being adequately argued back and forth; I want to focus on (2): Why, specifically, is it bad to use TXT records in an "_spf." subdomain for this purpose? What harm does it cause, specifically. Let's bring that out clearly, and have that part of the discussion, realizing that some possible arguments already have answers: - It's not hard to parse these; there are many parsers out there that work, and there are many text-based protocols that work. - The "_spf." subdomain eliminates the issue of multi-use collisions -- DKIM queries, for example, will go to "_dkim." subdomains, and won't see SPF records in the responses. What other issues does the use of TXT records in this context cause, which would make it clear that migration away from them in SPF is important to avoid damage to the Internet, or at least to the DNS system? Barry From marka@isc.org Fri Apr 26 10:09: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 4A36821F9A18; Fri, 26 Apr 2013 10:09:59 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNUgNt6f5Ube; Fri, 26 Apr 2013 10:09:58 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 35ACD21F99FD; Fri, 26 Apr 2013 10:09:58 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 731095F991D; Fri, 26 Apr 2013 17:09:48 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1366996197; bh=hHM2pg4wJNMT09QPQMS/InrwcRCiwwhqHNPqQfoNJdE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=CVoYZ/SV0LcvZpH1b6YMd+S0il+CdKAYT0nwGDciFVm5rm2KNXJCsXT0uR7Mmw7DI Yil61LBo8kiAiWZyJG56/aMa8h9LvzEFc+/yWrZmOVy5coEIfTpYS1BjqaYEm4+gaE F3sKwyO76JY6uP2BdPaAt082ItNXIeIxPkESt55o= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 23C6B216C4B; Fri, 26 Apr 2013 17:09:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1DF24331133D; Sat, 27 Apr 2013 03:08:56 +1000 (EST) To: Barry Leiba From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> In-reply-to: Your message of "Fri, 26 Apr 2013 12:53:28 -0400." Date: Sat, 27 Apr 2013 03:08:56 +1000 Message-Id: <20130426170856.1DF24331133D@drugs.dv.isc.org> Cc: "spfbis@ietf.org" , Pete Resnick , Ted Lemon , "dnsext@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 17:09:59 -0000 In message , Barry Leiba writes: > > FWIW, and I do not intend this as a criticism of what you did, I just wen= > t back > > to the datatracker and looked at the text of the IETF last call. There = > is nothing > > at all in this text that would indicate that the document said anything a= > t all about > > the continued use of the SPF DNS RRtype. I've also read the document, a= > nd > > even reading the conclusion of the document, there's very little there th= > at would > > suggest to me that the spfbis working group was about to deprecate the us= > e of > > the SPF DNS RRtype. > > As Murray's already responded, the intent of the document that became > RFC 6686 was simply to report on the SPF/Sender-ID experiment. That > document never meant to recommend a specific course, and didn't -- so > any cross-area review of that document wouldn't have been likely to > raise this discussion, and no text in that document relating to this > issue would have been appropriate. > > That said, there is a general need for chairs, shepherds, and > responsible ADs to be aware of these sorts of things. > Chairs/shepherds need to make sure something about them gets put into > shepherd writeups, at least, and ideally gets sent out to relevant > lists earlier. Best I can tell, there *was* a discussion of this > earlier, but it didn't get this level of attention. > > It would also be good for ADs to put things into the last call > notices, pointing out things that participants in other areas might > want to look at. We don't have a habit of doing that, and we should. > Even something like, "This specification involves aspects of > [technology X] and [technology Y]; experts in those technologies > should pay particular attention and provide reviews and comments," > might make a big difference. > > > On the other side, here are the arguments that I understand to have been = > made: > > > > 1. TXT records are not specific to SPF, thus we can't assume that any giv= > en TXT > > record is an SPF record. > > > > Rejoinder: doesn't seem to be an issue in practice=97no other TXT records= > are > > needed on the names to which SPF TXT records are typically attached. > > Right: the underscore-prefix technique has been vetted before, and as > far as I can tell this issue and its variants are settled. > > > 3. Using TXT records is a bad idea. > > > > Rejoinder: this isn't really a technical argument; if there is a technica= > l argument > > in here, it should be stated explicitly, but this argument per se will be= > ignored. > > Actually, I don't agree that it's not a technical argument. The > second part of that sentence is operative, and I want to drill down on > that: if there's a technical argument in here, let's tease out what it > is. > > We really have two issues that really seem to matter here: > > 1. Should we be working on a transition to type=3D99 only, rather than > deprecating type=3D99? > > 2. Claim (quoting M=E5ns here): overloading TXT is bad. > > (1) is being adequately argued back and forth; I want to focus on (2): > > Why, specifically, is it bad to use TXT records in an "_spf." > subdomain for this purpose? What harm does it cause, specifically. > Let's bring that out clearly, and have that part of the discussion, > realizing that some possible arguments already have answers: Wrong question. The correct question is "is the use of _spf bad?". Using a prefix constrains where the solution can be used. It won't work with wildcards. It won't work for all domains. > - It's not hard to parse these; there are many parsers out there that > work, and there are many text-based protocols that work. > > - The "_spf." subdomain eliminates the issue of multi-use collisions > -- DKIM queries, for example, will go to "_dkim." subdomains, and > won't see SPF records in the responses. > > What other issues does the use of TXT records in this context cause, > which would make it clear that migration away from them in SPF is > important to avoid damage to the Internet, or at least to the DNS > system? > > Barry > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@elandsys.com Fri Apr 26 10:10: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 C0C6721F9A18; Fri, 26 Apr 2013 10:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drL44wUMvtD5; Fri, 26 Apr 2013 10:10:27 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1CA21F99FD; Fri, 26 Apr 2013 10:10:27 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.115]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3QHACCY001747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Apr 2013 10:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366996225; bh=VTusckDU1FnokYWcWxPfBdAYcmcfr8qCOYCAPW1DN5Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=z9ZN8kdlRppat9nrc1O1CXQM523HBr/ikZQxgzMmTchPLJ/xGcV2HZkRQkkbtR/Ld ovGBkDdGhU1ugQmKhf55j8dCuDB1OLHHHSG8ysgo2pse6FvhEfl3Q2+DbPVwcMdnEt ocEvmFnMJASJKtKIqUmB9qyOhdCKHbuvquxbUrEw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366996225; i=@elandsys.com; bh=VTusckDU1FnokYWcWxPfBdAYcmcfr8qCOYCAPW1DN5Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dJ4PdCRJqF0oDXmvcw+WIL2oqwa3MNHUTlmjyfz3FEKTaDfMIKcFelY+yBfe9TQbO X5S4ntfBjHuUMf7hKwSP8bQtARw+4X46C8fzEjDCX6DKQ2dEH0uLUTsmLRg2+y4vtB PbWC7XETqlkClTzuzV2gUSF5dQxK9oJgESsMajD8= Message-Id: <6.2.5.6.2.20130426070324.0c76fc00@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 26 Apr 2013 10:09:49 -0700 To: Ted Lemon From: S Moonesamy In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominu m.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, Pete Resnick , dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 17:10:28 -0000 Hi Ted, At 06:41 26-04-2013, Ted Lemon wrote: >[This is really long, because I've spent a lot=20 >of time thinking about this and reading the=20 >discussion; the tl;dr is that I don't intend to=20 >contest the obsoleting of the SPF RRtype any=20 >further, but would not fault others=20 >for doing so, and I think there=20 >are lessons to be learned about how the process=20 >went this time, which, if you are interested=20 >in that, might be a good reason to continue reading.] I'll comment nelow. >I undertook the exercise of reading this thread,=20 >and it looks like there was some very=20 >interesting data collection work done. I=20 >didn't find a point at which a consensus was=20 >determined; I presume that happened later, on some other thread. There are actually several threads about the=20 issue of which RRTYPE to use. The discussions=20 also occurred on unrelated threads. There was an=20 intermediate conclusion (see=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg00594.html=20 ) which was followed by an objection (see=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg00658.html=20 ). The SPFBIS WG Chairs posted a message after=20 that (=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg00692.html=20 ) which I'll quote partially: "There appears to be a wide variety of opinion about Issue #9. Moreover, the discussion has revealed an=20 interoperability concern in the existing RFC." There was the IETF 83 session (see Item C in the=20 minutes) after that where the SPFBIS Chairs stated the following: "The conclusion reached by the Chair was that the document will say SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99." For what it is worth I edited the minutes by=20 listening to the audio recording. Two drafts of=20 the minutes were posted to the SPFBIS mailing=20 list (see=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg01369.html=20 and=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg01419.html=20 ). As there wasn't any objection I considered the issue as resolved. >FWIW, and I do not intend this as a criticism of=20 >what you did, I just went back to the=20 >datatracker and looked at the text of the IETF=20 >last call. There is nothing at all in Let's not worry about that and focus on understanding what happened. :-) > this text that would indicate that the=20 > document said anything at all about the=20 > continued use of the SPF DNS RRtype. I've=20 > also read the document, and even reading the=20 > conclusion of the document, there's very little=20 > there that would suggest to me that the spfbis=20 > working group was about to deprecate the use of the SPF DNS RRtype. Here's an extract from the write-up: "The discussions about the RRTYPE 99 DNS Resource Record were= controversial. The issue was resolved. There was consensus that Sender ID re-use of SPF DNS Resource Records does not have to be called out in the document." I'll highlight one of the points from Section 6 of RFC 6686: "2. The absence of significant adoption of the RRTYPE 99 DNS Resource Record suggests that it has not attracted enough support to be useful." There is some background information about the=20 RRTYPE in Appendix A of RFC 6686. I agree that the document or even the write-up=20 may not be clear. I left it to Pete Resnick to=20 translate for the IESG. :-) I'll describe the=20 working group climate as unfriendly. It was=20 surprising that was even consensus. >Of course someone who was already involved in=20 >the discussion on the mailing list would know=20 >this, but there's no reason to think that anyone=20 >reading the dnsext mailing list would have felt=20 >it was their duty to review this particular=20 >document during the IETF last call, and if they=20 >had reviewed it, they might still have remained=20 >innocent of any understanding that spfbis=20 >intended to deprecate the SPF RRtype in favor of the TXT record. I expected some people from DNSEXT to raise an=20 issue during the Last Call. There was some text=20 in it which was like asking for trouble. I'll=20 refrain from commenting about DNSEXT reviews. >It seems to me that the argument in favor of=20 >deprecating SPF is that nobody is publishing SPF=20 >records, despite widespread support in=20 >software. This results in unnecessary traffic,=20 >the elimination of which would have minimal impact. Yes. >On the other side, here are the arguments that I understand to have been= made: > >1. TXT records are not specific to SPF, thus we=20 >can't assume that any given TXT record is an SPF record. >Rejoinder: doesn't seem to be an issue in=20 >practice=97no other TXT records are needed on the=20 >names to which SPF TXT records are typically attached. Yes. >2. Because TXT records aren't specific to SPF, a=20 >query for TXT records may return an unexpectedly=20 >large result set, requiring fallback to TCP. >Rejoinder: doesn't seem to be an issue in practice. Yes. >3. Using TXT records is a bad idea. >Rejoinder: this isn't really a technical=20 >argument; if there is a technical argument in=20 >here, it should be stated explicitly, but this argument per se will be= ignored. Probably. :-) >4. Using TXT records sets a bad precedent. >Rejoinder: the horse is already out of the barn. I don't know about this one. >Speaking entirely with my AD hat off, and merely=20 >as an armchair quarterback, I don't think it's=20 >fair to say that the consensus call in spfbis on=20 >what was to become RFC6686 and the IETF=20 >consensus call on that document, taken together,=20 >represent IETF consensus. I don't think the=20 >rejoinders to arguments 1 and 2 are very=20 >convincing, although they seem to have carried=20 >the day in the spfbis working group, and I understand why. It's debatable. I would have to read the=20 detailed arguments to form an opinion. >Having reviewed the discussion in spfbis, and=20 >argued with this at length with Pete, I am=20 >remarkably ambivalent about it. I don't like=20 >the decision the spfbis working group has=20 >made. I don't agree with the decision. I=20 >understand why you made it, and don't fault you=20 >for having made it. It's probably not worth my personal time to dispute= it. At the end of the day a decision has to be=20 taken. It may not be the right decision. There=20 are safeguards in the process if that is the=20 case. I don't mind if anyone disputes the=20 decision. There has been an appeal (see=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html=20 ). It's part of the work. >I would rather work to hasten the demise of SMTP=20 >and all the anti-spam kludges that rode in on it. :-) > >So, what do I think could have gone better=20 >here? First, it would have been very helpful=20 >if the abstract for RFC 6686 had said that the=20 >reason the research was being done was to answer=20 >the question "should we continue supporting the=20 >SPF RRtype, or drop it?" Authors of drafts=20 >that are trying to address issues like this=20 >might want to think carefully about how they=20 >write abstracts, since it's only the abstract=20 >that gets shown in the IETF last call=20 >message. If your abstract doesn't attract the=20 >people who ought to be reading the document,=20 >it's going to be hard later to argue that the=20 >document had a clear IETF consensus, even though it nominally has= consensus. That sounds like a good idea. >It may be that using the document abstract in=20 >the last call announcement is not sufficient=97if=20 >authors phrased the abstract the way I've=20 >suggested, it might be the wrong thing for the=20 >document once it's published. I don't know the=20 >answer to this=97it might also be the right thing. In the write-up I am supposed to mention whether=20 a draft requires review from a particular or from broader perspective. >I think it's clear that early in this=20 >discussion, all present, including the=20 >responsible AD, were aware that it was going to=20 >be contentious. I think if a message like the=20 >one drc sent to the mailing list yesterday had=20 >gone out in February of 2012, you would have=20 >gotten the exact same response. This probably=20 >would have created additional hassle on the=20 >spfbis mailing list as a bunch of dnsext people=20 >dogpiled there, but we wouldn't be having _this_=20 >conversation _now_, so it actually would have=20 >been better, despite the short-term hassle. With hindsight I'll say that it would have been good to have the discussion. >I hasten to emphasize that I don't really know=20 >what went wrong here. It may be that even if=20 >all the remedies I've discussed above had=20 >happened, we'd still be having a big kerfuffle=20 >about this on the dnsext mailing list. My=20 >motivation for suggesting that more could have=20 >been done is simply my experience as a=20 >participant: I really think I would have=20 >participated in the discussion about this if I'd=20 >realized it was happening last February. I get=20 >the impression from several other participants=20 >in the discussion now that they weren't aware of=20 >it either. I don't have a sense of whether the=20 >discussion would have come out differently if we'd participated. The discussion would have been more=20 controversial. As a rough guess I would say that=20 the Last Call did not work as expected. Some of=20 the reasons for that are mentioned in the (quoted) text above. >And, by the way, internet dating is quite a=20 >lucrative industry, so it's probably a bad example of a hopeless task. :) I might ask the Responsible AD to recharter this=20 working group to work on that task. :-) Regards, S. Moonesamy =20 From hsantos@isdg.net Fri Apr 26 10:10: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 18F2021F9A2B for ; Fri, 26 Apr 2013 10:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.589 X-Spam-Level: X-Spam-Status: No, score=-101.589 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg2mKjKtvhz1 for ; Fri, 26 Apr 2013 10:10:29 -0700 (PDT) Received: from secure.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2B16421F9A18 for ; Fri, 26 Apr 2013 10:10:28 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2193; t=1366996222; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=iAphS7R 6p3QGLCd1JaV8rEveK/I=; b=tTotDO6qfTuAkxsnBUb+axYlzae7EwxKP9Kjhuo uIpaOubdftscQWdsecKNHCDiCcROWfTH8XV6MVLvRXpOlG2sCDfe680+TYeaaHlZ wprJERwY08KSpHj+4thGIawlv0iX+gegadasQJ+D/YMdTzr6vntQI4zXdoOhHbjr nFFs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 26 Apr 2013 13:10:22 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1494943121.1698.5436; Fri, 26 Apr 2013 13:10:21 -0400 Message-ID: <517AB4AD.1090103@isdg.net> Date: Fri, 26 Apr 2013 13:09:01 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman References: <20130425013317.36729.qmail@joyce.lan> <20130426065221.D8E8133032DC@drugs.dv.isc.org> <1638252.lDf4xVkYCO@scott-latitude-e6320> In-Reply-To: <1638252.lDf4xVkYCO@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, "dnsext@ietf.org Group" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 17:10:30 -0000 On 4/26/2013 9:02 AM, Scott Kitterman wrote: > > Since there wasn't the same screaming about DKIM, I wonder if this issue is > really about the RR type at all or if it's really about the design decision on > where to place the record? It seems that SPF is not being penalized in some > form for having gone to the trouble of getting the type assignment and giving > it a go. > In my view, the DKIM decision was entirely based on the fact SPF was getting a huge traction and adoption as a TXT solution. So why not for DKIM? It worked for SPF! We should also note the mindset were among the same authors for protocols that are now entirely TXT: SPF - 99/TXT, Levine against SPF, Murray wasn't around MARID DKIM - TXT only, Murray authored VBR - TXT only, Levine authored DMARK - TXT only, and now a new I-D by Murray SPFBIS - TXT only, Murray started SPFBIS. So we don't have too much "diversity" on the design. SPF goal is still the same design goal for SPF type. The problem are the DNS servers. Getting Microsoft DNS servers to support unnamed RRTYPE processing at the very least will immediately change the course of the RRTYPE needs in the right direction. Its a different problem in the same way AUTH-RES isn't ready for prime time with SPF - an errata is needed and people need to change their Received-SPF reporting. In the mean time, in the name of across the board coding and single-sourcing, you support both even if the AUTH-RES support needs to be done with a kludge comment field. Its the same with DMARC design pressures, it "works" better when MTA does the SPF processing at the 5322 Payload level (DATA state) or you accept the message then do the above tests and it may bounce or perhaps, hopefully not, discard: SPF FAIL POLICY === DKIM/ADSP DISCARD POLICY Ideally, if we are going to stick with TXT based solutions and to better support integrated systems (ones that may support all of the above, it will be at least 4 DNS TXT queries), then we explore a direct solution of a single call to return all the sender information one may need about, including the message owner and copyright holder domain. -- HLS From superuser@gmail.com Fri Apr 26 10:37: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 6624A21F9969 for ; Fri, 26 Apr 2013 10:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0zkTRTptcsG for ; Fri, 26 Apr 2013 10:37:16 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 550CD21F9981 for ; Fri, 26 Apr 2013 10:37:16 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so893677wiv.9 for ; Fri, 26 Apr 2013 10:37:15 -0700 (PDT) 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=tPd1MiHk1Hj2MMbqVa4BcASZga5Z106g45r7PGxeXfw=; b=gxTpjdsxj1vFtJqEkqH13GmxcY84TwLTxXAhrVkgHaXrRVg6V6CggvNqfF/EN4TtIt rA0zWuJKmBfOZshGb9M24XHJjbuqpWQUNb3bJw05tpWNjNQq4Xu4Zhm8YtMPJADuKFy6 Ukpm1kkikuUZEBqq2JASBovpqpenqfzHcnYsXvYeyEHsrYDlLshdsup9+MPtkUj9I101 mQRtBV+84gYERteNOr01cVn7KTKkhVvK7GIDOumQlvqs8ejkTEgOts2zopR9PsAkYJDy Lc0tseZXwH8Z/IaOxNyThKtQG/WBGZLzOPEsG+s4G8BVEW3B/ZbnONOrSjDu5+VVBRsw 9HcQ== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr5372901wic.32.1366997835514; Fri, 26 Apr 2013 10:37:15 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Fri, 26 Apr 2013 10:37:15 -0700 (PDT) In-Reply-To: <20130426153816.E2DD133105A9@drugs.dv.isc.org> References: <20130425013317.36729.qmail@joyce.lan> <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> <6703991.tZ8WHlYQKG@scott-latitude-e6320> <20130426153816.E2DD133105A9@drugs.dv.isc.org> Date: Fri, 26 Apr 2013 10:37:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews Content-Type: multipart/alternative; boundary=001a11c348306519ac04db46fcd2 Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 17:37:17 -0000 --001a11c348306519ac04db46fcd2 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 26, 2013 at 8:38 AM, Mark Andrews wrote: > An SPF-compliant domain name SHOULD have SPF records of both RR > types. > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > Now if your nameserver doesn't support type SPF that is a good > reason not to publish it but otherwise I can't think of a reason > that meets SHOULD for not publishing type SPF if you are publishing > TXT spf record. > [...] Sounds like you're asking operators that went with TXT only to prove they had some hardship that prevented them from advertising both. If you'd like to collect those data I'm sure it would be an interesting survey. I'm also sure some quantity of the sample space will simply say "We didn't know" or "It's what everyone else was doing", but I'm further sure that there will be some non-trivial part of the sample space that had some problem -- provisioning issues, DNS software support, whatever -- that prevented them from doing it. RFC4408 said SHOULD publish both and MUST publish one of them, simultaneously stating that clients are to query either or both. A client would be in its rights to issue a query for only one of the types and a server would be within its rights to only publish the other for whatever local justification applied at the time. That would always result in NODATA despite correct implementations on both sides. That sure sounds like an interoperability problem to me. Because of the way publication occurred, this wasn't caught by any kind of real review, and then sat out there for the last seven years leaving approximately zero incentive to do it the way you're saying it should've been done in the first place while deployment continued to increase. All this sound and fury about the right way and the wrong way doesn't change any of that reality. I totally agree that doing it the right way in the first place would've been nice. Are you perchance offering to lead the charge to get the industry to swing over to type 99? Someone who supports that as the right way forward from here will have to. -MSK --001a11c348306519ac04db46fcd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 26, 2013 at 8:38 AM, Mark Andrews <marka@isc.org<= /a>> wrote:
=A0=A0 An SPF-compliant domain name SHOULD have SPF records of both RR
=A0 =A0types.

3. SHOULD =A0 This word, or the adjective "RECOMMENDED", mean tha= t there
=A0 =A0may exist valid reasons in particular circumstances to ignore a
=A0 =A0particular item, but the full implications must be understood and =A0 =A0carefully weighed before choosing a different course.

Now if your nameserver doesn't support type SPF that is a good
reason not to publish it but otherwise I can't think of a reason
that meets SHOULD for not publishing type SPF if you are publishing
TXT spf record.
[...]

Sounds like you're asking operato= rs that went with TXT only to prove they had some hardship that prevented t= hem from advertising both.=A0 If you'd like to collect those data I'= ;m sure it would be an interesting survey.=A0 I'm also sure some quanti= ty of the sample space will simply say "We didn't know" or &q= uot;It's what everyone else was doing", but I'm further sure t= hat there will be some non-trivial part of the sample space that had some p= roblem -- provisioning issues, DNS software support, whatever -- that preve= nted them from doing it.

RFC4408 said SHOULD publish both and MUST publish one of them, simultan= eously stating that clients are to query either or both.=A0 A client would = be in its rights to issue a query for only one of the types and a server wo= uld be within its rights to only publish the other for whatever local justi= fication applied at the time.=A0 That would always result in NODATA despite= correct implementations on both sides.=A0 That sure sounds like an interop= erability problem to me.=A0 Because of the way publication occurred, this w= asn't caught by any kind of real review, and then sat out there for the= last seven years leaving approximately zero incentive to do it the way you= 're saying it should've been done in the first place while deployme= nt continued to increase.

All this sound and fury about the right way and the wrong wa= y doesn't change any of that reality.=A0 I totally agree that doing it = the right way in the first place would've been nice.

Are you perchance offering to lead the charge to get the industry to swing = over to type 99?=A0 Someone who supports that as the right way forward from= here will have to.

-MSK
--001a11c348306519ac04db46fcd2-- From dhc2@dcrocker.net Fri Apr 26 10:39: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 8A15B21F99A4 for ; Fri, 26 Apr 2013 10:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-ZpwpXFaCsV for ; Fri, 26 Apr 2013 10:39:47 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DD54D21F991A for ; Fri, 26 Apr 2013 10:39:47 -0700 (PDT) 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 r3QHdhdO006135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 10:39:46 -0700 Message-ID: <517ABBDA.2060201@dcrocker.net> Date: Fri, 26 Apr 2013 10:39:38 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130424180512.GN16817@mx1.yitter.info> <1431349.C0e3qG0mtd@scott-latitude-e6320> 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.66]); Fri, 26 Apr 2013 10:39:46 -0700 (PDT) X-Mailman-Approved-At: Fri, 26 Apr 2013 10:52:58 -0700 Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 17:39:48 -0000 On 4/24/2013 11:14 AM, Murray S. Kucherawy wrote: > On Wed, Apr 24, 2013 at 11:08 AM, Scott Kitterman > wrote: > > The barriers to RR type assignment are different, but the barriers > to RR type > deployment (which in my opinion were more important for Type 99/SPF) > are still > real and substantial. > > > Sure, but they're unchanged. > > I think the only reason not to fully obsolete type 99 would be if we > think SPF3 is: > > a) likely to ever appear; and > > b) likely to do a TXT clone again; and > > c) likely to be able to tolerate finding legacy SPFv1 records, which > undoubtedly will linger. Even then, retention is a bad idea. There is no current basis for seeing any likelihood of utility for the RR. None. In the face of /massive/ market rejection for a feature, the normal and reasonable approach during a -bis effort is to deprecate it. Given both the market reality of SPF deployment and common IETF revision practice, retention is unrealistic, counter-productive willfulness. Worse, retention tells new implementers that they should do extra work that won't be useful now or in the foreseeable future. Useless extra work that might create additional software and/or operations hassles. Should the future decide to grace us with a more friendly environment and more significant functional benefit, which makes using an SPF-specific RR practical, then it will be appropriate to define it and pursue its adoption. The reality is that that will have nothing to do with the current, vestigial SPF RR. (Even if it winds up looking the same.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc2@dcrocker.net Fri Apr 26 10:44: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 3087521F99B1 for ; Fri, 26 Apr 2013 10:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9rYrUNa2hFM for ; Fri, 26 Apr 2013 10:44:22 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9365921F9841 for ; Fri, 26 Apr 2013 10:44:22 -0700 (PDT) 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 r3QHhjhK006159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 10:43:49 -0700 Message-ID: <517ABCCD.80103@dcrocker.net> Date: Fri, 26 Apr 2013 10:43:41 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <1936386.sgrkPvE9zZ@scott-latitude-e6320> <2936220.a4Qo14FLj7@scott-latitude-e6320> <20130424211539.GE16817@crankycanuck.ca> 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.66]); Fri, 26 Apr 2013 10:43:49 -0700 (PDT) X-Mailman-Approved-At: Fri, 26 Apr 2013 10:53:21 -0700 Cc: "spfbis@ietf.org" , Andrew Sullivan Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 17:44:23 -0000 On 4/24/2013 2:19 PM, Murray S. Kucherawy wrote: > > So I think this document needs to request IANA to update the > "Reference" field of "Resource Record (RR) TYPEs" subregistry to point > to this document, and to update the "Meaning" field to say "OBSOLETE - > use TXT". This is roughly what the currend document does. > > I am not concerned about the loss of the RRTYPE. Yes, it would be > nicer if there were an RR for this, but there isn't. > > I'm satisfied with that solution as well. The proposal seems to be for something that is simple, clear and pragmatic to its purpose. I'm sure that means it is massively deficient, but let's do it anyway. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Fri Apr 26 11:00: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 1C3C321F99C2 for ; Fri, 26 Apr 2013 11:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXSoUE8EPDPU for ; Fri, 26 Apr 2013 11:00:38 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 084F221F99CA for ; Fri, 26 Apr 2013 11:00:36 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4214020E40D5; Fri, 26 Apr 2013 14:00:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366999235; bh=JOxE8bK5Gt+Tvex3HDCL331bVBET0dniz/JC3ZfpS08=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OyDnufEyHqAeSpqG5X5A+lCGv9WsC/nvh5fZ+N47NqkJI8eIjZ2xOM0Nsjw1L2W4k TAUxlbmRezHqRvx00OrZK1JYeJgOr0wI8AXL12Qvpl1Ql68xmM29CbywNjuBE6flnK JELsBxaQgXp+Uk+3WYHi/S/yB7l2b7mKQFvHNvVQ= 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 25D2720E40CF; Fri, 26 Apr 2013 14:00:34 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 14:00:34 -0400 Message-ID: <1659315.HBOFQdbsc9@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <517AB4AD.1090103@isdg.net> References: <20130425013317.36729.qmail@joyce.lan> <1638252.lDf4xVkYCO@scott-latitude-e6320> <517AB4AD.1090103@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 18:00:39 -0000 On Friday, April 26, 2013 01:09:01 PM Hector Santos wrote: > On 4/26/2013 9:02 AM, Scott Kitterman wrote: > > Since there wasn't the same screaming about DKIM, I wonder if this issue > > is > > really about the RR type at all or if it's really about the design > > decision on where to place the record? It seems that SPF is not being > > penalized in some form for having gone to the trouble of getting the type > > assignment and giving it a go. > > In my view, the DKIM decision was entirely based on the fact SPF was > getting a huge traction and adoption as a TXT solution. So why not for > DKIM? It worked for SPF! > > We should also note the mindset were among the same authors for > protocols that are now entirely TXT: > > SPF - 99/TXT, Levine against SPF, Murray wasn't around MARID > DKIM - TXT only, Murray authored > VBR - TXT only, Levine authored > DMARK - TXT only, and now a new I-D by Murray > SPFBIS - TXT only, Murray started SPFBIS. > > So we don't have too much "diversity" on the design. For DKIM and SPFbis there's a whole working group. Also DKIM has been through not only working group last calls, but several IETF last calls. I think that it's reasonable to conclude that there's IETF consensus around TXT plus and underscored namespace being an OK solution to these kinds of problems. Trying to pin this on a few people, particularly when decisions were made in working groups that you participated in is just not correct. Scott K From hsantos@isdg.net Fri Apr 26 11:02: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 6159621F8DBB for ; Fri, 26 Apr 2013 11:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.993 X-Spam-Level: X-Spam-Status: No, score=-101.993 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id en-KlZWIXz9i for ; Fri, 26 Apr 2013 11:01:59 -0700 (PDT) Received: from secure.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 56D0D21F99F1 for ; Fri, 26 Apr 2013 11:01:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3800; t=1366999314; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=LrECy7Y mNCtPtBVoScEYtxWuymE=; b=l4MKvtPDCfe6XcqrerauJffzZ1W76b8i21U8kfT GbuNdkZbGR+XkcqcVmm3LkLtpqAlYvr+k40PmXCGmD4Y4Ym24kLKov0mdFqRXnsl VrmvvWJFjndo7QrBcxGDU4IubLm3f0XtHMQRHROKYYQy8/NG2usqrLHeUzYO02xV Josc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 26 Apr 2013 14:01:54 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1498035732.1698.1780; Fri, 26 Apr 2013 14:01:54 -0400 Message-ID: <517AC0C1.5020003@isdg.net> Date: Fri, 26 Apr 2013 14:00:33 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130425013317.36729.qmail@joyce.lan> <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> <6703991.tZ8WHlYQKG@scott-latitude-e6320> <20130426153816.E2DD133105A9@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , Scott Kitterman , Mark Andrews Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 18:02:00 -0000 In my opinion, you're missing the point. The specs should provide the functional specs (it does now, its being eliminated) where developers would basically offer deployment options. Think about how far you went to alter the concept of a FAIL/REJECT to also include a FAIL/ACCEPT+REPORT. You want developers to do both in order for deployments can have a "Local Policy" setup of either one. That is ideal even if some software are not ready for both. Its the same issue with the 99/TXT. Developers will be able to write the proper code, if they want to cover it all: o Method of SPF Calls, choose one: (_) SPF type (_) TXT type (*) Both, per spec. o Method of handling SPF Fail (*) Reject per SPEC (_) Accept [X] Always report when accepting [X] Separate Accepted Failed Mail to User Junk folder etc. What you are basically saying is that DNS software will never change and therefore, we should always give up on non-TXT DNS applications. That's apparently the direction DKIM, VBR and DMARC took! It was always stated that this will have endorsement problems, that was known since MARID and the status quo is the same today. COMPROMISE! -- HLS On 4/26/2013 1:37 PM, Murray S. Kucherawy wrote: > On Fri, Apr 26, 2013 at 8:38 AM, Mark Andrews wrote: > >> An SPF-compliant domain name SHOULD have SPF records of both RR >> types. >> >> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >> may exist valid reasons in particular circumstances to ignore a >> particular item, but the full implications must be understood and >> carefully weighed before choosing a different course. >> >> Now if your nameserver doesn't support type SPF that is a good >> reason not to publish it but otherwise I can't think of a reason >> that meets SHOULD for not publishing type SPF if you are publishing >> TXT spf record. >> [...] > > > Sounds like you're asking operators that went with TXT only to prove they > had some hardship that prevented them from advertising both. If you'd like > to collect those data I'm sure it would be an interesting survey. I'm also > sure some quantity of the sample space will simply say "We didn't know" or > "It's what everyone else was doing", but I'm further sure that there will > be some non-trivial part of the sample space that had some problem -- > provisioning issues, DNS software support, whatever -- that prevented them > from doing it. > > RFC4408 said SHOULD publish both and MUST publish one of them, > simultaneously stating that clients are to query either or both. A client > would be in its rights to issue a query for only one of the types and a > server would be within its rights to only publish the other for whatever > local justification applied at the time. That would always result in > NODATA despite correct implementations on both sides. That sure sounds > like an interoperability problem to me. Because of the way publication > occurred, this wasn't caught by any kind of real review, and then sat out > there for the last seven years leaving approximately zero incentive to do > it the way you're saying it should've been done in the first place while > deployment continued to increase. > > All this sound and fury about the right way and the wrong way doesn't > change any of that reality. I totally agree that doing it the right way in > the first place would've been nice. > > Are you perchance offering to lead the charge to get the industry to swing > over to type 99? Someone who supports that as the right way forward from > here will have to. > > -MSK > > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > From paf@frobbit.se Fri Apr 26 11:01: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 DF87021F99DA; Fri, 26 Apr 2013 11:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FN-CzdIkUGa; Fri, 26 Apr 2013 11:01:01 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id CF0C921F99C2; Fri, 26 Apr 2013 11:00:55 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::f160:8e06:3c06:258e] (unknown [IPv6:2a02:80:3ffc:0:f160:8e06:3c06:258e]) by mail.frobbit.se (Postfix) with ESMTPSA id 2A2D021DE9; Fri, 26 Apr 2013 20:00:54 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20130426170856.1DF24331133D@drugs.dv.isc.org> Date: Fri, 26 Apr 2013 20:00:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2122D2D2-70A8-4EFA-B4E1-1D9F6E0A728E@frobbit.se> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> <20130426170856.1DF24331133D@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Fri, 26 Apr 2013 11:14:46 -0700 Cc: "spfbis@ietf.org" , Pete Resnick , Barry Leiba , Ted Lemon , "dnsext@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 18:01:02 -0000 On 26 apr 2013, at 19:08, Mark Andrews wrote: > Using a prefix constrains where the solution can be used. It won't > work with wildcards. It won't work for all domains. There CAN be a zone cut between the SPF record and the MX, which in turn = might have impact on trust related to DNSSEC. I have no idea on the implications, but I do not see it being examined. Patrik From vesely@tana.it Fri Apr 26 11: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 2C2C121F890F for ; Fri, 26 Apr 2013 11:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tYmYZh+NTC3 for ; Fri, 26 Apr 2013 11:38:25 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7009821F8480 for ; Fri, 26 Apr 2013 11:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367001498; bh=E7dEv7682AJOMKXb8Z+9nCx2siyR3HoD/4cEcB8dImU=; l=4008; h=Date:From:To:CC:References:In-Reply-To; b=wvI1+1UMoFPy7X0Qdi+YENgsRDF5VAAi/Hm+Yn2Og97GQFGsncc4pa5Vszaoi/ATj jZf9x/nfq72NXZg8jN4uDXma9GimWVTTwFylWWOLsqM5Pzzpjhsi6wvK9ywVc9LgcE UdSzokBC5wEzAnd3fePEdcJHmnXnUnVCnDDuNzpk= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Fri, 26 Apr 2013 20:38:18 +0200 id 00000000005DC039.00000000517AC99A.0000661E Message-ID: <517AC998.5090105@tana.it> Date: Fri, 26 Apr 2013 20:38:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?TcOlbnMgTmlsc3Nvbg==?= References: <20130425013317.36729.qmail@joyce.lan> <5179B10E.705@qti.qualcomm.com> <5179C72F.1070703@dougbarton.us> <1998649.x7xmPiSjvn@scott-latitude-e6320> <20130426074414.GR23770@besserwisser.org> In-Reply-To: <20130426074414.GR23770@besserwisser.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 18:38:26 -0000 On Fri 26/Apr/2013 09:44:14 +0200 MÃ¥ns Nilsson wrote: > > Tl;dr: "Overloading TXT is bad, lets fix this mess once and for all" May I point out that, besides the pointers given by SM to discussions in SPFBIS WG, this issue was discussed at length in the IETF list, in various threads starting at: http://www.ietf.org/mail-archive/web/ietf/current/msg72024.html > 1. Parsing TXT records and keeping a lookout for various almost SPF > (but not) data (which is legal in TXT) is hard. In the way open-ended > text parsing is. Lots of security holes in that problem vector. It makes > sense to remove this scenario as much as possible. Why not data? If it is text/plain rather than binary, TXT suits it well, doesn't it? > 2. Writing code to do the equivalent of: > > if (exists SPF record) { > parse and return verdict; > } else if ( exists TXT record ) { > parse and return verdict; > } else { > return no data > } > > ...is not very hard. Been there, done that, it sucks. > Of course, we'll enter the open-ended parser quite > often today, with this code, but given that That Vendor Which I'll Not > Name gets its act together, that frequency will decrease. All the way, > we'll maintain interoperability. Automatically. And this is if not pure > (not doing TXT from the start would be pure, I'm trying to stop the silt > from clogging the drain here, so purity is long gone.) at least the proper > way to clean up a mess. Doubling the records and the queries seems to be more of a mess to me. > 3. As a DNS operator (and also running mail gw for employer and myself) > I look at the SPF problem like this: > > 3a. Having to query twice (in the case of ask-for-SPF-first-and-then-TXT) > is something that is -- to me -- bearable, more so since this is something > that our friend the Computer can do automatically. Moore's law will make > this less of a problem in the future, as code gets corrected. If a decade didn't correct anything, what time horizon do you mean? You are suggesting to keep a RR type that nobody uses, as a fig leaf to cover our inability to use the DNS more efficiently. Moore's law doesn't prescribe that having more resources is a good reason for wasting them, maybe that's Murphy's one or a corollary thereof. > 3b. Not all uses of TXT records are automated. Having structured data > in TXT records messes up my manual parsing of other TXT records that > may exist on the same node. (or dig zone.tld. axfr | grep TXT) > This usage does not benefit from the capacity increase according to Moore. grep -v v=spf1 > 4. Having thus established that TXT overloading is bad, in this > specific case, we must turn to the general case. In the general case, > TXT overloading is bad. Why? Simply, because the above discussion applies > to all those cases as well. (Ok, lots of handwaving here, but I'm right.) Non-authoritative answer: besserwisser.org text = "MN-1334-RIPE" besserwisser.org text = "SPF is stupid. Very Stupid." > 5. Then with the conclusion that TXT overloading is bad, we can turn > to the setting of a precedent. Which this discussion actually is all > about; the presence of TXT records with alleged meaning and some syntax > is undisputed. We already are are in damage-control mode here. Setting > the precedent that caving in and ignoring the bad effects of overloading > TXT because of reasons of defaitism is not how the IETF should do this. Please distinguish two layers: At a DNS layer discuss the DNS and how to incorporate variously structured records of specific types in a simple manner. At the application layer, when the use of specific types will have been established, consider migration. > So: I oppose the publication of any text deprecating a specific RR type > in favour of overloading a generic free-form RR. Because overloading > TXT is bad. I don't think overloading TXT is bad, but even if it were, it's the only option available now. From Ted.Lemon@nominum.com Fri Apr 26 11:42: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 66CE221F985F; Fri, 26 Apr 2013 11:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.282 X-Spam-Level: X-Spam-Status: No, score=-106.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4B4i2dOS40o; Fri, 26 Apr 2013 11:42:08 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id C136221F9579; Fri, 26 Apr 2013 11:42:07 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUXrKf5dP1eZ1hFJHYqJesJXfjAlUeHln@postini.com; Fri, 26 Apr 2013 11:42:07 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 43A6A1B80E6; Fri, 26 Apr 2013 11:42:07 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3B75C190061; Fri, 26 Apr 2013 11:42:07 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 11:42:07 -0700 From: Ted Lemon To: Barry Leiba Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQp6UBXubqTI8/ESMN/lsrU52YZjpS5qA Date: Fri, 26 Apr 2013 18:42:06 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775160B14@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <6.2.5.6.2.20130425163243.0bedb6d0@resistor.net> <8D23D4052ABE7A4490E77B1A012B63077515FDEB@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <41AE2352D5BCD14B8E56812D805FD5CE@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" , Pete Resnick , "dnsext@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 18:42:08 -0000 On Apr 26, 2013, at 12:53 PM, Barry Leiba wrote: > It would also be good for ADs to put things into the last call > notices, pointing out things that participants in other areas might > want to look at. We don't have a habit of doing that, and we should. > Even something like, "This specification involves aspects of > [technology X] and [technology Y]; experts in those technologies > should pay particular attention and provide reviews and comments," > might make a big difference. Yes. > Why, specifically, is it bad to use TXT records in an "_spf." > subdomain for this purpose? What harm does it cause, specifically. > Let's bring that out clearly, and have that part of the discussion, > realizing that some possible arguments already have answers: I think it's mostly harmless, but it's not what 4408bis does. From hsantos@isdg.net Fri Apr 26 11:57: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 CD9CD21F996C for ; Fri, 26 Apr 2013 11:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.633 X-Spam-Level: X-Spam-Status: No, score=-101.633 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4rf1dU+XNxk for ; Fri, 26 Apr 2013 11:57:21 -0700 (PDT) Received: from mail.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 753F521F991F for ; Fri, 26 Apr 2013 11:57:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2885; t=1367002637; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=f2LXQwh HrdFZmxLnFfP12fcYA/s=; b=en10mPX6CPJeP6rrWsT8OOeoyegyCHnmSwwOl/C FOk6K8tkCNCR03gaSVcFFSOsx6Dt35PluUhDoArCT0vB9LVgzIF2o2v8yuNxn4JJ /e4wuZAWevrbccth4DqS209HajgKtE9p4XN7ytzQ7v3cxfYAqHT0hZN2aBNszCEm OndU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 26 Apr 2013 14:57:17 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1501358802.1698.3764; Fri, 26 Apr 2013 14:57:17 -0400 Message-ID: <517ACDBC.2010408@isdg.net> Date: Fri, 26 Apr 2013 14:55:56 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <1638252.lDf4xVkYCO@scott-latitude-e6320> <517AB4AD.1090103@isdg.net> <1659315.HBOFQdbsc9@scott-latitude-e6320> In-Reply-To: <1659315.HBOFQdbsc9@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 18:57:21 -0000 There was nothing nefarious about what I stated. They did what any practical designer/developer MIGHT do - stick with the path of least resistance and propose what has worked for other similar protocols but more importantly provides the fastest market entry point solution. This is the only problem with the idea - everyone using TXT. Going with an new RRTYPE is simply nor practical. A TXT fall back would be required. Its better when they have their own name spaces, so it isn't a big issue. But SPF doesn't have its own name space. The issue remains, do you believe SPFBIS will get the endorsement of the DNS community to finally make SPF a IETF Standard? I personally believe many developers understand the practicalities, so SPFBIS may get many reluctant approvals for a TXT only solution. But it shouldn't eliminate what the functional specs should say for developers to program to be ready when the DNS servers do finally get updated to support unnamed type queries and passthrus with the recursion. Do we believe the DNS servers will get updated, one day? Can we encourage it, get the DNS vendors to join in enhancing software? On 4/26/2013 2:00 PM, Scott Kitterman wrote: > On Friday, April 26, 2013 01:09:01 PM Hector Santos wrote: >> On 4/26/2013 9:02 AM, Scott Kitterman wrote: >>> Since there wasn't the same screaming about DKIM, I wonder if this issue >>> is >>> really about the RR type at all or if it's really about the design >>> decision on where to place the record? It seems that SPF is not being >>> penalized in some form for having gone to the trouble of getting the type >>> assignment and giving it a go. >> >> In my view, the DKIM decision was entirely based on the fact SPF was >> getting a huge traction and adoption as a TXT solution. So why not for >> DKIM? It worked for SPF! >> >> We should also note the mindset were among the same authors for >> protocols that are now entirely TXT: >> >> SPF - 99/TXT, Levine against SPF, Murray wasn't around MARID >> DKIM - TXT only, Murray authored >> VBR - TXT only, Levine authored >> DMARK - TXT only, and now a new I-D by Murray >> SPFBIS - TXT only, Murray started SPFBIS. >> >> So we don't have too much "diversity" on the design. > > For DKIM and SPFbis there's a whole working group. Also DKIM has been through > not only working group last calls, but several IETF last calls. I think that > it's reasonable to conclude that there's IETF consensus around TXT plus and > underscored namespace being an OK solution to these kinds of problems. Trying > to pin this on a few people, particularly when decisions were made in working > groups that you participated in is just not correct. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From spf2@kitterman.com Fri Apr 26 11:59: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 F09C721F9987 for ; Fri, 26 Apr 2013 11:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrJsHKxduFOY for ; Fri, 26 Apr 2013 11:59:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 47BC321F9965 for ; Fri, 26 Apr 2013 11:59:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C007B20E40D5; Fri, 26 Apr 2013 14:59:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367002791; bh=6PH0l9Nd7eFhJjmYsVs5w9FtbCDd3V05S9zIZLEJStA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fbfur15Ki8CJS3lWf6q993i0n6asJI2s98sroYhfeMhFscljmmlJjoVcXjo/0cBmf We3XuMSsmeDzssS/efHfbvSAtZPjY2PhRT/mTpGAu2cGre/RION8GEm1Ww0fENWmSs mtlg3AMlObnJ0COwYpaysPdzmrN8klAtUkG+tyGg= 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 A252C20E40CF; Fri, 26 Apr 2013 14:59:51 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 14:59:50 -0400 Message-ID: <3278520.In0W6NM3sD@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160B14@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775160B14@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: Ted Lemon Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 18:59:53 -0000 On Friday, April 26, 2013 06:42:06 PM Ted Lemon wrote: > On Apr 26, 2013, at 12:53 PM, Barry Leiba wrote: > > It would also be good for ADs to put things into the last call > > notices, pointing out things that participants in other areas might > > want to look at. We don't have a habit of doing that, and we should. > > Even something like, "This specification involves aspects of > > [technology X] and [technology Y]; experts in those technologies > > should pay particular attention and provide reviews and comments," > > might make a big difference. > > Yes. > > > Why, specifically, is it bad to use TXT records in an "_spf." > > subdomain for this purpose? What harm does it cause, specifically. > > Let's bring that out clearly, and have that part of the discussion, > > > realizing that some possible arguments already have answers: > I think it's mostly harmless, but it's not what 4408bis does. Yes, but it's a useful discussion point because it helps clarify what the objection is. It appears that the primary objection is not use of TXT per se, but use of TXT in the name namespace of the domain. To the extent this may actually be a problem, it's trivially mitigated: example.com. 3600 IN TXT "v=spf1 redirect=_spf.example.com" _spf.example.com. 3600 IN TXT "v=spf1 [record content] -all" Most of the object to the current design seems highly emotional and not particularly empirically based. Scott K From ajs@anvilwalrusden.com Fri Apr 26 12:13: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 4E97821F999D for ; Fri, 26 Apr 2013 12:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.79 X-Spam-Level: X-Spam-Status: No, score=-0.79 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Qors9UICdEq for ; Fri, 26 Apr 2013 12:13:09 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id BDA9421F988E for ; Fri, 26 Apr 2013 12:13:09 -0700 (PDT) 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 C407C8A031 for ; Fri, 26 Apr 2013 19:13:08 +0000 (UTC) Date: Fri, 26 Apr 2013 15:13:07 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130426191306.GB809@mx1.yitter.info> References: <20130425013317.36729.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775160B14@mbx-01.win.nominum.com> <3278520.In0W6NM3sD@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3278520.In0W6NM3sD@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 19:13:10 -0000 No hat. On Fri, Apr 26, 2013 at 02:59:50PM -0400, Scott Kitterman wrote: > but use of TXT in the name namespace of the domain. To the extent this may > actually be a problem, it's trivially mitigated: > > example.com. 3600 IN TXT "v=spf1 redirect=_spf.example.com" > _spf.example.com. 3600 IN TXT "v=spf1 [record content] -all" That only partly mitigates it. You _still_ need the TXT record at example.com. That's one of the things those of us who find this an incredibly ugly wart object to: it uses one datatype for other data. More precisely, it uses a by-definition-unstructured datatype for structured data. It's unquestionalbly datatype abuse. I think the only question is whether the ship has left the barn; the answer is yes. A -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Fri Apr 26 12:22: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 0C90621F99B5 for ; Fri, 26 Apr 2013 12:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.639 X-Spam-Level: X-Spam-Status: No, score=-101.639 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olMobjIzGw-Q for ; Fri, 26 Apr 2013 12:22:31 -0700 (PDT) Received: from mail.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 16AEF21F99AD for ; Fri, 26 Apr 2013 12:22:30 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2392; t=1367004141; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=JTyUvp2 UkZdQEgvSLNp1j3akCI4=; b=C8v96IbHTId74pM41HqZ4BaYg5R9eciI59OfSQ9 s5uiPqCmfqIAPQxXtpkgUPwgi/Iz4N7T1gC7oHbXt4UNTNereEB2yjkykR+xBDbG DJ2Qes1tmMYIUyIl6TRlKMu5Ppxoxgrjtqa5BnddKy8vXjOURZemWS1TGH63+uBE hn7Y= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 26 Apr 2013 15:22:21 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1502861467.1698.5736; Fri, 26 Apr 2013 15:22:20 -0400 Message-ID: <517AD39B.3040403@isdg.net> Date: Fri, 26 Apr 2013 15:20:59 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman References: <20130425013317.36729.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775160B14@mbx-01.win.nominum.com> <3278520.In0W6NM3sD@scott-latitude-e6320> In-Reply-To: <3278520.In0W6NM3sD@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Ted Lemon Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 19:22:33 -0000 On 4/26/2013 2:59 PM, Scott Kitterman wrote: > On Friday, April 26, 2013 06:42:06 PM Ted Lemon wrote: >> On Apr 26, 2013, at 12:53 PM, Barry Leiba wrote: >>> It would also be good for ADs to put things into the last call >>> notices, pointing out things that participants in other areas might >>> want to look at. We don't have a habit of doing that, and we should. >>> Even something like, "This specification involves aspects of >>> [technology X] and [technology Y]; experts in those technologies >>> should pay particular attention and provide reviews and comments," >>> might make a big difference. >> >> Yes. >> >>> Why, specifically, is it bad to use TXT records in an "_spf." >>> subdomain for this purpose? What harm does it cause, specifically. >>> Let's bring that out clearly, and have that part of the discussion, >> >>> realizing that some possible arguments already have answers: >> I think it's mostly harmless, but it's not what 4408bis does. > > Yes, but it's a useful discussion point because it helps clarify what the > objection is. It appears that the primary objection is not use of TXT per se, > but use of TXT in the name namespace of the domain. To the extent this may > actually be a problem, it's trivially mitigated: > > example.com. 3600 IN TXT "v=spf1 redirect=_spf.example.com" > _spf.example.com. 3600 IN TXT "v=spf1 [record content] -all" > > Most of the object to the current design seems highly emotional and not > particularly empirically based. So this is where this wasted multiple calls came from? Can you imagine the huge waste of calls from large email senders/domains when their SPF is totally waste in processing with neutral and softfall results? All mail from Facebook.com, Gmail.com and Hotmail.com is SPF wasted called and all of them required at least two calls. Hotmail.com has 4 includes to "spf" identifying subdomains. And receivers with end users getting mail from the large ESPs is a major victim of this DNS waste! Facebook at least has a High Payoff with a -ALL (Fail) policy. Their domain will be protected from spoofing. Gmail.com and Hotmail.com won't be protected and are forcing all receivers to do at least TWO calls! I rather have emotion and passion in engineers than not at all. But this isn't that at all and its unfair to blab that out. -- HLS From spf2@kitterman.com Fri Apr 26 12:31: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 028FC21F99A5 for ; Fri, 26 Apr 2013 12:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhJ75e8jLwlb for ; Fri, 26 Apr 2013 12:31:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 15C0221F999E for ; Fri, 26 Apr 2013 12:30:59 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C4E9A20E40D5; Fri, 26 Apr 2013 15:30:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367004657; bh=gpLd7l1inrpa7hEYb+jM9lEEB039TOQQkwrVbaCu/UI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=M/3/DZIrSMBnHAIezb4pRkLs2xlQnvqpa3z9eP2PQhKI2fYdrMzj86pGJ82+s9UfO vFkBOurdnAG217ecdjmpk5cHHdgyb64qyb4caPIbiMneCZrnk6nMLGT3MsOkcA5hDi OStQbX0/N8iu4uz++UHxgNT6syRnUCaZL9dYCRj8= 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 A95C020E40CF; Fri, 26 Apr 2013 15:30:57 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 15:30:56 -0400 Message-ID: <2071555.BvHnxURCiI@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <517AD39B.3040403@isdg.net> References: <20130425013317.36729.qmail@joyce.lan> <3278520.In0W6NM3sD@scott-latitude-e6320> <517AD39B.3040403@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 19:31:01 -0000 On Friday, April 26, 2013 03:20:59 PM Hector Santos wrote: > On 4/26/2013 2:59 PM, Scott Kitterman wrote: > > On Friday, April 26, 2013 06:42:06 PM Ted Lemon wrote: > >> On Apr 26, 2013, at 12:53 PM, Barry Leiba wrote: > >>> It would also be good for ADs to put things into the last call > >>> notices, pointing out things that participants in other areas might > >>> want to look at. We don't have a habit of doing that, and we should. > >>> Even something like, "This specification involves aspects of > >>> [technology X] and [technology Y]; experts in those technologies > >>> should pay particular attention and provide reviews and comments," > >>> might make a big difference. > >> > >> Yes. > >> > >>> Why, specifically, is it bad to use TXT records in an "_spf." > >>> subdomain for this purpose? What harm does it cause, specifically. > >>> Let's bring that out clearly, and have that part of the discussion, > >> > >>> realizing that some possible arguments already have answers: > >> I think it's mostly harmless, but it's not what 4408bis does. > > > > Yes, but it's a useful discussion point because it helps clarify what the > > objection is. It appears that the primary objection is not use of TXT per > > se, but use of TXT in the name namespace of the domain. To the extent > > this may actually be a problem, it's trivially mitigated: > > > > example.com. 3600 IN TXT "v=spf1 > > redirect=_spf.example.com" > > _spf.example.com. 3600 IN TXT "v=spf1 [record content] -all" > > > > Most of the object to the current design seems highly emotional and not > > particularly empirically based. > > So this is where this wasted multiple calls came from? Can you imagine > the huge waste of calls from large email senders/domains when their SPF > is totally waste in processing with neutral and softfall results? > > All mail from Facebook.com, Gmail.com and Hotmail.com is SPF wasted > called and all of them required at least two calls. Hotmail.com has 4 > includes to "spf" identifying subdomains. And receivers with end users > getting mail from the large ESPs is a major victim of this DNS waste! > Facebook at least has a High Payoff with a -ALL (Fail) policy. Their > domain will be protected from spoofing. Gmail.com and Hotmail.com won't > be protected and are forcing all receivers to do at least TWO calls! > > I rather have emotion and passion in engineers than not at all. But > this isn't that at all and its unfair to blab that out. Large complex records (e.g. hotmail.com) are going to require multiple queries for includes due to their size and complexity independent of the RR type discussion. That comes from a need to avoid falling back to TCP for operational reliability. Once you throw multiple RR types into the mix, that just doubles the problem. I agree it's not pretty, but I don't see any measurable harm. Scott K From Ted.Lemon@nominum.com Fri Apr 26 12:43: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 0904F21F96E0 for ; Fri, 26 Apr 2013 12:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.307 X-Spam-Level: X-Spam-Status: No, score=-106.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjexTh0YAHST for ; Fri, 26 Apr 2013 12:43:50 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id AC46221F968B for ; Fri, 26 Apr 2013 12:43:50 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUXrY9saJxsrTDC2E3HLGwp38ArbwjDHr@postini.com; Fri, 26 Apr 2013 12:43:50 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4CE321B80E8 for ; Fri, 26 Apr 2013 12:43:50 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 447CF190061; Fri, 26 Apr 2013 12:43:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 12:43:50 -0700 From: Ted Lemon To: Scott Kitterman Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQp6UBXubqTI8/ESMN/lsrU52YZjpS5qAgAAE9gCAAAxKgA== Date: Fri, 26 Apr 2013 19:43:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775160C82@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775160B14@mbx-01.win.nominum.com> <3278520.In0W6NM3sD@scott-latitude-e6320> In-Reply-To: <3278520.In0W6NM3sD@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <47D58D4A613C3740822C922F6AAE6031@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 19:43:52 -0000 On Apr 26, 2013, at 2:59 PM, Scott Kitterman wrote: > Yes, but it's a useful discussion point because it helps clarify what the= =20 > objection is. It appears that the primary objection is not use of TXT pe= r se,=20 > but use of TXT in the name namespace of the domain. To the extent this m= ay=20 > actually be a problem, it's trivially mitigated: >=20 > example.com. 3600 IN TXT "v=3Dspf1 redirect=3D_spf.exampl= e.com" > _spf.example.com. 3600 IN TXT "v=3Dspf1 [record content] -all" Sure, but how does this win over just using SPF records? If your answer is "the middleware doesn't support it," I don't buy that=97t= hat was a valid argument five years ago, but not now. If it's "the provisioning systems don't support it," I still haven't heard = a convincing answer from anybody pushing this viewpoint. I'm not saying th= e argument is wrong; just that I haven't heard a good answer. The SPF rec= ord is just a TXT record with a different name; why is this hard, other tha= n in the sense of "we would like to continue running the code that we wrote= in 1995?" From spf2@kitterman.com Fri Apr 26 12:49: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 5E6AD21F990F for ; Fri, 26 Apr 2013 12:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4rMwm9w8CC5 for ; Fri, 26 Apr 2013 12:49:54 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A41E521F9909 for ; Fri, 26 Apr 2013 12:49:54 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2D8E820E40D5; Fri, 26 Apr 2013 15:49:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367005794; bh=nZiB9XTAZnu9k93KN9ry8Gdk1cKc4SHSP+HNuZ06xOQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LBu8jBZ8pfqVQneCiHyFpd7j/PLLv9PgV7NJIlM9rJSwcCf1p8LSdFkFkMgYKy6h3 PCqz/MC/KnizXECZb/fxQTERujttg0MeNnRPMo7AHqUSSwZHOlGxRxNGbTmdwm9TSJ lAIAhv2TPFCmXWWKjPd+Zn0U1Ip8+wEtqsvtKOfU= 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 11CD120E40CF; Fri, 26 Apr 2013 15:49:53 -0400 (EDT) From: Scott Kitterman To: Ted Lemon Date: Fri, 26 Apr 2013 15:49:53 -0400 Message-ID: <2550719.BGoZM8yNCR@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160C82@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <3278520.In0W6NM3sD@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160C82@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 19:49:55 -0000 On Friday, April 26, 2013 07:43:49 PM Ted Lemon wrote: > On Apr 26, 2013, at 2:59 PM, Scott Kitterman wro= te: > > Yes, but it's a useful discussion point because it helps clarify wh= at the > > objection is. It appears that the primary objection is not use of = TXT per > > se, but use of TXT in the name namespace of the domain. To the ext= ent > > this may actually be a problem, it's trivially mitigated: > >=20 > > example.com. 3600 IN TXT "v=3Dspf1 > > redirect=3D_spf.example.com" > > _spf.example.com. 3600 IN TXT "v=3Dspf1 [record content]= -all" >=20 > Sure, but how does this win over just using SPF records? >=20 > If your answer is "the middleware doesn't support it," I don't buy th= at=E2=80=94that > was a valid argument five years ago, but not now. >=20 > If it's "the provisioning systems don't support it," I still haven't = heard a > convincing answer from anybody pushing this viewpoint. I'm not sayin= g the > argument is wrong; just that I haven't heard a good answer. The SPF= > record is just a TXT record with a different name; why is this hard, = other > than in the sense of "we would like to continue running the code that= we > wrote in 1995?" Ask the vendors that don't provide it. I would imagine it's largely a=20= business decision where perceived ROI doesn't merit the investment. =20= Unfortunately such people don't generally participate in the IETF. Sho= uld=20 they/shouldn't they isn't the question. It'd do they. Even once they do, who cares. I recently noticed that at some point my= DNS=20 provider started offering type SPF records (no idea when they started),= but I=20 haven't bothered to publish them. Why not? It's not worth my time and= it's=20 just another chance to screw something up in my DNS. No ROI. Scott K From dougb@dougbarton.us Fri Apr 26 12:31: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 1803B21F99BC; Fri, 26 Apr 2013 12:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz2yY1YBUjSs; Fri, 26 Apr 2013 12:31:38 -0700 (PDT) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2256B21F99BA; Fri, 26 Apr 2013 12:31:38 -0700 (PDT) Received: from [IPv6:2001:470:d:5e7:bc8b:58b7:549d:818c] (unknown [IPv6:2001:470:d:5e7:bc8b:58b7:549d:818c]) by dougbarton.us (Postfix) with ESMTPSA id C3EAC22B11; Fri, 26 Apr 2013 19:31:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1367004697; bh=6H15Mw1ssOq7L2ZKPTtmjntMxzzF9yUXtSicA7tehbw=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=HdPGtalgzD0TXyB/picgV7ROq3Vb8URajpG3UaA4zozMB+HsoW9OTB66CE5XTtM3D RiqnRskDZwByQ++BsGxNMy+3wrUfsH/fhLfA7SKT/ME7CKoQewbXrHPVcXdmxA87Ka cPKmnbFnXZZ2DmD9abbkMRqCYBc8LC2uIthecJ8Y= Message-ID: <517AD619.3000406@dougbarton.us> Date: Fri, 26 Apr 2013 12:31:37 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 26 Apr 2013 12:50:28 -0700 Cc: "spfbis@ietf.org" , David Conrad , "dnsext@ietf.org Group" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 19:31:39 -0000 On 04/25/2013 11:30 PM, Murray S. Kucherawy wrote: > On Thu, Apr 25, 2013 at 11:05 PM, David Conrad > wrote: > > > So how much energy are the DNS experts going to put into cleaning > up their house while demanding the mail people clean up theirs? > > So, this is about revenge because it used to be hard to get RRtypes? > > > Did I really come across as that petty? Uncharitable interpretation of the current situation could come to that conclusion. > No, what I'm saying is that the way things were ten years ago As I (and others) have said many times, things were rough at the time SPF came to bloom. However, and this is really important to understand, it's not 10 years ago anymore. I'm not being petty when I say that. It really is important to understand, the time is going to pass anyway. In the time period between then and now a LOT of things have happened in the DNS world, and the situation is dramatically different now than it was. What is even more important to understand is that 10 years from now 10 more years will have passed. We have a chance now to set in motion events that will continue to improve the situation, so that 10 years from now we can look back and laugh at the SPF TXT record, and have joy that things are so much better. Or, we can spend 10 more years with the same silly kludge, and not have made any progress at all. Either way, the next 10 years are going to pass. > pushed the > SPF community to the place it's in now, ugly as it is. SPF, in the > interim, has become very widely deployed. And some of the software that handles SPF has already switched to querying SPF/99 first. There is no reason that the rest could not do that as well. Then by the time that the next version of SPF is released, it can be all SPF/99, and no TXT. Eventually the TXT record will die out altogether. As I have mentioned previously, in the DNS world we have a LOT of experience dealing with issues EXACTLY like this. We know how it works, we know what long tails look like, and we know that as problems go it's a pretty easy problem to deal with. > Suddenly now we have a few > voices from the ivory tower asserting that the same community needs to > go out and re-do things the way they should have been done in the first > place, now that we finally have a somewhat more reasonable perspective, > even though some of the vestiges of ten years ago are in fact still > around. My reaction to that is "You can't be serious." That doesn't > sound like revenge at all to me, just pragmatism. Um, it's not "suddenly." The advice to do it right in the first place has been offered repeatedly, since the very beginning. That's why the code point was assigned in the first place. There is no doubt that in the early days, prior to the widespread deployment of 3597, querying for SPF/99 could cause problems. But we're not in that world anymore. Thank DNSSEC and IPv6 for shaking things loose. There is currently no TECHNICAL reason that the change cannot be made NOW to query SPF/99 first. The only argument you (and others) have put forward so far is, "We have been using TXT, it works, so we want to keep using it." I understand why that course of action is attractive, but it's bad. And the right thing isn't hard to do. > The point is that it isn't just fine. It does have operational > impacts, from potentially increased fragmentation/fallback to TCP to > increased complexity in TXT RR parsers that have to distinguish > between the myriad of crap that's residing at the zone apex TXT RR, > etc. Of course, most of these negative impacts are hidden to the > folks who are putting the TXT RRs in the zone, so it's all good, right? > > > Thus, I maintain that we take our licks on this one and just take > steps to ensure that nobody follows this path again. > > And how do you propose that exactly, particularly given the > precedent set by SPFBIS? > > > Someone else (Joe, I think) has already referred to other RFCs that talk > about things like IAB advice about how [not] to put application data > into the DNS. Seems to me this is a perfectly good subject for another > such project. One may counter that by saying nobody will pay attention > to such a document, but I submit that it's our primary mechanism for > making sure mistakes aren't re-made, so that's the tool we have to use > or not use. But this mistake isn't carved in stone. It CAN be fixed. And the solution isn't difficult. Some minor changes are made to software, some docs are updated, and then time passes and the old way becomes obsolete. > If we do the opposite and somehow compel SPFBIS to favour type 99 over > TXT, then I still think we'll be shouting that to an audience that will > think we're nuts and simply go about their business. If that happens (and I personally don't think it will), it's not the IETF's problem. We don't (traditionally) write specs to accommodate the worst behavior we see in implementations. We write specs to describe how it should be done right, and do our best to support people who want to write software that does it right. And I should emphasize again, "Mail::SPF (which is used by Spamassassin) checks for Type SPF first by default." So there is already a non-trivial implementation that is doing it right. The number of other implementations that need to be updated is not very large. Another case mentioned in the spfbis thread on "issue #9" was the python lib for spf, which already has the code to query SPF/99. It would be a 30 minute job to update that to query 99 first. So if I'm missing some TECHNICAL reasons why this proposal isn't feasible, please enlighten me. But all I've seen so far is, "We don't want to do it," which I don't find particularly compelling. Doug From Ted.Lemon@nominum.com Fri Apr 26 12:55: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 AF63421F9909 for ; Fri, 26 Apr 2013 12:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.328 X-Spam-Level: X-Spam-Status: No, score=-106.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Drjg-NJ1xNDq for ; Fri, 26 Apr 2013 12:55:54 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBC921F9996 for ; Fri, 26 Apr 2013 12:55:50 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUXrbxhQhzuO3RWqGThg+MuCyiPDz0awK@postini.com; Fri, 26 Apr 2013 12:55:50 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3D8EE1B80E8 for ; Fri, 26 Apr 2013 12:55:50 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 37812190061; Fri, 26 Apr 2013 12:55:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 12:55:50 -0700 From: Ted Lemon To: Scott Kitterman Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQp6UBXubqTI8/ESMN/lsrU52YZjpS5qAgAAE9gCAAAxKgIAAAbKAgAABqIA= Date: Fri, 26 Apr 2013 19:55:50 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775160CF9@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <3278520.In0W6NM3sD@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160C82@mbx-01.win.nominum.com> <2550719.BGoZM8yNCR@scott-latitude-e6320> In-Reply-To: <2550719.BGoZM8yNCR@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C3B9924BC6C6B499180FAEDA881D772@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 19:55:54 -0000 On Apr 26, 2013, at 3:49 PM, Scott Kitterman wrote: > Ask the vendors that don't provide it. I would imagine it's largely a=20 > business decision where perceived ROI doesn't merit the investment. =20 > Unfortunately such people don't generally participate in the IETF. Shoul= d=20 > they/shouldn't they isn't the question. It'd do they. >=20 > Even once they do, who cares. I recently noticed that at some point my D= NS=20 > provider started offering type SPF records (no idea when they started), b= ut I=20 > haven't bothered to publish them. Why not? It's not worth my time and i= t's=20 > just another chance to screw something up in my DNS. No ROI. Okay. But using _spf.domain requires significant provisioning changes. = It requires you to update your DNS. Why is there ROI here, but not in sim= ply using the already documented solution to the problem? From spf2@kitterman.com Fri Apr 26 13:06:42 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 3915021F998C for ; Fri, 26 Apr 2013 13:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYgA+sLlxVSi for ; Fri, 26 Apr 2013 13:06:41 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAEB21F999B for ; Fri, 26 Apr 2013 13:06:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B163220E40D5; Fri, 26 Apr 2013 16:06:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367006799; bh=Zw8NuRgQt3bGZktkIuJFslfZWXyvVCn5WvDBvU6RWBQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LGWDUtLeCwgxQB9/6aw5SpzP3H5z3NNsouoQix0QtkshmRWA133oi4e2rIbmLmi26 j/wquDvMVHeGebQ10PS/ujoi7doGfmiLIkMQ1fZjrusDLBfRoZU8Vklk9KLUvpcS9X 3rg6IZjrv+ADgk1gDSv2gYUjtQjKooshaicRscCI= 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 933B020E40CF; Fri, 26 Apr 2013 16:06:39 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 16:06:38 -0400 Message-ID: <1453053.12BnJ8GF9f@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160CF9@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <2550719.BGoZM8yNCR@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160CF9@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: Ted Lemon Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:06:42 -0000 On Friday, April 26, 2013 07:55:50 PM Ted Lemon wrote: > On Apr 26, 2013, at 3:49 PM, Scott Kitterman wrote: > > Ask the vendors that don't provide it. I would imagine it's largely a > > business decision where perceived ROI doesn't merit the investment. > > Unfortunately such people don't generally participate in the IETF. Should > > they/shouldn't they isn't the question. It'd do they. > > > > Even once they do, who cares. I recently noticed that at some point my > > DNS > > provider started offering type SPF records (no idea when they started), > > but I haven't bothered to publish them. Why not? It's not worth my time > > and it's just another chance to screw something up in my DNS. No ROI. > > Okay. But using _spf.domain requires significant provisioning changes. > It requires you to update your DNS. Why is there ROI here, but not in > simply using the already documented solution to the problem? No, it doesn't. The provisioning changes needed for _spf have been needed by _domainkeys for a long time. In that case there was no alternative and a lot of deployment momentum, so providers did suddenly discover that hosts and domains weren't the same thing after all and remove restrictions on use of underscore. To me, managing two sets of identical record would cause work and increased risk of error for zero benefit. I don't view that as a wise investment of my time. I know you won't agree with it, but I think it's a perfectly rationale view and one that's common outside the IETF. Also, the underscore trick requires a one time change. Double publishing SPF records for two RR types requires double changes every time the record is changed, so it's not comparable. Scott K From Ted.Lemon@nominum.com Fri Apr 26 13:11: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 425D721F99AA for ; Fri, 26 Apr 2013 13:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.346 X-Spam-Level: X-Spam-Status: No, score=-106.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIpmmWi320jW for ; Fri, 26 Apr 2013 13:11:03 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB1721F99A0 for ; Fri, 26 Apr 2013 13:11:03 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUXrfVt1oONyCHn3BWMfEd+GZ/6oNQ3c5@postini.com; Fri, 26 Apr 2013 13:11:03 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C39111B80E6 for ; Fri, 26 Apr 2013 13:11:01 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BD870190061; Fri, 26 Apr 2013 13:11:01 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 13:11:01 -0700 From: Ted Lemon To: Scott Kitterman Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQp6UBXubqTI8/ESMN/lsrU52YZjpS5qAgAAE9gCAAAxKgIAAAbKAgAABqICAAAMGAIAAATgA Date: Fri, 26 Apr 2013 20:11:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <2550719.BGoZM8yNCR@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160CF9@mbx-01.win.nominum.com> <1453053.12BnJ8GF9f@scott-latitude-e6320> In-Reply-To: <1453053.12BnJ8GF9f@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:11:10 -0000 On Apr 26, 2013, at 4:06 PM, Scott Kitterman wrote: > Also, the underscore trick requires a one time change. Double publishing= SPF=20 > records for two RR types requires double changes every time the record is= =20 > changed, so it's not comparable. You'd have to double publish either way. From spf2@kitterman.com Fri Apr 26 13:13: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 CF12321F99A7 for ; Fri, 26 Apr 2013 13:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oG+F95wK8kg for ; Fri, 26 Apr 2013 13:13:01 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 30F1D21F99A5 for ; Fri, 26 Apr 2013 13:13:01 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9BE5320E40D5; Fri, 26 Apr 2013 16:13:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367007180; bh=6xQVySeTfqe5LFbM3MMMoUyiSrpFDVHpS+0y0VUPers=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=l2IK2TWznNvlj3I56XWKlK1JaCBbtfqLhfHk4hTqJi43X1jLxxF0FIgsUYgU2b5xP vHv6cMSSVmP3wPgesKP9YtNcDzwBoKX2He9g/SBJphBCtps5yxAARDqTYtsvYlSBBB HGIFqvhSP4+4OYZHAg+m57koDJ/+6wXHngz01TiQ= 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 84EAD20E40CF; Fri, 26 Apr 2013 16:13:00 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 16:12:59 -0400 Message-ID: <1538026.HyQorgixtm@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <1453053.12BnJ8GF9f@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: Ted Lemon Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:13:01 -0000 On Friday, April 26, 2013 08:11:01 PM Ted Lemon wrote: > On Apr 26, 2013, at 4:06 PM, Scott Kitterman wrote: > > Also, the underscore trick requires a one time change. Double publishing > > SPF records for two RR types requires double changes every time the > > record is changed, so it's not comparable. > > You'd have to double publish either way. No. When doing the underscore bit the domain level record is static. You change it to a pointer somewhere else and never touch it again (where never is until your underscore record gets so big you need two, but not many domains need that). Scott K From Ted.Lemon@nominum.com Fri Apr 26 13:15: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 636A121F99A9 for ; Fri, 26 Apr 2013 13:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.362 X-Spam-Level: X-Spam-Status: No, score=-106.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWnFzQtU2yEG for ; Fri, 26 Apr 2013 13:15:21 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id D6F6521F99A7 for ; Fri, 26 Apr 2013 13:15:20 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUXrgWH/f1ExQyLPsnv0/ekV2hlPecsRR@postini.com; Fri, 26 Apr 2013 13:15:20 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 603CF1B80E8 for ; Fri, 26 Apr 2013 13:15:20 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 521BA190064; Fri, 26 Apr 2013 13:15:20 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 13:15:20 -0700 From: Ted Lemon To: Scott Kitterman Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQp6UBXubqTI8/ESMN/lsrU52YZjpS5qAgAAE9gCAAAxKgIAAAbKAgAABqICAAAMGAIAAATgAgAAAjoCAAAClAA== Date: Fri, 26 Apr 2013 20:15:19 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <1453053.12BnJ8GF9f@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> <1538026.HyQorgixtm@scott-latitude-e6320> In-Reply-To: <1538026.HyQorgixtm@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <86C0DFD6004129468EEB9E2D09FCE4CC@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:15:21 -0000 On Apr 26, 2013, at 4:12 PM, Scott Kitterman wrote: > No. When doing the underscore bit the domain level record is static. Yo= u=20 > change it to a pointer somewhere else and never touch it again (where nev= er is=20 > until your underscore record gets so big you need two, but not many domai= ns=20 > need that). You still have to make the change. And this doesn't actually solve the pr= oblem with TXT records on the domain. It just makes it less bad. If you= have 37 text records, this isn't going to prevent the MTA having to fall b= ack to TCP. From spf2@kitterman.com Fri Apr 26 13:17: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 0CBBD21F99BC for ; Fri, 26 Apr 2013 13:17:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61ne3s3Izxho for ; Fri, 26 Apr 2013 13:17:40 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 47F8B21F99AD for ; Fri, 26 Apr 2013 13:17:40 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C2EF520E40D5; Fri, 26 Apr 2013 16:17:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367007459; bh=ZTdSbQ/OdvKw3OuGO2xhzCwHnKoCvHfZicKEdFgJVnI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ivbBxFH+8VIeX/EgYXVXmRxUwbgPnEnBDDcWSegSNitdZANiotIazOV6piW0RBCHm p1diz5fSN/6KCUQYr9t+717tbJA23w4//N8uDTwNl6Q9kWM79mTBYyJZ/+UD4WeWFB vhlLRpEftXWWMFp91XNX6s61FZaYLxYuRT1ucatc= 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 A725120E40CF; Fri, 26 Apr 2013 16:17:39 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 16:17:38 -0400 Message-ID: <1904246.GKbtVlPDWo@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <1538026.HyQorgixtm@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: Ted Lemon Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:17:41 -0000 On Friday, April 26, 2013 08:15:19 PM Ted Lemon wrote: > On Apr 26, 2013, at 4:12 PM, Scott Kitterman wrote: > > No. When doing the underscore bit the domain level record is static. You > > change it to a pointer somewhere else and never touch it again (where > > never is until your underscore record gets so big you need two, but not > > many domains need that). > > You still have to make the change. And this doesn't actually solve the > problem with TXT records on the domain. It just makes it less bad. If > you have 37 text records, this isn't going to prevent the MTA having to > fall back to TCP. I agree it's not a complete solution, but if you have 37 TXT records it's pretty arbitrary which one you decide gets the blame for falling back to TCP. It's a 99.9% solution and that's good enough. Scott K From dotzero@gmail.com Fri Apr 26 13:19: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 E4E4A21F968B for ; Fri, 26 Apr 2013 13:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrsUKV3a67Ad for ; Fri, 26 Apr 2013 13:19:43 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7897721F965C for ; Fri, 26 Apr 2013 13:19:42 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id ep20so216157lab.10 for ; Fri, 26 Apr 2013 13:19:41 -0700 (PDT) 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=LMZyyjnbAqKE0ABFN1IQLt/mVL/zX6r3eHAoXQmcPFA=; b=FA1eXZMte5YOb9+tVJgDWycp/vynCTYtUx4C3B1Xb0obateR9mbG/pZdgNFHciCTAD raLxiZ9e7VAt8gWSSlVni8BtYi+5k+8M9eIoVVT5RPOVvZaRuHwOEfb/LhYfuR3YsCiL KZjZrz2SJuW2LIZMQqcxPBd58948dMgkIQ33uYu4G47mZtksV7Sv61/M1EK3cKwyCQMs vpm0+9DjlsXpu7b7kJPoWEtaL86NjBgW/WWKBytl66RbVhbrVv39lf/8/2Mw//mP7qwR Z+UPmfg0Puv+8k0AUmZ5uAO/O5svINbsq7NLzKVl41S5ES1Pi7UrEt/QaWu+vnOmwz1Y D5bA== MIME-Version: 1.0 X-Received: by 10.152.6.10 with SMTP id w10mr23165644law.30.1367007581302; Fri, 26 Apr 2013 13:19:41 -0700 (PDT) Received: by 10.112.72.166 with HTTP; Fri, 26 Apr 2013 13:19:41 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <1453053.12BnJ8GF9f@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> <1538026.HyQorgixtm@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> Date: Fri, 26 Apr 2013 16:19:41 -0400 Message-ID: From: Dotzero To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , Scott Kitterman Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:19:44 -0000 On Fri, Apr 26, 2013 at 4:15 PM, Ted Lemon wrote: > On Apr 26, 2013, at 4:12 PM, Scott Kitterman wrote: >> No. When doing the underscore bit the domain level record is static. You >> change it to a pointer somewhere else and never touch it again (where never is >> until your underscore record gets so big you need two, but not many domains >> need that). > > You still have to make the change. And this doesn't actually solve the problem with TXT records on the domain. It just makes it less bad. If you have 37 text records, this isn't going to prevent the MTA having to fall back to TCP. > > If you have 37 text records for a single name space you have a very interesting record. Could you provide some legitimate examples of this in the wild that the WG could consider? Mike From spf2@kitterman.com Fri Apr 26 13:21: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 A421921F989C for ; Fri, 26 Apr 2013 13:21:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUnccG-Khq9I for ; Fri, 26 Apr 2013 13:21:13 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F01E421F9849 for ; Fri, 26 Apr 2013 13:21:12 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7BA8C20E40D5; Fri, 26 Apr 2013 16:21:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367007672; bh=YXa+/DOb+Uc2h5EDH/i4BwLmMe4LYdXNrDw8fE73iWM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SEu9GfhlAdwGXfZDR4xkyTpLcD1tiUdbeAZUKUufKcp8fMiUJPGlLzOfwaE2Kftqf V17HYkrLzwGJrMr9aSooOMTK6k6imREONEnvWtHItc1IJFy88wpUy+zytRIrpzJBh5 dDH36/Y1LQL/TT5k9TvkUGG61kQB/KC3oWZZfR1U= 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 5DCC620E40CF; Fri, 26 Apr 2013 16:21:11 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 16:21:11 -0400 Message-ID: <2329139.m4pBbo4xRc@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <20130425013317.36729.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.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] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:21:13 -0000 On Friday, April 26, 2013 04:19:41 PM Dotzero wrote: > On Fri, Apr 26, 2013 at 4:15 PM, Ted Lemon wrote: > > On Apr 26, 2013, at 4:12 PM, Scott Kitterman wrote: > >> No. When doing the underscore bit the domain level record is static. > >> You > >> change it to a pointer somewhere else and never touch it again (where > >> never is until your underscore record gets so big you need two, but not > >> many domains need that). > > > > You still have to make the change. And this doesn't actually solve the > > problem with TXT records on the domain. It just makes it less bad. If > > you have 37 text records, this isn't going to prevent the MTA having to > > fall back to TCP. > If you have 37 text records for a single name space you have a very > interesting record. Could you provide some legitimate examples of this > in the wild that the WG could consider? msk (IIRC) found one in his data survey. Scott K From dhc@dcrocker.net Fri Apr 26 13:24: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 EA68521F9846; Fri, 26 Apr 2013 13:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs7xFgtv0DO6; Fri, 26 Apr 2013 13:24:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 55AD621F982C; Fri, 26 Apr 2013 13:24:56 -0700 (PDT) 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 r3QKOq5s013108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 13:24:56 -0700 Message-ID: <517AE290.6030303@dcrocker.net> Date: Fri, 26 Apr 2013 13:24:48 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> In-Reply-To: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> 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.66]); Fri, 26 Apr 2013 13:24:56 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:24:57 -0000 On 4/23/2013 3:03 PM, S Moonesamy wrote: > Hello, > > Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: > > 'IANA is requested to add an annotation to the SPF RRTYPE saying > "(OBSOLETE - use TXT)" in the DNS Parameters registry.' > > Is the annotation in the DNS Parameters registry correct? Dear DNSEXT, For all of the really interesting side discussions that have developed since SM sent this initial query, I believe there have not been any responses that answered the question that was asked. DNSEXT was asked to provide expert review of this specific bit of text. The text is intended to be comparable to the way that some other, similar situations have already been handled. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Ted.Lemon@nominum.com Fri Apr 26 13:25: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 D06A921F99BC for ; Fri, 26 Apr 2013 13:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.376 X-Spam-Level: X-Spam-Status: No, score=-106.376 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbBdUXF8QPDv for ; Fri, 26 Apr 2013 13:25:50 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8EC21F986C for ; Fri, 26 Apr 2013 13:25:50 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUXrizpZj8Uhf6D+nkdvtP5Y9kgt2xGPz@postini.com; Fri, 26 Apr 2013 13:25:50 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0D6901B80E6 for ; Fri, 26 Apr 2013 13:25:50 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 06F21190061; Fri, 26 Apr 2013 13:25:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 13:25:50 -0700 From: Ted Lemon To: Dotzero Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQp6UBXubqTI8/ESMN/lsrU52YZjpS5qAgAAE9gCAAAxKgIAAAbKAgAABqICAAAMGAIAAATgAgAAAjoCAAAClAIAAATqAgAABt4A= Date: Fri, 26 Apr 2013 20:25:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775160DC3@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <1453053.12BnJ8GF9f@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> <1538026.HyQorgixtm@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2685D2D6B953D347B31946F4AA6883F5@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Scott Kitterman Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:25:50 -0000 On Apr 26, 2013, at 4:19 PM, Dotzero wrote: > If you have 37 text records for a single name space you have a very > interesting record. Could you provide some legitimate examples of this > in the wild that the WG could consider? It was given as an example earlier; you'd have to ask the person who cited = it. From Ted.Lemon@nominum.com Fri Apr 26 13:29: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 BE5B321F99D3 for ; Fri, 26 Apr 2013 13:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.388 X-Spam-Level: X-Spam-Status: No, score=-106.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tMjhX88OYAM for ; Fri, 26 Apr 2013 13:29:10 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3B62D21F9909 for ; Fri, 26 Apr 2013 13:29:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUXrjlegarG2mTHPQUmQsIftuRd9tOdu8@postini.com; Fri, 26 Apr 2013 13:29:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CB2271B80E8 for ; Fri, 26 Apr 2013 13:29:09 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C3DA7190061; Fri, 26 Apr 2013 13:29:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 13:29:09 -0700 From: Ted Lemon To: Scott Kitterman Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQp6UBXubqTI8/ESMN/lsrU52YZjpS5qAgAAE9gCAAAxKgIAAAbKAgAABqICAAAMGAIAAATgAgAAAjoCAAAClAIAAAKcAgAADNwA= Date: Fri, 26 Apr 2013 20:29:08 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775160DFF@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <1538026.HyQorgixtm@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> <1904246.GKbtVlPDWo@scott-latitude-e6320> In-Reply-To: <1904246.GKbtVlPDWo@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <9F3730616EB32F439EBB8DFBD629419F@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:29:10 -0000 On Apr 26, 2013, at 4:17 PM, Scott Kitterman wrote: >> You still have to make the change. And this doesn't actually solve the >> problem with TXT records on the domain. It just makes it less bad. I= f >> you have 37 text records, this isn't going to prevent the MTA having to >> fall back to TCP. >=20 > I agree it's not a complete solution, but if you have 37 TXT records it's= =20 > pretty arbitrary which one you decide gets the blame for falling back to = TCP. =20 > It's a 99.9% solution and that's good enough. Excellent rhetorical judo. But I refuted your main point, and your rejoin= der didn't address my refutation, so I assume you agree: this doesn't actua= lly make anything better, because you still have to update both the top-lev= el DNS and the _spf entry, and you have to have a TXT record at the top lev= el. If having a TXT record at the top level is okay, your proposed fix ad= ds nothing; if it is not okay, your solution doesn't address the problem. From spf2@kitterman.com Fri Apr 26 13:34: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 5870021F9950 for ; Fri, 26 Apr 2013 13:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm+ttOU7nQqV for ; Fri, 26 Apr 2013 13:34:07 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFFC21F9947 for ; Fri, 26 Apr 2013 13:34:07 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1331520E40D5; Fri, 26 Apr 2013 16:34:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367008447; bh=XuvOvy+zL8Lg7pRjAqwaCfPmy3uFayKHJHpT9fj0KrE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=m919MKGVuBmgfhxecUtHSQmgtHYQKXV03jHbCNip80iygYG+/4AoAox6NX3hkVl0A 86fxpIgkOR5OLlIRFkYoH+FTOmt62sCCD0UunBAWi0bo0HZYwtLuMhuytQfG8yMTau xE9jgOSErBbfil7wBcXKL0Ln46jPSLwXtvyrFRfY= 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 ED4ED20E40CF; Fri, 26 Apr 2013 16:34:06 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 16:34:05 -0400 Message-ID: <1947641.qMtMBB5hPF@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160DFF@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <1904246.GKbtVlPDWo@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160DFF@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: Ted Lemon Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:34:08 -0000 On Friday, April 26, 2013 08:29:08 PM Ted Lemon wrote: > On Apr 26, 2013, at 4:17 PM, Scott Kitterman wrote: > >> You still have to make the change. And this doesn't actually solve the > >> problem with TXT records on the domain. It just makes it less bad. If > >> you have 37 text records, this isn't going to prevent the MTA having to > >> fall back to TCP. > > > > I agree it's not a complete solution, but if you have 37 TXT records it's > > pretty arbitrary which one you decide gets the blame for falling back to > > TCP. It's a 99.9% solution and that's good enough. > > Excellent rhetorical judo. But I refuted your main point, and your > rejoinder didn't address my refutation, so I assume you agree: this doesn't > actually make anything better, because you still have to update both the > top-level DNS and the _spf entry, and you have to have a TXT record at the > top level. If having a TXT record at the top level is okay, your proposed > fix adds nothing; if it is not okay, your solution doesn't address the > problem. I don't know how to be clearer, so I'll just stop. Scott K From dotzero@gmail.com Fri Apr 26 13:41: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 8DFCC21F99C4 for ; Fri, 26 Apr 2013 13:41:19 -0700 (PDT) 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.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiMen+8W7vR8 for ; Fri, 26 Apr 2013 13:41:19 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9B43A21F99B5 for ; Fri, 26 Apr 2013 13:41:18 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id y8so4161863lbh.35 for ; Fri, 26 Apr 2013 13:41:17 -0700 (PDT) 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=A6YOKuqkpO+LWnrqDlC8ZvrCcRdu2JXP0cm4syQUXac=; b=JrxbTkB1d3z2PMfuQlZxObBVVQQHJAE3MWtde//NCi9UmISlhK+ftbC/M6qEXnL2sG yLSFHkouoDmABY5a9dD5/R4Lgp7Iw/3noMxDpv0/PwuNdQpx1LcHUGS1onCLCk6MOelO Kbu4ievgwf48eov4M6l10WwpuTACd/T9HhzTvIfd4+i3b9GglGPjpw/GwFr764X4nbC7 8RAYrMScEFSVjAdHx90owNEW6h/1fC43WTgx3igurCG5M3ViY2d6R7mKVZ+VPSSYAmXw RgtnA8a5MDmoAFxOEyO/ZogEs/r8bfSj2uERU5+G4qa/EmME7d2yKxASas6RWcd6s7K+ SVkg== MIME-Version: 1.0 X-Received: by 10.112.160.130 with SMTP id xk2mr2963294lbb.1.1367008536003; Fri, 26 Apr 2013 13:35:36 -0700 (PDT) Received: by 10.112.72.166 with HTTP; Fri, 26 Apr 2013 13:35:35 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160DC3@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <1453053.12BnJ8GF9f@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> <1538026.HyQorgixtm@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775160DC3@mbx-01.win.nominum.com> Date: Fri, 26 Apr 2013 16:35:35 -0400 Message-ID: From: Dotzero To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , Scott Kitterman Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:41:19 -0000 On Fri, Apr 26, 2013 at 4:25 PM, Ted Lemon wrote: > On Apr 26, 2013, at 4:19 PM, Dotzero wrote: >> If you have 37 text records for a single name space you have a very >> interesting record. Could you provide some legitimate examples of this >> in the wild that the WG could consider? > > It was given as an example earlier; you'd have to ask the person who cited it. > And that is exactly my point (I was waiting for folks to pounce) ..... there is a SINGLE example that foks are pointing to. I'm sure that with some level of effort someone can find a second example. In the greater scheme of things it doesn't even rise to the level of noise and is irrelevent to the discussion. If it were represented that 37 text records were found a significant percentage of the time AND that SPF records were a significant factor THEN we might have a discussion about this horrible problem SPF text records are creating. Mike From dhc2@dcrocker.net Fri Apr 26 13:44: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 C112A21F9954; Fri, 26 Apr 2013 13:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPQYMOPs+BHV; Fri, 26 Apr 2013 13:43:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 16DDE21F962B; Fri, 26 Apr 2013 13:43:59 -0700 (PDT) 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 r3QKhtCF019402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 13:43:58 -0700 Message-ID: <517AE707.4000206@dcrocker.net> Date: Fri, 26 Apr 2013 13:43:51 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dnsext@ietf.org References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> In-Reply-To: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> 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.66]); Fri, 26 Apr 2013 13:43:58 -0700 (PDT) X-Mailman-Approved-At: Fri, 26 Apr 2013 13:58:56 -0700 Cc: spfbis@ietf.org Subject: Re: [spfbis] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:44:00 -0000 On 4/23/2013 3:03 PM, S Moonesamy wrote: > Hello, > > Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: > > 'IANA is requested to add an annotation to the SPF RRTYPE saying > "(OBSOLETE - use TXT)" in the DNS Parameters registry.' > > Is the annotation in the DNS Parameters registry correct? Dear DNSEXT, For all of the really interesting side discussions that have developed since SM sent this initial query, I believe there have not been any responses that answered the question that was asked. DNSEXT was asked to provide expert review of this specific bit of text. The text is intended to be comparable to the way that some other, similar situations have already been handled. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From drc@virtualized.org Fri Apr 26 13:55: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 3F8D821F986C; Fri, 26 Apr 2013 13:55:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+b-msTPoZ4e; Fri, 26 Apr 2013 13:55:09 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE6F21F9855; Fri, 26 Apr 2013 13:55:02 -0700 (PDT) Received: from [172.20.1.101] (unknown [12.6.90.3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 6224017166; Fri, 26 Apr 2013 20:55:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: David Conrad In-Reply-To: <517AE707.4000206@dcrocker.net> Date: Fri, 26 Apr 2013 15:55:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <43923FD8-D99E-4297-82CF-F5F5C9040C29@virtualized.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <517AE707.4000206@dcrocker.net> To: Dave Crocker X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Fri, 26 Apr 2013 13:59:05 -0700 Cc: spfbis@ietf.org, dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 20:55:19 -0000 Dave, As I pointed out to Paul Hoffman, the message I sent that I believe = started this thread said: "It is in keeping with past practice, e.g., see the notations for MD, = MF, A6, and the MAILA RRtypes at = http://www.iana.org/assignments/dns-parameters/dns-parameters.xml." Regards, -drc On Apr 26, 2013, at 3:43 PM, Dave Crocker wrote: > On 4/23/2013 3:03 PM, S Moonesamy wrote: >> Hello, >>=20 >> Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF = RRTYPE: >>=20 >> 'IANA is requested to add an annotation to the SPF RRTYPE saying >> "(OBSOLETE - use TXT)" in the DNS Parameters registry.' >>=20 >> Is the annotation in the DNS Parameters registry correct? >=20 >=20 > Dear DNSEXT, >=20 > For all of the really interesting side discussions that have developed = since SM sent this initial query, I believe there have not been any = responses that answered the question that was asked. >=20 > DNSEXT was asked to provide expert review of this specific bit of = text. The text is intended to be comparable to the way that some other, = similar situations have already been handled. >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From johnl@iecc.com Fri Apr 26 14:14: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 4588A21F99F5 for ; Fri, 26 Apr 2013 14:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMjIRGb+M1FZ for ; Fri, 26 Apr 2013 14:14:02 -0700 (PDT) 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 9B52B21F999B for ; Fri, 26 Apr 2013 14:13:54 -0700 (PDT) Received: (qmail 58923 invoked from network); 26 Apr 2013 21:13:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Apr 2013 21:13:53 -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; s=517aee11.xn--hew.k1304; i=johnl@user.iecc.com; bh=g9QIKoXUbO1xM6mLOL/CkWvMEAQFFcH5uYgp9BQhTeM=; b=TTwnVw3KmsZDC7CeUpWTRUyhyDwnrii02c8HE9zn0HqMnn+MGzgokNOg3hcrVq204gzfXVmoEg72+Ic7Yy97Nn3lEUrJBonZw0Fwfv4ZgXhs1vPbggy5TSu2qy8IWMZtQVuXPC5wrCYaqeDFSCe/u+TEjM74KW4cWA72CU6FL/s= 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; s=517aee11.xn--hew.k1304; olt=johnl@user.iecc.com; bh=g9QIKoXUbO1xM6mLOL/CkWvMEAQFFcH5uYgp9BQhTeM=; b=VJBh5YhjKmz2vpDvW0Io2CKc3k7P054mNE704oZvh6pYzZvbCLFlvXLpSA/OooEUPLaZ4MZNgEBnphU/1IGlrW/Ce3kwtmV45Jwpkf9g2OVFaK+4BlUqhWc8EBG38Puj7WjV3L5lnbnfMOFfeT6+SX8cKQZy+9F4N36+s5+0U0E= Date: 26 Apr 2013 21:13:31 -0000 Message-ID: <20130426211331.74958.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160234@mbx-01.win.nominum.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: Ted.Lemon@nominum.com Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 21:14:03 -0000 >Okay, fair enough. Please do note that I didn't say that there was process breakage—I said the process >seemed to have been followed correctly, but produced a less than perfect outcome. We understand that it's not the outcome that you'd like, but it's absolutely the outcome that the data supports. I have to ask, is there any amount of data that would change your opinion here? If not, we're having a religious argument, not an engineering one, and there's no point to continuing. >2. Because TXT records aren't specific to SPF, a query for TXT records may return an unexpectedly large >result set, requiring fallback to TCP. >Rejoinder: doesn't seem to be an issue in practice. > >That's not correct; there are still packet filters out there configured by default to disallow TCP over >port 53. We discovered this during the RFC6686 surveys. > >These two points taken together seem like a pretty strong argument in favor of _not_ deprecating the SPF >record; in this case, only the SPF record would have made it back to the MTA. Well, actually, complex SPF records can easily blow past 500 characters all by themselves. This issue is well known among people who use SPF, and there is a well known workaround that Scott mentioned a few messages back. As should be obvious, if we were using type 99 records, we would have the exact same issue, and would address it with the exact same workaround. There truly is no problem at this point that type 99 solves, and several well documented ones that it causes. Is it really appropriate for someone who is this unfamiliar with a protocol as widely deployed as SPF (viz. the ~400,000 domains found in the RFC 6686 surveys, and the many years of experience by WG members, some at very large mail systems) to be demanding last minute redesigns? R's, John From dhc2@dcrocker.net Fri Apr 26 14:04: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 3A15521F98B0; Fri, 26 Apr 2013 14:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rdtq+2PaGcC9; Fri, 26 Apr 2013 14:04:01 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7284421F9897; Fri, 26 Apr 2013 14:04:01 -0700 (PDT) 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 r3QL3vD3019796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 14:04:00 -0700 Message-ID: <517AEBB8.3090105@dcrocker.net> Date: Fri, 26 Apr 2013 14:03:52 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: David Conrad References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <517AE707.4000206@dcrocker.net> <43923FD8-D99E-4297-82CF-F5F5C9040C29@virtualized.org> In-Reply-To: <43923FD8-D99E-4297-82CF-F5F5C9040C29@virtualized.org> 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.66]); Fri, 26 Apr 2013 14:04:00 -0700 (PDT) X-Mailman-Approved-At: Fri, 26 Apr 2013 14:17:53 -0700 Cc: spfbis@ietf.org, Dave Crocker , dnsext@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 21:04:02 -0000 On 4/26/2013 1:55 PM, David Conrad wrote: > Dave, > > As I pointed out to Paul Hoffman, the message I sent that I believe > started this thread said: > > "It is in keeping with past practice, e.g., see the notations for MD, ahh. right. thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Fri Apr 26 14:46: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 658C721F99E5 for ; Fri, 26 Apr 2013 14:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8BFGjFQjOvm for ; Fri, 26 Apr 2013 14:46:20 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 467C321F99E4 for ; Fri, 26 Apr 2013 14:46:20 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id m1so3936070wea.40 for ; Fri, 26 Apr 2013 14:46:04 -0700 (PDT) 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=Hm7G4xm2sps3rf6r2taSYMj3spyj43DJ20tydKj+sdI=; b=DA5xh/JZ33NxlhXnd9qEVElFocFuFpVOO97GROMU4gffR5ES1ttzmCi97ovjwIB69F NUaoDnOPfnfTPG/pCiB0fkYZXzpQXw4lyZdpvzBk4iOKigrdEFtWF4PxEYRdmUIfmvZe BBiMbDpgsp3Zkq0c2OduhvVvV4KYoR1IpJGraso88dq+AcgSVrVPgBI5mDP9XRQgCKqC g1SbLZ4mU7ivhEvida/AodwvwMFH6++k0LnQ/G2AU1HnCcZXcsr+6Wzbl7qo+STMpVPl 2nWKUuKZN76bJrsUrRRGEDo6c/ftpK3Y4pGDDSqJA5K+tjT+R8CgLSSjAGsfi2uEvY7o BCYg== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr37635438wjb.17.1367012764117; Fri, 26 Apr 2013 14:46:04 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Fri, 26 Apr 2013 14:46:03 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160DC3@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <1453053.12BnJ8GF9f@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> <1538026.HyQorgixtm@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775160DC3@mbx-01.win.nominum.com> Date: Fri, 26 Apr 2013 14:46:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b5d8cff35736404db4a76d4 Cc: "" , Dotzero , Scott Kitterman Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 21:46:22 -0000 --047d7b5d8cff35736404db4a76d4 Content-Type: text/plain; charset=ISO-8859-1 At the time the RFC6686 surveys were done there were several domains larger than this one (in terms of the number of RRs returned), but asking for TXT from "ut.edu" right now will give you 18 replies. The rest seem to have cleaned up their respective acts. I still have the original data seen during the surveys but this shows a live example. -MSK On Fri, Apr 26, 2013 at 1:25 PM, Ted Lemon wrote: > On Apr 26, 2013, at 4:19 PM, Dotzero wrote: > > If you have 37 text records for a single name space you have a very > > interesting record. Could you provide some legitimate examples of this > > in the wild that the WG could consider? > > It was given as an example earlier; you'd have to ask the person who cited > it. > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --047d7b5d8cff35736404db4a76d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I still have the original data seen during the surveys but t= his shows a live example.

-MSK


On Fri, Apr 26, 2013 at= 1:25 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
On Apr 26, 2013, at 4:19 P= M, Dotzero <dotzero@gmail.com&g= t; wrote:
> If you have 37 text records for a single name space you have a very > interesting record. Could you provide some legitimate examples of this=
> in the wild that the WG could consider?

It was given as an example earlier; you'd have to ask the person = who cited it.

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

--047d7b5d8cff35736404db4a76d4-- From Ted.Lemon@nominum.com Fri Apr 26 14:49: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 4A4DF21F9CEC for ; Fri, 26 Apr 2013 14:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx3djqQ5aIhu for ; Fri, 26 Apr 2013 14:49:53 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id C0D9921F9CEB for ; Fri, 26 Apr 2013 14:49:52 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUXr2dpa7bl/kmmD+poU2Jpr9p0hwZsD+@postini.com; Fri, 26 Apr 2013 14:49:52 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6F1BA1B80D6 for ; Fri, 26 Apr 2013 14:49:42 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 66C83190061; Fri, 26 Apr 2013 14:49:42 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 14:49:42 -0700 From: Ted Lemon To: John Levine Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQo2uaOnySfcNYkaWBgVmragk3ZjpEWOAgABkqICAAAoaAA== Date: Fri, 26 Apr 2013 21:49:41 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775160FC7@mbx-01.win.nominum.com> References: <20130426211331.74958.qmail@joyce.lan> In-Reply-To: <20130426211331.74958.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="utf-8" Content-ID: <8C6C42F6E4F003438D08CCE564CC4A78@nominum.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 21:49:54 -0000 T24gQXByIDI2LCAyMDEzLCBhdCA1OjEzIFBNLCBKb2huIExldmluZSA8am9obmxAdGF1Z2guY29t PiB3cm90ZToNCj4+IE9rYXksIGZhaXIgZW5vdWdoLiAgIFBsZWFzZSBkbyBub3RlIHRoYXQgSSBk aWRuJ3Qgc2F5IHRoYXQgdGhlcmUgd2FzIHByb2Nlc3MgYnJlYWthZ2Xvv71JIHNhaWQgdGhlIHBy b2Nlc3MNCj4+IHNlZW1lZCB0byBoYXZlIGJlZW4gZm9sbG93ZWQgY29ycmVjdGx5LCBidXQgcHJv ZHVjZWQgYSBsZXNzIHRoYW4gcGVyZmVjdCBvdXRjb21lLg0KPiANCj4gV2UgdW5kZXJzdGFuZCB0 aGF0IGl0J3Mgbm90IHRoZSBvdXRjb21lIHRoYXQgeW91J2QgbGlrZSwgYnV0IGl0J3MNCj4gYWJz b2x1dGVseSB0aGUgb3V0Y29tZSB0aGF0IHRoZSBkYXRhIHN1cHBvcnRzLg0KDQpZb3UgbWlzdW5k ZXJzdGFuZCBteSBwb2ludCBoZXJlLiAgIFdoYXQgSSBtZWFuIGlzIHRoYXQgaWYgdGhpcyBoYXMg YmVlbiByYWlzZWQgaW4gYSB3YXkgdGhhdCBhdHRyYWN0ZWQgYXR0ZW50aW9uIG9uIEROU0VYVCBp biBGZWJydWFyeSBvZiAyMDAyLCBvciB3aGVuZXZlciBpdCBiZWNhbWUgY2xlYXIgdGhhdCB0aGUg c3BmYmlzIHdhcyBnb2luZyB0byBkZXByZWNhdGUgU1BGIGluIGZhdm9yIG9mIFRYVCwgd2UgY291 bGQgaGF2ZSBhdm9pZGVkIHRoaXMgY29udmVyc2F0aW9uIG5vdy4gICBJIGRvbid0IG1lYW4gdGhh dCB0aGUgb3V0Y29tZSBvZiB0aGUgY29udmVyc2F0aW9uIHdvdWxkIGhhdmUgYmVlbiBhbnkgZGlm ZmVyZW50Lg0KDQo+ICBJIGhhdmUgdG8gYXNrLCBpcw0KPiB0aGVyZSBhbnkgYW1vdW50IG9mIGRh dGEgdGhhdCB3b3VsZCBjaGFuZ2UgeW91ciBvcGluaW9uIGhlcmU/ICBJZiBub3QsDQo+IHdlJ3Jl IGhhdmluZyBhIHJlbGlnaW91cyBhcmd1bWVudCwgbm90IGFuIGVuZ2luZWVyaW5nIG9uZSwgYW5k IHRoZXJlJ3MNCj4gbm8gcG9pbnQgdG8gY29udGludWluZy4NCg0KSSBkb24ndCB0aGluayBkYXRh IGFib3V0IHdoYXQgaXMgZGVwbG95ZWQgaW4gdGhlIGZpZWxkIHNob3VsZCBiZSB0aGUgcHJpbWFy eSBtb3RpdmF0aW5nIGZhY3RvciBmb3Igd3JpdGluZyBzdGFuZGFyZHMuICAgSXQncyBpbXBvcnRh bnQsIGJ1dCBpdCdzIG5vdCB0aGUgb25seSBmYWN0b3IuICAgQ2FsbGluZyBteSBvcGluaW9uIHJl bGlnaW91cywgYW5kIHlvdXJzIGVuZ2luZWVyaW5nLCBzZWVtcyBhIGJpdCBhcnJvZ2FudC4NCg0K PiBJcyBpdCByZWFsbHkgYXBwcm9wcmlhdGUgZm9yIHNvbWVvbmUgd2hvIGlzIHRoaXMgdW5mYW1p bGlhciB3aXRoIGENCj4gcHJvdG9jb2wgYXMgd2lkZWx5IGRlcGxveWVkIGFzIFNQRiAodml6LiB0 aGUgfjQwMCwwMDAgZG9tYWlucyBmb3VuZCBpbg0KPiB0aGUgUkZDIDY2ODYgc3VydmV5cywgYW5k IHRoZSBtYW55IHllYXJzIG9mIGV4cGVyaWVuY2UgYnkgV0cgbWVtYmVycywNCj4gc29tZSBhdCB2 ZXJ5IGxhcmdlIG1haWwgc3lzdGVtcykgdG8gYmUgZGVtYW5kaW5nIGxhc3QgbWludXRlDQo+IHJl ZGVzaWducz8NCg0KSSdtIG5vdCBkZW1hbmRpbmcgYSBsYXN0LW1pbnV0ZSByZWRlc2lnbi4gICBJ IHNhaWQgSSB3YXNuJ3QgZGVtYW5kaW5nIGEgbGFzdC1taW51dGUgcmVkZXNpZ24uICAgUmlnaHQg YXQgdGhlIHRvcCBvZiB0aGUgbWVzc2FnZSwgdHdvIGV4Y2hhbmdlcyBiYWNrLiAgIFRoZSByZWFz b24gSSdtIG5vdCBkZW1hbmRpbmcgYSBsYXN0LW1pbnV0ZSByZWRlc2lnbiBpcyB0aGF0IHdoaWxl IEkgZG8gZmVlbCBJJ20gcXVhbGlmaWVkIHRvIHBhcnRpY2lwYXRlIGluIHRoaXMgZGlzY3Vzc2lv biwgSSBkb24ndCBmZWVsIHRoYXQgbXkgb3BpbmlvbiBzaG91bGQgd2luLCBqdXN0IGJlY2F1c2Ug aXQncyBteSBvcGluaW9uLg0KDQo= From spf2@kitterman.com Fri Apr 26 14:58: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 6CD4C21F99EC; Fri, 26 Apr 2013 14:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wViT2BaFemHf; Fri, 26 Apr 2013 14:58:08 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C3ACB21F998B; Fri, 26 Apr 2013 14:58:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1EE7020E40D5; Fri, 26 Apr 2013 17:58:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367013483; bh=m4YeNCTTcSVPJvj6xkSF4d6s8k9p3hL41j4DrhCte1Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z7ssnVkGjOwdBgIj/ceT2PVp2wGtjO6fatn74r6eS7DWizBJUs0eSfykZT/S1N62t L3xLkXnc2uePBXj4c63Wk4B4sQ4tM/62pTdx/yzDWoPjB89K7KUvfmfiJTzTonkWLK WrPpls+TOajFTF56mkgXwIjdRiad6LyzJ3HWCsLU= 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 03A0220E40CF; Fri, 26 Apr 2013 17:58:02 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org, dnsext@ietf.org Date: Fri, 26 Apr 2013 17:58:02 -0400 Message-ID: <11684211.aVagNjs4Ck@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <43923FD8-D99E-4297-82CF-F5F5C9040C29@virtualized.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <517AE707.4000206@dcrocker.net> <43923FD8-D99E-4297-82CF-F5F5C9040C29@virtualized.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: David Conrad Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 21:58:10 -0000 Thanks. Having looked at that, I think that the text in the original question from sm is OK (modulo we don't redesign things - please keep that in a different subthread). Scott K On Friday, April 26, 2013 03:55:01 PM David Conrad wrote: > Dave, > > As I pointed out to Paul Hoffman, the message I sent that I believe started > this thread said: > > "It is in keeping with past practice, e.g., see the notations for MD, MF, > A6, and the MAILA RRtypes at > http://www.iana.org/assignments/dns-parameters/dns-parameters.xml." > > Regards, > -drc > > On Apr 26, 2013, at 3:43 PM, Dave Crocker wrote: > > On 4/23/2013 3:03 PM, S Moonesamy wrote: > >> Hello, > >> > >> Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE: > >> 'IANA is requested to add an annotation to the SPF RRTYPE saying > >> > >> "(OBSOLETE - use TXT)" in the DNS Parameters registry.' > >> > >> Is the annotation in the DNS Parameters registry correct? > > > > Dear DNSEXT, > > > > For all of the really interesting side discussions that have developed > > since SM sent this initial query, I believe there have not been any > > responses that answered the question that was asked. > > > > DNSEXT was asked to provide expert review of this specific bit of text. > > The text is intended to be comparable to the way that some other, similar > > situations have already been handled. > > > > d/ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From superuser@gmail.com Fri Apr 26 14:59: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 9C12721F99AA; Fri, 26 Apr 2013 14:59:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba6-vJgK4T+6; Fri, 26 Apr 2013 14:59:00 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA1421F998B; Fri, 26 Apr 2013 14:58:59 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hm14so1093248wib.17 for ; Fri, 26 Apr 2013 14:58:59 -0700 (PDT) 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=jmOwnbaZpz0gnH1v55Y3Il2SO0jBL6sigCSh7DV/Pes=; b=VxpEIM0iyp9t2IK8cgcjMQ2G0oEJ3cVnR9YmuQZxawjS2tPNgQpzRycmpl5x2BYY1V ku3VacT3hslhhqn7xbdTHfMchS885dRB5gy9VNIKyLf9pVGg/lfy9o+VNyv8Z5kO9RDZ bLNaydTQfxDkPpjKb4IogY7BD+0dAm/GNsQkZ4oA0itzGiqmeBFOzl7Uz1Rnjl+iSyOy PYGaIszmsr7/EBWEU001QAvxQrpmItaE/9URa4wwD/0NRtn92ekYQpb2fqZNUm3xijZy Dw+5QWE3AZJj2Rzr0717zP8JwzoOytR6JcNYqdp1GjmzWxgkuMYjzNtAU9WaaQc9+26h LQWg== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr6414418wic.32.1367013539292; Fri, 26 Apr 2013 14:58:59 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Fri, 26 Apr 2013 14:58:59 -0700 (PDT) In-Reply-To: <517AD619.3000406@dougbarton.us> References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179BC32.8050205@dougbarton.us> <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> <517AD619.3000406@dougbarton.us> Date: Fri, 26 Apr 2013 14:58:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Doug Barton Content-Type: multipart/alternative; boundary=001a11c3483069abe404db4aa437 Cc: "spfbis@ietf.org" , David Conrad , "dnsext@ietf.org Group" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 21:59:02 -0000 --001a11c3483069abe404db4aa437 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 26, 2013 at 12:31 PM, Doug Barton wrote: > > No, what I'm saying is that the way things were ten years ago >> > > As I (and others) have said many times, things were rough at the time SPF > came to bloom. However, and this is really important to understand, it's > not 10 years ago anymore. > I am keenly aware of the date. What I am also keenly aware of, as I (and others) have said many times, is that SPF set off in a specific direction based on the situation ten years ago and has continued in that direction all this time. Now, with the situation "at home" largely-but-not-completely improved, there are a few people now exclaiming that it went in the wrong direction, and that needs to be fixed. It's very easy to make that assertion when one ignores questions of momentum and inertia. I'm not being petty when I say that. It really is important to understand, > the time is going to pass anyway. In the time period between then and now a > LOT of things have happened in the DNS world, and the situation is > dramatically different now than it was. > Nobody's arguing that point. > > What is even more important to understand is that 10 years from now 10 > more years will have passed. We have a chance now to set in motion events > that will continue to improve the situation, so that 10 years from now we > can look back and laugh at the SPF TXT record, and have joy that things are > so much better. Or, we can spend 10 more years with the same silly kludge, > and not have made any progress at all. Either way, the next 10 years are > going to pass. Sure. Is that a good use of engineering resources? This is where we appear to differ. I claim, given current data, that it is not. > > And some of the software that handles SPF has already switched to querying > SPF/99 first. There is no reason that the rest could not do that as well. I agree with the first sentence, but not the second. > As I have mentioned previously, in the DNS world we have a LOT of > experience dealing with issues EXACTLY like this. We know how it works, we > know what long tails look like, and we know that as problems go it's a > pretty easy problem to deal with. > This situation touches more than just DNS code. You appear to be convinced that the path to overcoming inertia in the DNS world is the same, or maybe even harder, than it is in other environments like email. I am not a believer. > > Um, it's not "suddenly." The advice to do it right in the first place has > been offered repeatedly, since the very beginning. That's why the code > point was assigned in the first place. > Um, it is "suddenly", or have you a copy of the spfbis archive that's different from the one I have? > > There is no doubt that in the early days, prior to the widespread > deployment of 3597, querying for SPF/99 could cause problems. But we're not > in that world anymore. Thank DNSSEC and IPv6 for shaking things loose. > There is currently no TECHNICAL reason that the change cannot be made NOW > to query SPF/99 first. The only argument you (and others) have put forward > so far is, "We have been using TXT, it works, so we want to keep using it." > I understand why that course of action is attractive, but it's bad. And the > right thing isn't hard to do. > I'm sorry, but that is not the only argument I (and others) have put forward so far. If this conversation is going to be selective in that manner, then I think I'm done here. -MSK --001a11c3483069abe404db4aa437 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 26, 2013 at 12:31 PM, Doug Barton <dougb@do= ugbarton.us> wrote:

No, what I'm saying is that the way things were ten years ago

As I (and others) have said many times, things were rough at the time SPF c= ame to bloom. However, and this is really important to understand, it's= not 10 years ago anymore.

I am keenly = aware of the date.=A0 What I am also keenly aware of, as I (and others) hav= e said many times, is that SPF set off in a specific direction based on the= situation ten years ago and has continued in that direction all this time.= =A0 Now, with the situation "at home" largely-but-not-completely = improved, there are a few people now exclaiming that it went in the wrong d= irection, and that needs to be fixed.

It's very easy to make that assertion when one ignores questions of= momentum and inertia.


I'm not being petty when I say that. It really is important to understa= nd, the time is going to pass anyway. In the time period between then and n= ow a LOT of things have happened in the DNS world, and the situation is dra= matically different now than it was.

Nobody's arguing that point.
=A0

What is even more important to understand is that 10 years from now 10 more= years will have passed. We have a chance now to set in motion events that = will continue to improve the situation, so that 10 years from now we can lo= ok back and laugh at the SPF TXT record, and have joy that things are so mu= ch better. Or, we can spend 10 more years with the same silly kludge, and n= ot have made any progress at all. Either way, the next 10 years are going t= o pass.

Sure.=A0 Is that a good use of engineering resources?= =A0 This is where we appear to differ.=A0 I claim, given current data, that= it is not.
=A0

And some of the software that handles SPF has already switched to querying = SPF/99 first. There is no reason that the rest could not do that as well. <= /blockquote>

I agree with the first sentence, but not th= e second.
=A0
As I have mentioned previously,= in the DNS world we have a LOT of experience dealing with issues EXACTLY l= ike this. We know how it works, we know what long tails look like, and we k= now that as problems go it's a pretty easy problem to deal with.

This situation touches more than just DNS = code.=A0 You appear to be convinced that the path to overcoming inertia in = the DNS world is the same, or maybe even harder, than it is in other enviro= nments like email.=A0 I am not a believer.
=A0

Um, it's not "suddenly." The advice to do it right in the fir= st place has been offered repeatedly, since the very beginning. That's = why the code point was assigned in the first place.

Um, it is "suddenly", or have you a copy of the sp= fbis archive that's different from the one I have?
=A0

There is no doubt that in the early days, prior to the widespread deploymen= t of 3597, querying for SPF/99 could cause problems. But we're not in t= hat world anymore. Thank DNSSEC and IPv6 for shaking things loose. There is= currently no TECHNICAL reason that the change cannot be made NOW to query = SPF/99 first. The only argument you (and others) have put forward so far is= , "We have been using TXT, it works, so we want to keep using it."= ; I understand why that course of action is attractive, but it's bad. A= nd the right thing isn't hard to do.

I'm sorry, but that is not the only ar= gument I (and others) have put forward so far.=A0 If this conversation is g= oing to be selective in that manner, then I think I'm done here.
-MSK
--001a11c3483069abe404db4aa437-- From dhc@dcrocker.net Fri Apr 26 15:02: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 8360421F9A14 for ; Fri, 26 Apr 2013 15:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezjfyDswEEs4 for ; Fri, 26 Apr 2013 15:02:12 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA5421F993C for ; Fri, 26 Apr 2013 15:02:12 -0700 (PDT) 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 r3QM29LX020872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 15:02:12 -0700 Message-ID: <517AF95C.6050005@dcrocker.net> Date: Fri, 26 Apr 2013 15:02:04 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Lemon References: <20130426211331.74958.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775160FC7@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775160FC7@mbx-01.win.nominum.com> Content-Type: text/plain; charset=UTF-8; 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.66]); Fri, 26 Apr 2013 15:02:12 -0700 (PDT) Cc: "" , John Levine Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 22:02:13 -0000 Ted, et al, On 4/26/2013 2:49 PM, Ted Lemon wrote: > You misunderstand my point here. What I mean is that if this has > been raised in a way that attracted attention on DNSEXT in February > of 2002, or whenever it became clear that the spfbis was going to > deprecate SPF in favor of TXT, we could have avoided this > conversation now. Such an optimist, given the tenacity of those insisting on relying on new RRs. >> I have to ask, is there any amount of data that would change your >> opinion here? If not, we're having a religious argument, not an >> engineering one, and there's no point to continuing. > > I don't think data about what is deployed in the field should be the > primary motivating factor for writing standards. Right. Running code and operational practice really aren't all that important, when compared against architectural ideals. As in, wow... The current situation is pretty simple: 1. The SPF RR was defined but failed to gain traction. The market has overwhelmingly rejected it. 2. There is no objective basis for believing that will change. 3. Retention of unused features makes a specification more complex and invites implementation and operations problems. 4. Specification revision efforts typically drop unused features. Added to this is the problem of claiming that it's now reasonable to deploy new RRs. This line of claim carefully focuses on only a subset of the overall adoption and deployment task and cavalierly dismisses the rest. While portions of the task have indeed improved over the last 10 years, there are still show-stopping barriers to adoption. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ajs@anvilwalrusden.com Fri Apr 26 15:07: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 3846A21F9CF2 for ; Fri, 26 Apr 2013 15:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZPaO6ECwkTO for ; Fri, 26 Apr 2013 15:07:20 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED8A21F9CF1 for ; Fri, 26 Apr 2013 15:07:20 -0700 (PDT) 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 09D218A031 for ; Fri, 26 Apr 2013 22:07:19 +0000 (UTC) Date: Fri, 26 Apr 2013 18:07:18 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130426220717.GI809@mx1.yitter.info> References: <20130425013317.36729.qmail@joyce.lan> <1453053.12BnJ8GF9f@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> <1538026.HyQorgixtm@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775160DC3@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 22:07:21 -0000 No hat On Fri, Apr 26, 2013 at 02:46:03PM -0700, Murray S. Kucherawy wrote: > than this one (in terms of the number of RRs returned), but asking for TXT > from "ut.edu" right now will give you 18 replies. The rest seem to have > cleaned up their respective acts. What do you mean, "cleaned up"? Several of the TXT records at ut.edu are _what TXT was for_, which is "text" (although I think they may be confused about how DNS works, since they have text that says "in the following record", which is pretty amusing). Text is, you know, stuff for humans to read. Indeed, the ut.edu example is an excellent one of why polluting TXT with data that is somehow supposed to be used programmatically is a bad idea. I also observe that SPF is plainly not the only protocol doing this. There's some apparent random cryptographic blob there, too, and one of those MS= things. (This makes me want to request an RRTYPE code assignment for the VOMIT RRTYPE, but I know nobody would use it, or at least not the people it was aimed at. Very Offensive Mangled Interchange Type in case anyone was wondering, though I could maybe do better with a little more thought.) The argument that SPF, by using the TXT type, is tromping all over an otherwise useful type and making that other type harder to use is a perfectly good one. The _only_ reason to accept the deprecation of TYPE 99 is the twin issue that TXT-mostly is a fact of life on the Internet _and_ we have an interoperability problem in the existing specification. That's why I think the hand-wringing about "precedent" is foolish: there is no precedent here, because of the history of SPF. What we have to ensure is that a Charlie Foxtrot of the same proportions doesn't happen again. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc@dcrocker.net Fri Apr 26 15:12: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 E0A2821F9CF8 for ; Fri, 26 Apr 2013 15:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONr+QhAnzAdl for ; Fri, 26 Apr 2013 15:12:38 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9C621F9CF7 for ; Fri, 26 Apr 2013 15:12:38 -0700 (PDT) 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 r3QMC32W021033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 15:12:06 -0700 Message-ID: <517AFBAF.6000608@dcrocker.net> Date: Fri, 26 Apr 2013 15:11:59 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andrew Sullivan References: <20130425013317.36729.qmail@joyce.lan> <1453053.12BnJ8GF9f@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> <1538026.HyQorgixtm@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775160DC3@mbx-01.win.nominum.com> <20130426220717.GI809@mx1.yitter.info> In-Reply-To: <20130426220717.GI809@mx1.yitter.info> 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.66]); Fri, 26 Apr 2013 15:12:06 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 22:12:39 -0000 On 4/26/2013 3:07 PM, Andrew Sullivan wrote: > What we have to ensure is that a Charlie Foxtrot of the same > proportions doesn't happen again. Yup. And whether it entails using a new RR or an underscore prefix (to define a scoped TXT usage) that's a solved concern. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Ted.Lemon@nominum.com Fri Apr 26 15:13: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 3A91B21F9731 for ; Fri, 26 Apr 2013 15:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.409 X-Spam-Level: X-Spam-Status: No, score=-106.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2Tw6ggg985Y for ; Fri, 26 Apr 2013 15:13:27 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9C90F21F9727 for ; Fri, 26 Apr 2013 15:13:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUXr8Bxlcyn9Nf2AlynCgRCwQr8bn52Vk@postini.com; Fri, 26 Apr 2013 15:13:27 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1D9EF1B80D6 for ; Fri, 26 Apr 2013 15:13:27 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 15578190061; Fri, 26 Apr 2013 15:13:27 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 15:13:27 -0700 From: Ted Lemon To: Dave Crocker Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQo2uaOnySfcNYkaWBgVmragk3ZjpEWOAgABkqICAAAoaAIAAA3cAgAADKgA= Date: Fri, 26 Apr 2013 22:13:26 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751610E8@mbx-01.win.nominum.com> References: <20130426211331.74958.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775160FC7@mbx-01.win.nominum.com> <517AF95C.6050005@dcrocker.net> In-Reply-To: <517AF95C.6050005@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <929CEB75EEF04D4784644DABA4C43C79@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , John Levine Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 22:13:28 -0000 On Apr 26, 2013, at 6:02 PM, Dave Crocker wrote: > On 4/26/2013 2:49 PM, Ted Lemon wrote: >> You misunderstand my point here. What I mean is that if this has >> been raised in a way that attracted attention on DNSEXT in February >> of 2002, or whenever it became clear that the spfbis was going to >> deprecate SPF in favor of TXT, we could have avoided this >> conversation now. >=20 > Such an optimist, given the tenacity of those insisting on relying on new= RRs. Again, you misunderstand my point. Yes, probably someone would bring this= up every six months. But it would have been settled, so it wouldn't matt= er that they brought it up again, although I suppose the proponents of the = view that prevailed would still feel obligated to beat them up again. >> I don't think data about what is deployed in the field should be the >> primary motivating factor for writing standards. >=20 > Right. Running code and operational practice really aren't all that impo= rtant, when compared against architectural ideals. Thanks, Dave. "Not the primary motivating factor" !=3D "not all that impo= rtant." You write a protocol spec because you mean to solve a problem, no= t because the problem has already been solved. It's certainly true that r= unning code is important, but so is rough consensus. And when people clai= m that running code trumps rough consensus, in the sense that the IETF is o= nly allowed to document precisely what's already been implemented, it's oft= en taken very poorly. I will refrain from responding to the rest of what you said, because I alre= ady said that while I am not happy with the spfbis consensus, I do not disp= ute it. From superuser@gmail.com Fri Apr 26 15:16: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 BEA9A21F9A26 for ; Fri, 26 Apr 2013 15:16:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrKjOFU+kCc8 for ; Fri, 26 Apr 2013 15:16:18 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9431321F9629 for ; Fri, 26 Apr 2013 15:16:17 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id l13so1103565wie.16 for ; Fri, 26 Apr 2013 15:16:16 -0700 (PDT) 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=Q4ho0S218JPK7eXXwYApJD4GsI0by7vQGn4sNZOTW20=; b=EwJaI0Cp10WCGoP0LDjOEzDva15ADVpJlQoKEFo35e3wdnf6diDMmz17ODxmX98c9T e4ZT373fWN+6E9KeBJGcGNEEAS3CH1U+YpHDWD4m705T8xB+Or7xjKlpbDail/VDen5X DEJT2+ZLC6lqYn+TD5t2GrsliIadA87U0DZM19r3Bld8b7U/FHLhdzzuYZ60FoHH8f0k CLV/19Z0gXDqeFr9cqK/W0sgInip+9ws1/D0lOuBb4CC9TTR2eXXGc7Ik4UVdWNlmsGD ZHajpFb/rlxY+XZXEllRO14uIVuopVK1T46KUjlYUxVEg2ID1W7ewSOguzzTcxynH246 /RQw== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr6460642wic.32.1367014576622; Fri, 26 Apr 2013 15:16:16 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Fri, 26 Apr 2013 15:16:16 -0700 (PDT) In-Reply-To: <20130426220717.GI809@mx1.yitter.info> References: <20130425013317.36729.qmail@joyce.lan> <1453053.12BnJ8GF9f@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> <1538026.HyQorgixtm@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775160DC3@mbx-01.win.nominum.com> <20130426220717.GI809@mx1.yitter.info> Date: Fri, 26 Apr 2013 15:16:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c348303e108c04db4ae21c Cc: "spfbis@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 22:16:18 -0000 --001a11c348303e108c04db4ae21c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 26, 2013 at 3:07 PM, Andrew Sullivan wrote: > What do you mean, "cleaned up"? Several of the TXT records at ut.edu > are _what TXT was for_, which is "text" (although I think they may be > confused about how DNS works, since they have text that says "in the > following record", which is pretty amusing). Text is, you know, stuff > for humans to read. > It's a hodgepodge of data, given that the TXT RRs could be returned in any order. The largest recorded example in the RFC6686 surveys included a reply comprising 43 records, nearly all of which were random strings Google asked them to add to prove they owned the domain when setting up Google Apps or something similar. Those aren't meant for use by humans. They're are all gone now, which is what I meant by "cleaned up". The argument that SPF, by using the TXT type, is tromping all over an > otherwise useful type and making that other type harder to use is a > perfectly good one. The _only_ reason to accept the deprecation of > TYPE 99 is the twin issue that TXT-mostly is a fact of life on the > Internet _and_ we have an interoperability problem in the existing > specification. That's why I think the hand-wringing about "precedent" > is foolish: there is no precedent here, because of the history of SPF. > What we have to ensure is that a Charlie Foxtrot of the same > proportions doesn't happen again. > +1, given that this is a restatement of what I said earlier. Maybe you have more credibility than I do. :-) -MSK --001a11c348303e108c04db4ae21c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 26, 2013 at 3:07 PM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
What do you mean, "cleaned up"? = =A0Several of the TXT records at ut.edu
are _what TXT was for_, which is "text" (although I think they ma= y be
confused about how DNS works, since they have text that says "in the following record", which is pretty amusing). =A0Text is, you know, stu= ff
for humans to read.

It's a hodgepod= ge of data, given that the TXT RRs could be returned in any order.=A0 The l= argest recorded example in the RFC6686 surveys included a reply comprising = 43 records, nearly all of which were random strings Google asked them to ad= d to prove they owned the domain when setting up Google Apps or something s= imilar.=A0 Those aren't meant for use by humans.=A0 They're are all= gone now, which is what I meant by "cleaned up".

The argument that SPF, by using the TXT type, is tromping all over an
otherwise useful type and making that other type harder to use is a
perfectly good one. =A0The _only_ reason to accept the deprecation of
TYPE 99 is the twin issue that TXT-mostly is a fact of life on the
Internet _and_ we have an interoperability problem in the existing
specification. =A0That's why I think the hand-wringing about "prec= edent"
is foolish: there is no precedent here, because of the history of SPF.
What we have to ensure is that a Charlie Foxtrot of the same
proportions doesn't happen again.

+= 1, given that this is a restatement of what I said earlier.=A0 Maybe you ha= ve more credibility than I do.=A0=A0 :-)

-MSK =

--001a11c348303e108c04db4ae21c-- From spf2@kitterman.com Fri Apr 26 15:20: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 3C5E221F9CEA for ; Fri, 26 Apr 2013 15:20:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpRkUiK7Uavq for ; Fri, 26 Apr 2013 15:20:53 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9127E21F9A2D for ; Fri, 26 Apr 2013 15:20:53 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1AFE320E40D5; Fri, 26 Apr 2013 18:20:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367014853; bh=enEPkvxqPHltNvbR7f6o+q1vZvEk9FEFoCx5+xj4cJc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nvkkZxkllHT7LOvbr0TVwRXpUM8p+qi+kSW8iZhBlAuOh50VmXlHuYDayqPqHTzux mF09yVRVoQHR4Dq34xB8o7Z7zc644BE1DlA8adhm4pd+Im99tjiEWMO9TqWhQPf6Xj w3uYoMwCa7NwJ0OQgb0FHl+StMSpqkN4L2/wk4iA= 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 F2AA420E40CF; Fri, 26 Apr 2013 18:20:52 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 18:20:52 -0400 Message-ID: <3645708.9gL8lVvrKx@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <1947641.qMtMBB5hPF@scott-latitude-e6320> References: <20130425013317.36729.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775160DFF@mbx-01.win.nominum.com> <1947641.qMtMBB5hPF@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] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 22:20:54 -0000 On Friday, April 26, 2013 04:34:05 PM Scott Kitterman wrote: ... > I don't know how to be clearer, so I'll just stop ... It was pointed out to me offlist that this came across as a cheap shot. It wasn't meant that way, so I withdraw it. I was attempting to describe a communication failure (with no blame attaching to either party, just a failure) that I couldn't see how to rectify. Scott K From dhc@dcrocker.net Fri Apr 26 15:36:42 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 7D65621F9CF0 for ; Fri, 26 Apr 2013 15:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VORtXJsi1Ki4 for ; Fri, 26 Apr 2013 15:36:41 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BBC7921F9A27 for ; Fri, 26 Apr 2013 15:36:41 -0700 (PDT) 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 r3QMaccI021390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 15:36:41 -0700 Message-ID: <517B0171.6020501@dcrocker.net> Date: Fri, 26 Apr 2013 15:36:33 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Lemon References: <20130426211331.74958.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775160FC7@mbx-01.win.nominum.com> <517AF95C.6050005@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307751610E8@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751610E8@mbx-01.win.nominum.com> 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.66]); Fri, 26 Apr 2013 15:36:41 -0700 (PDT) Cc: "" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 22:36:42 -0000 On 4/26/2013 3:13 PM, Ted Lemon wrote: > Again, you misunderstand my point. Yes, probably someone would > bring this up every six months. But it would have been settled, so > it wouldn't matter that they brought it up again, although I suppose Well, I'll claim that the question of TXT vs. RR was thoroughly discussed at the time, with plenty of DNS expertise present. In fact, including the SPF RR in the spec, then, was the compromise outcome, as a concession to RR devotees. In other words, it /was/ settled a long time ago. But that hasn't stopped any number of folk from claiming it wasn't. (By way of contrast, and FWIW, I happen to dislike SPF in its entirety, from its being path-based to its excessive complexity. But none of that has been worth discussing during spfbis and I haven't raised it. SPF is highly integrated into the global email infrastructure. So the only issues now should be small technical tweaks and documentation refinement. And that's what the wg has done, modulo some, ummmm... synchronization challenges in getting consensus on what tweaking has been needed.) >>> I don't think data about what is deployed in the field should be >>> the primary motivating factor for writing standards. >> >> Right. Running code and operational practice really aren't all >> that important, when compared against architectural ideals. > > Thanks, Dave. "Not the primary motivating factor" != "not all that > important." I acknowledge the semantic distinction. But a) the IETF historically has held very high the goal of documenting existing practice, and b) this is a -bis effort, where existing practice really /is/ primary. > You write a protocol spec because you mean to solve a > problem, not because the problem has already been solved. Oh. You've missed the role of documenting existing practice that I thought was held as an IETF ideal and that has been common IETF practice??? > It's > certainly true that running code is important, but so is rough > consensus. Indeed, but rough consensus in the market trumps any amount of it within a tiny community of technology idealists, even if that community's name is "IETF". > And when people claim that running code trumps rough > consensus, in the sense that the IETF is only allowed to document > precisely what's already been implemented, it's often taken very > poorly. Turn that around. Rough consensus in a small group that has little risk, if an effort fails, should not be allowed to trump rough consensus among the larger community that relies on implementations interoperating. To the extent that an IETF failure to gain rough consensus causes an outcome that is contrary to marketplace needs (and rough consensus), it is the IETF that become irrelevant. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Fri Apr 26 15:38: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 2107021F9CF0 for ; Fri, 26 Apr 2013 15:38:09 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Da99UQBfgcV for ; Fri, 26 Apr 2013 15:38:08 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B438021F9A1B for ; Fri, 26 Apr 2013 15:38:08 -0700 (PDT) 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 r3QMc5Rd021425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 15:38:08 -0700 Message-ID: <517B01C8.2030805@dcrocker.net> Date: Fri, 26 Apr 2013 15:38:00 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman References: <20130425013317.36729.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775160DFF@mbx-01.win.nominum.com> <1947641.qMtMBB5hPF@scott-latitude-e6320> <3645708.9gL8lVvrKx@scott-latitude-e6320> In-Reply-To: <3645708.9gL8lVvrKx@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.66]); Fri, 26 Apr 2013 15:38:08 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 22:38:09 -0000 On 4/26/2013 3:20 PM, Scott Kitterman wrote: > On Friday, April 26, 2013 04:34:05 PM Scott Kitterman wrote: > ... >> I don't know how to be clearer, so I'll just stop > ... > > It was pointed out to me offlist that this came across as a cheap shot. For reference, I thought it was nicely neutral and professional. Seriously. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mansaxel@besserwisser.org Fri Apr 26 15:45: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 2722621F99B6 for ; Fri, 26 Apr 2013 15:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+SG6JSuhKFO for ; Fri, 26 Apr 2013 15:45:22 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id 5236221F97D9 for ; Fri, 26 Apr 2013 15:45:21 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 5ADAA9EF0; Sat, 27 Apr 2013 00:45:20 +0200 (CEST) Date: Sat, 27 Apr 2013 00:45:20 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Andrew Sullivan Message-ID: <20130426224519.GU23770@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <1453053.12BnJ8GF9f@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> <1538026.HyQorgixtm@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775160DC3@mbx-01.win.nominum.com> <20130426220717.GI809@mx1.yitter.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oGy11dVowAZA6eXT" Content-Disposition: inline In-Reply-To: <20130426220717.GI809@mx1.yitter.info> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 22:45:23 -0000 --oGy11dVowAZA6eXT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Fri, Apr 26, 201= 3 at 06:07:18PM -0400 Quoting Andrew Sullivan (ajs@anvilwalrusden.com): =20 > The argument that SPF, by using the TXT type, is tromping all over an > otherwise useful type and making that other type harder to use is a > perfectly good one. The _only_ reason to accept the deprecation of > TYPE 99 is the twin issue that TXT-mostly is a fact of life on the > Internet _and_ we have an interoperability problem in the existing > specification. That's why I think the hand-wringing about "precedent" > is foolish: there is no precedent here, because of the history of SPF. > What we have to ensure is that a Charlie Foxtrot of the same > proportions doesn't happen again. I'd suggest that the spfbis draft gets text along these lines:=20 SPF records MUST be published as a DNS SPF (type 99) Resource Record (RR) . The character content of the record is encoded as . Use of alternate DNS RR types was supported in SPF's experimental phase, but has been discontinued. The intermediate practice of publishing SPF data in TXT records MAY be retained along the required SPF RR for compatibility reasons, but MUST NOT be the sole publication. A SPF (type 99) record MUST be present. =2E.. In accordance with how the records are published (see above), a DNS query needs to be made for the <domain> name, querying for type SPF. If the reply is valid=20 but empty (RCODE NOERROR (0) and answer count =3D=3D 0), check_host()=20 MAY query for the same <domain> name, but substituting the=20 resource record type with TXT.=20 (XML diffs can be had by asking)=20 This way, both sides get what they want. People who wish to run old name server software can continue, provisioning systems may be subjected to bitrot, and the stuff that gets upgraded will do the right thing. ( The elephant in the room is Windows Server. When it allows injection of SPF RRen in its DNS server, we're good. For real.) --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I am deeply CONCERNED and I want something GOOD for BREAKFAST! --oGy11dVowAZA6eXT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF7A38ACgkQ02/pMZDM1cUl3gCfdRyB+uOsctzbY3YoqmfWnL8J c+oAniRo2RXcay7XC0wzyrgf4vMnbvfi =o971 -----END PGP SIGNATURE----- --oGy11dVowAZA6eXT-- From Ted.Lemon@nominum.com Fri Apr 26 15:46: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 BBE6021F9D00 for ; Fri, 26 Apr 2013 15:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.418 X-Spam-Level: X-Spam-Status: No, score=-106.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTi-M4M7H-wA for ; Fri, 26 Apr 2013 15:46:47 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 262FE21F9CFF for ; Fri, 26 Apr 2013 15:46:47 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUXsD1oDerBSryfI8NG8wGomAZTMFQsNf@postini.com; Fri, 26 Apr 2013 15:46:47 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B04921B8162 for ; Fri, 26 Apr 2013 15:46:46 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A6D79190061; Fri, 26 Apr 2013 15:46:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 15:46:46 -0700 From: Ted Lemon To: Dave Crocker Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQo2uaOnySfcNYkaWBgVmragk3ZjpEWOAgABkqICAAAoaAIAAA3cAgAADKgCAAAZ4gIAAAtkA Date: Fri, 26 Apr 2013 22:46:45 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751612D3@mbx-01.win.nominum.com> References: <20130426211331.74958.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775160FC7@mbx-01.win.nominum.com> <517AF95C.6050005@dcrocker.net> <8D23D4052ABE7A4490E77B1A012B6307751610E8@mbx-01.win.nominum.com> <517B0171.6020501@dcrocker.net> In-Reply-To: <517B0171.6020501@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 22:46:47 -0000 On Apr 26, 2013, at 6:36 PM, Dave Crocker wrote: > Turn that around. Rough consensus in a small group that has little risk,= if an effort fails, should not be allowed to trump rough consensus among t= he larger community that relies on implementations interoperating. And I am not arguing that it should, and I have said that repeatedly. Are= the beatings going to continue until morale improves, or can we please dro= p this useless discussion? From spf2@kitterman.com Fri Apr 26 15:52: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 4778821F9A21 for ; Fri, 26 Apr 2013 15:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGdQu+FVwMin for ; Fri, 26 Apr 2013 15:52:37 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D710721F9A05 for ; Fri, 26 Apr 2013 15:52:36 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5691C20E4167; Fri, 26 Apr 2013 18:52:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367016756; bh=lsrV96p6QYt5/XhUJ89LCW6NEYl0vaPfXmdR0RoAoMo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BvWNVXmxjgalEvmkTaUNbcwsx0p7yb8K0x2XsDkk44pRuD5x3YNYMzYgnqSIHT+D3 sht4a/LSoLY4+7HWXKyNJ3o4iNovNZTZIazoqXZ4ErNVFEbjt1tZ5OOBtpxkUsuIME 2zLQFMndkWWGbIpzBNTQ9NGipxe8Ph90E4hvjuFc= 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 365B020E40CF; Fri, 26 Apr 2013 18:52:35 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 18:52:35 -0400 Message-ID: <4272263.gKzvRQiTlr@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130426224519.GU23770@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 22:52:39 -0000 On Saturday, April 27, 2013 12:45:20 AM M=E5ns Nilsson wrote: > Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Fri, Apr 2= 6, 2013=20 at 06:07:18PM -0400 Quoting Andrew Sullivan (ajs@anvilwalrusden.com): > > The argument that SPF, by using the TXT type, is tromping all over = an > > otherwise useful type and making that other type harder to use is a= > > perfectly good one. The _only_ reason to accept the deprecation of= > > TYPE 99 is the twin issue that TXT-mostly is a fact of life on the > > Internet _and_ we have an interoperability problem in the existing > > specification. That's why I think the hand-wringing about "precede= nt" > > is foolish: there is no precedent here, because of the history of S= PF. > > What we have to ensure is that a Charlie Foxtrot of the same > > proportions doesn't happen again. >=20 > I'd suggest that the spfbis draft gets text along these lines: >=20 > SPF records MUST be published as a DNS SPF (type 99) > Resource Record (RR) . The > character content of the record is encoded as target=3D"US-ASCII"/>. Use of alternate DNS RR types was > supported in SPF's experimental phase, but has been > discontinued. The intermediate practice of publishing SPF > data in TXT records MAY be retained along the required SPF > RR for compatibility reasons, but MUST NOT be the sole > publication. A SPF (type 99) record MUST be present. >=20 > ... >=20 > In accordance with how the records are published (see target=3D"records"/> above), a DNS query needs to be made for the > <domain> name, querying for type SPF. If the reply is valid > but empty (RCODE NOERROR (0) and answer count =3D=3D 0), check_host= () > MAY query for the same <domain> name, but substituting the > resource record type with TXT. >=20 > =09(XML diffs can be had by asking) >=20 > This way, both sides get what they want. People who wish to run old n= ame > server software can continue, provisioning systems may be subjected t= o > bitrot, and the stuff that gets upgraded will do the right thing. >=20 > ( The elephant in the room is Windows Server. When it allows injectio= n of > SPF RRen in its DNS server, we're good. For real.) I don't think this is a good idea, but I'll ask a couple of questions a= nyway. What's the appropriate response for SERVFAIL or no response at all (tim= eout)=20 on the type SPF query? Do you think it is in the scope of the charter language to add a 2119 M= UST for=20 publishing type SPF when it's essentially unused? Scott K From marka@isc.org Fri Apr 26 16:08: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 E691A21F9933 for ; Fri, 26 Apr 2013 16:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzHLCQUSB49O for ; Fri, 26 Apr 2013 16:08:52 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5176321F992E for ; Fri, 26 Apr 2013 16:08:52 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 31ABEC9477; Fri, 26 Apr 2013 23:08:46 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367017732; bh=pWICe426NVTL54v3ul2NKTxZ53npHezQxS8hVlxYKs0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=esaLnEDnq7d6FHG0jpdeCcR2HvY+JVM8b3P+DNSyCaT35L6TKNmzX4JUEuqauP/B8 mNl/hGfQzvcLj22ySO8fN+YcubTeyeVC/+Qa93KeYHi/PBZ0CTcTZGm7iBDXgTjTQw zVhkKhv9glanzvbcnC6jnDWs+CT0pXqtCJtJ9TBA= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Fri, 26 Apr 2013 23:08:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:f1c3:e3e8:56e0:efc6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id ED2F8216C43; Fri, 26 Apr 2013 23:08:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5046C3313752; Sat, 27 Apr 2013 09:08:43 +1000 (EST) To: Scott Kitterman From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> In-reply-to: Your message of "Fri, 26 Apr 2013 18:52:35 -0400." <4272263.gKzvRQiTlr@scott-latitude-e6320> Date: Sat, 27 Apr 2013 09:08:42 +1000 Message-Id: <20130426230843.5046C3313752@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 23:08:53 -0000 In message <4272263.gKzvRQiTlr@scott-latitude-e6320>, Scott Kitterman writes: > > I don't think this is a good idea, but I'll ask a couple of questions > anyway. > > What's the appropriate response for SERVFAIL or no response at all > (timeout) on the type SPF query? For this case you can fallback to making a TXT query as the data content MUST be identical if present. This is different to MX query failures where the implicit MX record may not match the explict MX record. > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From spf2@kitterman.com Fri Apr 26 16:19: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 8295921F9D1F for ; Fri, 26 Apr 2013 16:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sKqns1pl+tI for ; Fri, 26 Apr 2013 16:19:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCA121F9D1E for ; Fri, 26 Apr 2013 16:19:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A799D20E4167; Fri, 26 Apr 2013 19:19:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367018361; bh=6k0jOkolem76lsooRxYEGRD7z+9w44MtLMcSf/LxI5w=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mr+qCwF+WEX2iy6x9vvmPahBinTaZFhISULsE+RmZ/3Zt/8y+qLq8TVSmZaKBF9Fy hnjzY50UWYnjZr1vag7fIxbqUgmVMzHA27JbrW5G58dmbTp6OZCSJJwbc7IOBUOYDY t27eUOXoCtZchueZMyo/gtQux0L8yHradmAlmjcI= 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 8D24920E40CF; Fri, 26 Apr 2013 19:19:21 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 19:19:20 -0400 Message-ID: <5490369.eeVXa2xi0q@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130426230843.5046C3313752@drugs.dv.isc.org> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <20130426230843.5046C3313752@drugs.dv.isc.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] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 23:19:22 -0000 On Saturday, April 27, 2013 09:08:42 AM Mark Andrews wrote: > In message <4272263.gKzvRQiTlr@scott-latitude-e6320>, Scott Kitterman writes: > > I don't think this is a good idea, but I'll ask a couple of questions > > anyway. > > > > What's the appropriate response for SERVFAIL or no response at all > > (timeout) on the type SPF query? > > For this case you can fallback to making a TXT query as the data > content MUST be identical if present. This is different to MX query > failures where the implicit MX record may not match the explict MX > record. Not according to the text he wrote. Based on the text, those would get a result of temperror even if a TXT query would have gotten a perfectly fine answer (and yes, this happens enough that it's one of the reasons no software I'm in charge of queries for SPF, it's a waste). Adding type SPF support back in a useful and correct way would be more complex than has been suggested (not that we are). Also, MUST be identical is an interesting requirement that's impossible to verify consistently in practice since one type or the other may be cached somewhere. The receiver can't tell if they get two answers that are different if they are intentionally different or not. It's kind of a pointless MUST. Scott K From mansaxel@besserwisser.org Fri Apr 26 16:29: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 AAB4821F9965 for ; Fri, 26 Apr 2013 16:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_ADULT2=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMuuust-Lofv for ; Fri, 26 Apr 2013 16:29:00 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id CA1F121F9947 for ; Fri, 26 Apr 2013 16:28:59 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id CAB409EF0; Sat, 27 Apr 2013 01:28:58 +0200 (CEST) Date: Sat, 27 Apr 2013 01:28:58 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Scott Kitterman Message-ID: <20130426232858.GV23770@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1J4USyVh4Jt5OGCL" Content-Disposition: inline In-Reply-To: <4272263.gKzvRQiTlr@scott-latitude-e6320> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 23:29:00 -0000 --1J4USyVh4Jt5OGCL Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Fri, Apr 26, 201= 3 at 06:52:35PM -0400 Quoting Scott Kitterman (spf2@kitterman.com): > > This way, both sides get what they want. People who wish to run old name > > server software can continue, provisioning systems may be subjected to > > bitrot, and the stuff that gets upgraded will do the right thing. > >=20 > > ( The elephant in the room is Windows Server. When it allows injection = of > > SPF RRen in its DNS server, we're good. For real.) >=20 > I don't think this is a good idea, but I'll ask a couple of questions any= way. >=20 > What's the appropriate response for SERVFAIL or no response at all (timeo= ut)=20 > on the type SPF query? Good one! SERVFAIL probably terminates processing. "temperror" in the language of the spfbis. SERVFAIL is returned when the full-service resolver can find the alleged server for the zone; it is running and reachable, but it has no data on the zone, not even SOA. Classic case is the slave that failed to do AXFR.=20 In the timeout case all name servers are unreachable (permanent or temporary). I'd argue for temperror here too.=20 Good argument can sway me here, but both cases are pretty hopeless in terms of getting data out of the zone at all. (at that point in time, which is an argument for "temperror") Thus, I find it unlikely to succeed in getting responses back for TXT when SPF queries have SERVFAILed or timed out. Outdated middleboxes should return NOTIMP which could trigger re-query using TXT. (yeah, I'm an optimist.) =20 > Do you think it is in the scope of the charter language to add a 2119 MUS= T for=20 > publishing type SPF when it's essentially unused? I do not think the charter permits SPF removal, so spfbis must deal with its continued existence.=20 Naturally, spfbis, by the same logic, can't remove TXT either. It can, however, discourage its use. Why should it? Well, apart from "Overloading TXT is bad" (which we all know, in our soul-searching, is the Right answer :), I'd state that, IMNSHO, the ut.edu example is a clear indication as to why TXT can never be more than a stopgap measure waiting for resolver and name server code updates. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Yow! Is this sexual intercourse yet?? Is it, huh, is it?? --1J4USyVh4Jt5OGCL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF7DboACgkQ02/pMZDM1cVt8QCfZugL5QMX92Gxa/lelaNM9QfR jnQAnRhCUkY98n5rnUK71jbFpXj8smLA =w2al -----END PGP SIGNATURE----- --1J4USyVh4Jt5OGCL-- From sm@elandsys.com Fri Apr 26 16:32: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 72E6421F9CF8 for ; Fri, 26 Apr 2013 16:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpErmDDuq+aq for ; Fri, 26 Apr 2013 16:32:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B912D21F9CF5 for ; Fri, 26 Apr 2013 16:32:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.115]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3QNWYgk017628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Apr 2013 16:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367019167; bh=5o3a0mr1toi5EHvnCZPyKUC+HobDu6BnG39Nhcmp8G8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FLNUPYeTH60/Ctt5ullRRvcfJUWT+9UzDbTB/c3Vtz456z+B/t3ocemK7wUnQtz4V RsGJk+pOzogIgpRjjkFxFHzAtw/ZId469oVAzVvp88WvU2u7xpukZlbk1DGXvy2ujc q35iDqA2C477tt6Y0vKLUim7uTj9mU3u2eNUn6T0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367019167; i=@elandsys.com; bh=5o3a0mr1toi5EHvnCZPyKUC+HobDu6BnG39Nhcmp8G8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bfIVTk29W9530N92ZTCeqR4oiQS70VMxM92ALsL9Rhar2aoKyV/xsn3I3GHQimENo fJdJyWz9BysgwQ8CozBiF+A7Zl0IgixfRqd/EUACRf6Y+wV5xFJd0NChcurvaswEw0 HM6KMsHu72V8/i52EEo2uzH+ilnCKgc2yz6eOR9w= Message-Id: <6.2.5.6.2.20130426161735.0ca2f828@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 26 Apr 2013 16:31:19 -0700 To: =?iso-8859-1?Q?M=C3ns?= Nilsson From: S Moonesamy In-Reply-To: <20130426224519.GU23770@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <1453053.12BnJ8GF9f@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D58@mbx-01.win.nominum.com> <1538026.HyQorgixtm@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160D89@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775160DC3@mbx-01.win.nominum.com> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 23:32:58 -0000 At 15:45 26-04-2013, M=C3=A5ns Nilsson wrote: >I'd suggest that the spfbis draft gets text along these lines: > > SPF records MUST be published as a DNS SPF (type 99) > Resource Record (RR) . The > character content of the record is encoded as target=3D"US-ASCII"/>. Use of alternate DNS RR types was > supported in SPF's experimental phase, but has been > discontinued. The intermediate practice of publishing SPF > data in TXT records MAY be retained along the required SPF > RR for compatibility reasons, but MUST NOT be the sole > publication. A SPF (type 99) record MUST be present. > >... > > In accordance with how the records are published (see target=3D"records"/> above), a DNS query needs to be made for the > <domain> name, querying for type SPF. If the reply is valid > but empty (RCODE NOERROR (0) and answer count =3D=3D 0), check_host() > MAY query for the same <domain> name, but substituting the > resource record type with TXT. > > (XML diffs can be had by asking) > >This way, both sides get what they want. People who wish to run old name >server software can continue, provisioning systems may be subjected to >bitrot, and the stuff that gets upgraded will do the right thing. Thanks for suggesting text. I am aware that the=20 issue has been discussed previously. It is an=20 unusual situation. I'll leave it to the working=20 group to discuss about the above. Regards, S. Moonesamy (as document shepherd)=20 From spf2@kitterman.com Fri Apr 26 16:38: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 6229D21F8E93 for ; Fri, 26 Apr 2013 16:38:43 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POwV5kI9EW3L for ; Fri, 26 Apr 2013 16:38:41 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5307721F8E5D for ; Fri, 26 Apr 2013 16:38:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C0FAE20E40D5; Fri, 26 Apr 2013 19:38:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367019520; bh=VIAxAieoprBhT9p5w1Ry01v+hx+wi0DLFk/RlDgieKM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BiVd6fa56Ez6uoAaqqbVqeLGpZuDDfvRCZzYR8p+piQSj9bBiES6OyKZCGiS08Vm7 UE0bdW9eJFlk63THPP8Bl/03vGq8hRpZwD9fvswG4aFP/UUU8jL9xwHDclCTH0k9AF mKUklWiOddNsMa/xM1z9oExAFoRnerdfSvCGntr0= 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 A972320E40CF; Fri, 26 Apr 2013 19:38:40 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Apr 2013 19:38:39 -0400 Message-ID: <8652358.d9CnLvTYr7@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130426232858.GV23770@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <20130426232858.GV23770@besserwisser.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Cc: =?ISO-8859-1?Q?M=E5ns?= Nilsson Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 26 Apr 2013 23:38:43 -0000 On Saturday, April 27, 2013 01:28:58 AM M=E5ns Nilsson wrote: > Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Fri, Apr 2= 6, 2013=20 at 06:52:35PM -0400 Quoting Scott Kitterman (spf2@kitterman.com): > > > This way, both sides get what they want. People who wish to run o= ld name > > > server software can continue, provisioning systems may be subject= ed to > > > bitrot, and the stuff that gets upgraded will do the right thing.= > > >=20 > > > ( The elephant in the room is Windows Server. When it allows inje= ction > > > of > > >=20 > > > SPF RRen in its DNS server, we're good. For real.) > >=20 > > I don't think this is a good idea, but I'll ask a couple of questio= ns > > anyway. > >=20 > > What's the appropriate response for SERVFAIL or no response at all > > (timeout) on the type SPF query? >=20 > Good one! SERVFAIL probably terminates processing. "temperror" in the= > language of the spfbis. SERVFAIL is returned when the full-service > resolver can find the alleged server for the zone; it is running and > reachable, but it has no data on the zone, not even SOA. Classic case= > is the slave that failed to do AXFR. >=20 > In the timeout case all name servers are unreachable (permanent or > temporary). I'd argue for temperror here too. >=20 > Good argument can sway me here, but both cases are pretty hopeless in= > terms of getting data out of the zone at all. (at that point in time,= > which is an argument for "temperror") >=20 > Thus, I find it unlikely to succeed in getting responses back for TXT= > when SPF queries have SERVFAILed or timed out. Outdated middleboxes > should return NOTIMP which could trigger re-query using TXT. (yeah, > I'm an optimist.) Should, but they don't. For implementations that don't deal with type = SPF,=20 SERVFAIL or no answer at all are the most common effects. So failure o= f a type=20 SPF query in one of these manners doesn't tell you anything about what = would=20 happen with a TXT query. [snipped the other bit, since it's pretty clearly something we are goin= g to=20 disagree on] Scott K From ajs@anvilwalrusden.com Fri Apr 26 18:24: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 659D121F9D3A for ; Fri, 26 Apr 2013 18:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYeYunAeUywp for ; Fri, 26 Apr 2013 18:24:49 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id E2C2E21F9D0A for ; Fri, 26 Apr 2013 18:24:48 -0700 (PDT) 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 D7D878A031 for ; Sat, 27 Apr 2013 01:24:47 +0000 (UTC) Date: Fri, 26 Apr 2013 21:24:46 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130427012445.GO809@mx1.yitter.info> References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <20130426232858.GV23770@besserwisser.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130426232858.GV23770@besserwisser.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 27 Apr 2013 01:24:49 -0000 Chair hat on. On Sat, Apr 27, 2013 at 01:28:58AM +0200, MÃ¥ns Nilsson wrote: > > I do not think the charter permits SPF removal, so spfbis must deal with > its continued existence. We actually had protracted discussion about that in the past, and concluded differently. In particular, as I already noted in another thread (on, IIRC, another mailing list), we discovered that there was an error in 4408 that led to interoperability problems. Our charter says this: Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. We did in fact originally decide that deprecating the SPF RRTYPE would be removing a feature that was not "unused"; this was actually the subject of an appeal, because some participants felt that the chairs were interpreting "unused" too strictly. You may see the results of all that in http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html. But the problem arose once we started to consider an _error_ in 4408, which is that it specified things in such a way that two conforming implementations could fail to interoperate; that is surely an error in the spec. We have to do _something_, though any action would introduce a backward incompatibility. The decision is covered under "correction of errors" in the charter text above. After some deliberation, the WG decided to deprecate SPF. Each of the options has problems, but we determined that this is the one most in line with the facts of the world, the likely future (based on analogies with other deployment patterns), and the minimization of additional needless queries in the DNS. Under the circumstances, I (at least) believe our charter does permit the deprecation of SPF. You can ask others how reluctantly I came to this conclusion, but I nevertheless think it's the right one, given the evidence. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Fri Apr 26 19:44: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 31B1821F9D53 for ; Fri, 26 Apr 2013 19:44:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTsPDwciCTJ1 for ; Fri, 26 Apr 2013 19:44:39 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 610D421F9D36 for ; Fri, 26 Apr 2013 19:44:39 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 1B1DDC9496; Sat, 27 Apr 2013 02:44:28 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367030675; bh=WQzrVwn+4Z7od85+dDVjbxV3zZKQ2aoCjidIJCLeXgY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=NPrhMkFB+IVDkW6wBOhQPnFSNrAq3V5xPTNbI4t7/uE8gGxZKuL3vVA5sOWSn9tV0 KDW8LLit2jes34lwcr+gBji+VRJHs4ppn04/rZ6gyPAGatAg2fiuL4+DwBwAgsPGQE yCE0tUOijGkZ7fd1CWmCWKw4PQqmq98pQt+1Rsvs= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Sat, 27 Apr 2013 02:44:28 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5F409216C40; Sat, 27 Apr 2013 02:44:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4E3CE3314ABC; Sat, 27 Apr 2013 12:44:00 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <20130426232858.GV23770@besserwisser.org> <20130427012445.GO809@mx1.yitter.info> In-reply-to: Your message of "Fri, 26 Apr 2013 21:24:46 -0400." <20130427012445.GO809@mx1.yitter.info> Date: Sat, 27 Apr 2013 12:43:57 +1000 Message-Id: <20130427024401.4E3CE3314ABC@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 27 Apr 2013 02:44:40 -0000 In message <20130427012445.GO809@mx1.yitter.info>, Andrew Sullivan writes: > Chair hat on. > > On Sat, Apr 27, 2013 at 01:28:58AM +0200, Mns Nilsson wrote: > > > > I do not think the charter permits SPF removal, so spfbis must deal with > > its continued existence. > > We actually had protracted discussion about that in the past, and > concluded differently. In particular, as I already noted in another > thread (on, IIRC, another mailing list), we discovered that there was > an error in 4408 that led to interoperability problems. > > Our charter says this: > > Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any > enhancements > that have already gained widespread support, and addition of > clarifying language. > > We did in fact originally decide that deprecating the SPF RRTYPE would > be removing a feature that was not "unused"; this was actually the > subject of an appeal, because some participants felt that the chairs > were interpreting "unused" too strictly. You may see the results of > all that in > http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html. > > But the problem arose once we started to consider an _error_ in 4408, > which is that it specified things in such a way that two conforming > implementations could fail to interoperate; that is surely an error in > the spec. We have to do _something_, though any action would > introduce a backward incompatibility. The decision is covered under > "correction of errors" in the charter text above. After some > deliberation, the WG decided to deprecate SPF. Each of the options > has problems, but we determined that this is the one most in line with > the facts of the world, the likely future (based on analogies with > other deployment patterns), and the minimization of additional > needless queries in the DNS. So it only "broken" when people fail to follow a SHOULD. I don't see a broken spec. I see a excuse. If you don't follow the SHOULD you need to understand the consequences which in this case you will not interoperate with everyone. Guess what there is NOTHING wrong with not interoperating with everyone. You get slightly less protection from bounce backs and you provide slightly less protection to other sites. You never had 100% protection anyway. > Under the circumstances, I (at least) believe our charter does permit > the deprecation of SPF. You can ask others how reluctantly I came > to this conclusion, but I nevertheless think it's the right one, given > the evidence. And I would argue that it was never a error but a deployment choice. You choose to not upgrade nameservers to ones capable serving SPF records. You choose to use a registrar that doesn't support type SPF. You choose to deploy firewalls that block SPF records. You choose to use a OS with a broken resolver that doesn't let through SPF records. These are all local decisions to the people deploying SPF. Nobody in the middle of the net is blocking type SPF records. Mark > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dhc@dcrocker.net Fri Apr 26 20:11: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 CC26B21F9D73 for ; Fri, 26 Apr 2013 20:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0ckRhU5ZKjv for ; Fri, 26 Apr 2013 20:11:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 38E1B21F9D70 for ; Fri, 26 Apr 2013 20:11:45 -0700 (PDT) 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 r3R3Behe002747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Apr 2013 20:11:43 -0700 Message-ID: <517B41E5.1050708@dcrocker.net> Date: Fri, 26 Apr 2013 20:11:33 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <20130426232858.GV23770@besserwisser.org> <20130427012445.GO809@mx1.yitter.info> <20130427024401.4E3CE3314ABC@drugs.dv.isc.org> In-Reply-To: <20130427024401.4E3CE3314ABC@drugs.dv.isc.org> 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.66]); Fri, 26 Apr 2013 20:11:43 -0700 (PDT) Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 27 Apr 2013 03:11:45 -0000 On 4/26/2013 7:43 PM, Mark Andrews wrote: > These are all local decisions to the people deploying SPF. Nobody > in the middle of the net is blocking type SPF records. Mark, what are you trying to accomplish? Operationally, the real-world situation with SPF is quite simple and completely clear. Procedurally, the working group is merely trying to adjust the specification to reflect extensive deployment experience; this is neither a new nor controversial approach to working group efforts in the IETF. So again I'll ask, what is your constructive intent here? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Sat Apr 27 00:01: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 1EFF021F9DE5 for ; Sat, 27 Apr 2013 00:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHplcrMuZfTB for ; Sat, 27 Apr 2013 00:01:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9165D21F9DDB for ; Sat, 27 Apr 2013 00:01:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.148]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3R70ldA016762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Apr 2013 00:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367046060; bh=9mP1RpVTrsSVtWwsDPlHggs1kaj2BACAcZsS9Y5RHVA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=N/pCnhcAJG/WztLGog3iwc37/8cCzuwWX+dzxOic5cdfEdImKZiqBh3gdzoVYfhUq b/NPGP/iyzaCU6N9QmPx2ojKX8OeOhJsbSz1i/WFrF34E4nLl/Y8acZA1demguOJVY 6/EQAmxsA5fDkn0c2wlNAhk+TaE9vpFWoushsUCA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367046060; i=@elandsys.com; bh=9mP1RpVTrsSVtWwsDPlHggs1kaj2BACAcZsS9Y5RHVA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=072JesbFD9kymPXyxvxal+mpJkSn32WTU0MqSiO9U0gcDfq3T+QyPqk/+j7ZowibV je3cAY0vQNuSpDQKA4x918KQH80RPB0mks/p3S6pkxATXdojiJUM1WV2iJbfwjijkX LHrK2FYaDgSLismuqBwWg+wThabQZ4KKReN6FyvA= Message-Id: <6.2.5.6.2.20130426224257.0c007700@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 26 Apr 2013 23:54:42 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20130427024401.4E3CE3314ABC@drugs.dv.isc.org> References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <20130426232858.GV23770@besserwisser.org> <20130427012445.GO809@mx1.yitter.info> <20130427024401.4E3CE3314ABC@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Mark Andrews Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 27 Apr 2013 07:01:04 -0000 At 19:43 26-04-2013, Mark Andrews wrote: >So it only "broken" when people fail to follow a SHOULD. I don't see >a broken spec. I see a excuse. I read RFC 4408 several times over the last year. I also reviewed draft-ietf-spfbis-4408bis-14 and read all the previous revisions of that draft. I don't find arguments that X is "broken" convincing unless it is accompanied by a clear explanation. "People failing to follow a SHOULD" is not a clear explanation in my opinion as I cannot verify that claim. The IETF way is to tell people to go and read the mailing list archives. I provided references to some of the relevant threads as I think that it might help people find out how the decision was taken and why it was taken. There were some intertwined issues, e.g. Issue #25 [1]. There is message from John Levine which I'll quote partially: "So my suggestion is to close this issue, keeping in mind that we may come back and remove the section if we deprecate type 99." I note that there is an "if" in the above. >If you don't follow the SHOULD you need to understand the consequences >which in this case you will not interoperate with everyone. Guess >what there is NOTHING wrong with not interoperating with everyone. >You get slightly less protection from bounce backs and you provide >slightly less protection to other sites. You never had 100% >protection anyway. [snip] >And I would argue that it was never a error but a deployment choice. > >You choose to not upgrade nameservers to ones capable serving SPF records. >You choose to use a registrar that doesn't support type SPF. >You choose to deploy firewalls that block SPF records. >You choose to use a OS with a broken resolver that doesn't let through SPF >records. > >These are all local decisions to the people deploying SPF. Nobody >in the middle of the net is blocking type SPF records. The SPF specification has a checkered history. I prefer not to comment about that. If I recall correctly some of the above points were raised during the discussions. Some of the arguments which have been made in previous WG discussions are being restated. I don't consider that as new information which can be used to reconsider a decision. The Responsible Area Director mentioned [3] what would be helpful and that seems clear enough to me. If someone provides an argument together with a good explanation it is not going to be ignored no matter how vocal other SPFBIS WG participants are. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00845.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00848.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg03497.html From vesely@tana.it Sat Apr 27 00:18: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 8714621F989C for ; Sat, 27 Apr 2013 00:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.681 X-Spam-Level: X-Spam-Status: No, score=-4.681 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1awhi9snM04 for ; Sat, 27 Apr 2013 00:18:20 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 999CB21F988A for ; Sat, 27 Apr 2013 00:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367047098; bh=rBd7+0/HQe2GPsviQaLLLd4GY+ZCF4hL+YpP2c8d9sk=; l=1423; h=Date:From:To:References:In-Reply-To; b=UsI8XGsubnDbtAbnOA8/M4Iis0Vk0kQHOfCJ6GqRckHRPH37E2FIpITwYV5fE09j0 YsMFz0B/vXii55EVdi0PWNyS21FQwaPZC33r+eLRtPDLVR/ZO7U7B2O81yol2Z3E8E UjZGgADBJy38ODkM/ypv/Q7z9CB9m8S26oU6CSo0= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sat, 27 Apr 2013 09:18:18 +0200 id 00000000005DC045.00000000517B7BBA.00003551 Message-ID: <517B7BB9.8020706@tana.it> Date: Sat, 27 Apr 2013 09:18:17 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <51726641.7070606@tana.it> <1818071.XgB9D1drlR@scott-latitude-e6320> <517A5363.6060902@tana.it> <1845397.bn79S9oqEB@scott-latitude-e6320> In-Reply-To: <1845397.bn79S9oqEB@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 27 Apr 2013 07:18:21 -0000 On Fri 26/Apr/2013 14:38:21 +0200 Scott Kitterman wrote: > On Friday, April 26, 2013 12:13:55 PM Alessandro Vesely wrote: >> On Thu 25/Apr/2013 16:05:04 +0200 Scott Kitterman wrote: >>> On Thursday, April 25, 2013 06:57:54 AM Murray S. Kucherawy wrote: >>>>> In fact, Section 4.3 already says: >>>>> If the has no local-part, substitute the string >>>>> "postmaster" for the local-part. >>>>> >>>>> How come it has no local part? We don't need to do it twice. The >>>>> former sentence is a "shortcut" to say that checking HELO is required >>>>> when MAIL FROM is null. >>>> >>>> What about macro evaluation? >>> >>> Macro evaluation is precisely why that's there. >> >> I still cannot figure out how it is possible to get a sender with no >> local part (except malformed MAIL FROM). Both Section 5.2 and 6.1 say: >> >> The and arguments remain the same >> as in the current evaluation of check_host(). >> >> So it seems that if has a local part initially, it will never >> go away. Any example to the contrary? > > If mail from is null, you substitute HELO for mail from. Yeah, right. Well, nearly: One should use postmaster@HELO, according to the definition, no? We already had this discussion in [1], where you said that removing that ridiculous definition is a "protocol change". [1] http://www.ietf.org/mail-archive/web/spfbis/current/msg03021.html From ajs@anvilwalrusden.com Sat Apr 27 06:28: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 DB43621F973B for ; Sat, 27 Apr 2013 06:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.658 X-Spam-Level: X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjRWPyJrpIwK for ; Sat, 27 Apr 2013 06:28:39 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 00AB621F973A for ; Sat, 27 Apr 2013 06:28:38 -0700 (PDT) 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 90D648A031 for ; Sat, 27 Apr 2013 13:28:37 +0000 (UTC) Date: Sat, 27 Apr 2013 09:28:35 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130427132835.GR809@mx1.yitter.info> References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <20130426232858.GV23770@besserwisser.org> <20130427012445.GO809@mx1.yitter.info> <20130427024401.4E3CE3314ABC@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130427024401.4E3CE3314ABC@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 27 Apr 2013 13:28:40 -0000 No hat. On Sat, Apr 27, 2013 at 12:43:57PM +1000, Mark Andrews wrote: > > And I would argue that it was never a error but a deployment choice. But the evidence that we have in RFC 6686 is that the deployment choice was overwhelmingly made in favour of TXT. There wasn't a significant uptake even of the "both" option. In fact, even people who did SPF records _didn't all do both_, which means that even among the tiny minority who used the SPF records, some of them didn't follow the SHOULD in RFC 4408. At some point, you have to say that the running code wins. Of all people, you should know this, as clarifications to DNS protocol documents have on occasion been issued precisely because widely deployed DNS server code bases did not precisely align with the way the RFC was written. Not always, of course, but it's happened, and for exactly the same reason as in this particular case: that's just the way the network is, and it's working, so we should make our documents align with reality rather than trying to be legislators of the Internet. Again, I wish _very much_ that TXT is not what SPF used lo these many years ago. I also wish _very much_ that there was any evidence that the SPF RR offers enough of an advantage that we could expect people to move over, or that there was any evidence that the overloading of TXT records does enough harm that we ought to jump up and down and try to get people to accept that argument in the way we've done for (say) BCP 38. But BCP 38 gives us another instructive example: even when there is demonstrable, clear, real harm that exposes people to civil liability when they do not deploy something, if there is not a positive incentive to deploy it then we should expect that some won't. How much less the incentive, then, to switch from TXT to SPF, particularly since 4408bis cannot possibly deprecate the use of TXT and ever be useful as a protocol document? The most we could do is specify that (non-existent) SPF records be looked up first. I cheerfully predict that a document with such a requirement would be widely ignored by the largest mail sites, because it would involve additional latency and an additional lookup. If you're processing millions of mails an hour, those additional lookups add up, and if you have every reason to believe that the lookup will yield nothing, you just won't do it. The report in RFC 6686 (which is sketchy and, admittedly, based on a possibly flawed study, but the only actual evidence we have) confirms that prediction, I note. The only evidence we have of anyone querying for TYPE 99 is of someone querying for TYPE 99 and TYPE 16 at the same time, and presumably taking whatever the first answer to return is. Even worse, if you publish both types, then you need some mechanism to make sure they're identical. There's actually no way to ensure this, and _much worse_ because of caching effects, it's almost certain that the two types will be observable on the Internet sometimes with different RDATA. So the sentence in 4408, "If a domain has records of both types, they MUST have identical content," is almost guaranteed not to be true sometimes, and the specification would need to be considerably more complicated in order to make clear what is ok at what place in what parts of the DNS. It's true that DNS is "eventually consistent", but here we're talking about two distinct RRs that are supposed to have "the same data" in some sense -- a problem DNS nerds have confronted in other contexts and which is just as impossible in this case as it is in those other ones. The original protocol has DNS problems that can only be resolved through one of the three courses of action I have already outlined. As nearly as I can tell, the best trade-off, both operationally and from a protocol design point of view, is to deprecate RRTYPE 99. This does not mean I think it is a good design: it is merely the best of three bad options. You seem to disagree with me, but I've yet to see a reason I can understand as to why your proposal is better. Because it increases traffic, it is unlikely to be deployed, so it means the new RFC just won't get adopted (indeed, what's more likely is that we'll get 4408bis mostly, except for the parts of 4408 that are convenient, which means the protocol will acutally be documented _nowhere_). This state of affairs would make us look foolish, also. Finally, your proposal does nothing to solve the problem that the two record types can never be guaranteed to have the same RDATA everywhere, which means that there is always the potential for inconsistent data around the network. All of the above is already well-hashed in previous conversations on this in the archives, and as SM has suggested there's no reason to revisit this decision unless someone has something new to bring to this topic. Do you? I don't, so this is my last word on it unless someone comes up with something that hasn't already been considered. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Sat Apr 27 07:55: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 97A0C21F989A for ; Sat, 27 Apr 2013 07:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUHZiJAPJb35 for ; Sat, 27 Apr 2013 07:55:33 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A66DB21F9899 for ; Sat, 27 Apr 2013 07:55:32 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.148]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3REtHx8015019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Apr 2013 07:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367074529; bh=ti5qDl4arHqSJ1/1Ayce46a3uP3NTMwX7MHZTrjEeCY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=l28D5TOco/o4m6cygxbF1UI7/a1OYNDA69e3o1UTpBKo18TtAYJBjLmu876qqHQMB mIv6B8Rff6htdyZWFoPFXagDbUXyQLeSbTbGhYnX7ODEVPFHfc8/h7/SP6fF++7xv6 wp2olr4kz+Yo3Jto41mrIzUso0/YRSCmFUGtPf+0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367074529; i=@elandsys.com; bh=ti5qDl4arHqSJ1/1Ayce46a3uP3NTMwX7MHZTrjEeCY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YSyf5pndNm7zPlj4yp6X13N17oGdErqtLbamVEGCoatVmavQBNvGd/46pQo20RSB8 1Hce3oP8/pJlSfL64O/IKWFbEy98u0cKGPQf3rjpYh673jOEO9te4uOyYeZdFHeOhs lTlaDL6Wn8bwS8l0cM/Vnf2+Jeyp9Yks2na7KPgY= Message-Id: <6.2.5.6.2.20130427065003.0b82af78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 27 Apr 2013 07:17:29 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <517B7BB9.8020706@tana.it> References: <51726641.7070606@tana.it> <1818071.XgB9D1drlR@scott-latitude-e6320> <517A5363.6060902@tana.it> <1845397.bn79S9oqEB@scott-latitude-e6320> <517B7BB9.8020706@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] New issue: 8.4. Fail: rejection is not described explicitly 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, 27 Apr 2013 14:55:33 -0000 Hi Alessandro, I read the messages on the thread at http://www.ietf.org/mail-archive/web/spfbis/current/msg03369.html The issue of "8.4. Fail: rejection is not described explicitly" may be related to other issues. It may be better to try and get the other outstanding issues resolved first and then get back to this one. I'll try and provide a rough summary of this issue after that. The SPFBIS WG can then decide what it wants to do about it. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03374.html From sm@elandsys.com Sat Apr 27 07:55: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 E5C2521F98AA for ; Sat, 27 Apr 2013 07:55:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqYgJVRqj1Sg for ; Sat, 27 Apr 2013 07:55:48 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA64221F9899 for ; Sat, 27 Apr 2013 07:55:47 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.148]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3REtHxA015019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Apr 2013 07:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367074536; bh=AP/bZNgScaMluPDIE8R6Jq2qrS8EMEiqb8Tm5u2n4gU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=K1NFSUCNxJqOHrZljRr8u/3nIhlzuRZhlf21De5vAPEApAjlnvP3rb7mt9+NenEji JAcIk1VbCHYNVdMjj2grURvVEQ3b/OturzJ1GlGj4dfVPJbLLqCIiot4c44kaQmGCx o+QrTOpDTgu5fc2ZmmznbW1mrG0MsSRFv4Y5sY8c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367074536; i=@elandsys.com; bh=AP/bZNgScaMluPDIE8R6Jq2qrS8EMEiqb8Tm5u2n4gU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=npwfsQuctGUyGvctc6ZRrYlRhVaa1fBHqp1EwuQdFbmJWzItNpZNkwKJMBUEWVeZq ZKj2TCykT7r0xvpKLq/36CCT2tL8tApGWO9HUhZn8E/YmQfolhPy0/gumVl8atm5mc kpxpU6FoMf4VIRvfSJrb8zR1/MI7sqQdh/tOkALg= Message-Id: <6.2.5.6.2.20130427072046.0b6a9f40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 27 Apr 2013 07:49:36 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <517A5345.8090008@tana.it> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <20130424160954.GA31835@simplex.0x539.de> <517807E7.2050005@viagenie.ca> <1620648.vNPTWAe3vH@scott-latitude-e6320> <51780DCC.7020802@viagenie.ca> <517A5345.8090008@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Tom Taylor , Philipp Kern , Alessandro Vesely Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 27 Apr 2013 14:55:49 -0000 At 03:13 26-04-2013, Alessandro Vesely wrote: >It is not clear to me what underlying layer we'd refer to. The kernel >obviously cannot do that if the socket is IPv6. Tim Taylor suggested some text [1]. There is also some text from Scott Kitterman [2]. Could someone please explain what this "underlying layer" is? Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03440.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg03436.html From hsantos@isdg.net Sat Apr 27 08:08: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 89C6221F8EBD for ; Sat, 27 Apr 2013 08:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.947 X-Spam-Level: X-Spam-Status: No, score=-101.947 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvyXPJSHCCwc for ; Sat, 27 Apr 2013 08:08:38 -0700 (PDT) Received: from news.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 37F9A21F84CA for ; Sat, 27 Apr 2013 08:08:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=8011; t=1367075308; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=wabx3G9 X8AwGOQSPyH8S7xW7nwU=; b=qDH497U0qtAQJIFlLbUCAj3qIiN6OUb7Exxt0FE tyIEOJK/v95Bb/3ViBSVmVRTIxrmfy1QRs7G5xoJ4Z8e1Ctn2NXvZtPe6ZqzvHxs GX6o5fDIIHJKMaNpbyquL0J72a5152bGAaxeFYLKJYRzELfjQuHneYgsJElVxK75 M1ZY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 27 Apr 2013 11:08:28 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1574028530.3075.3832; Sat, 27 Apr 2013 11:08:27 -0400 Message-ID: <517BE999.1030800@isdg.net> Date: Sat, 27 Apr 2013 11:07:05 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andrew Sullivan References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <20130426232858.GV23770@besserwisser.org> <20130427012445.GO809@mx1.yitter.info> <20130427024401.4E3CE3314ABC@drugs.dv.isc.org> <20130427132835.GR809@mx1.yitter.info> In-Reply-To: <20130427132835.GR809@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 27 Apr 2013 15:08:39 -0000 I don't think there has been adequate redesign considerations here. All I'm hearing is that TXT-based solutions is going to be the only practical design solution for future DNS applications for the fastest entry into the market place. AUTH-RES was kludged into SPFBIS. It is still not correct, changes are still required after the fact, yet, the same can continue to be done with SPFBIS in regards to a dual call migration path. As you saw, dual TXT/TXT calls are been advocated and also now done among the larger ESP domains and traffic - the victims are the SMTP receivers that has to make all these redundant calls for domains that don't need them!! gmail.com, hotmail.com, facebook.com - they don't need a TXT/TXT dual call SPF operation! That is just as inefficient as have a 99/TXT call. Its all WORST when the policies are relaxed - very little to zero payoff in SPF processing for the incoming domain. Only facebook.com offers a high payoff with a SPF fail policy. This problem is not being solved correctly and I am growing tired of my own suggestions being ignored, so why not just ignored SPFBIS? One thing for sure, we knew since, dare I say the word MARID, that this will be a major endorsement issue and it continues to be. I wanted to sense the status quo last year when I poised the question in IETF and DNSOP and even then and today the status quo remains. Nothing has changed except that the folks against SPF during MARID and over the years, have finally accepted it and have also leveraged the success of SPF with TXT records for their own protocols, case in point; DKIM, VBR and now DMARC. That's not performing a well integrated effort among all parties involved; systems engineers, ISVs, DBAs, DNS administrators, developers, network, infrastructure folks and also documentation writers, etc! Just get Microsoft rep here to tell us why MS DNS v5.0+ do not support and will not support unnamed type processing, and I will finally throw up my own hands on this and perhaps even begin to produce future TXT-based Domain Policy/Operations I-D proposals too. Overall, I feel SPFBIS does not have to advocate removal is basically my point to achieve the same level support. Consider that it will help raise the endorsement barrier that it will surely get in remaining last calls and reviews outside this group. I just hope that we don't get into a brushing aside of input and rubber stamp this effort. You can't continue to put good engineering on the spot with this engineering issues that are solvable with the right team work going on. In my honest opinion, SPFBIS does not *completely* fit real operations out there and is in many ways, already outdated. -- HLS On 4/27/2013 9:28 AM, Andrew Sullivan wrote: > No hat. > > On Sat, Apr 27, 2013 at 12:43:57PM +1000, Mark Andrews wrote: >> >> And I would argue that it was never a error but a deployment choice. > > But the evidence that we have in RFC 6686 is that the deployment > choice was overwhelmingly made in favour of TXT. There wasn't a > significant uptake even of the "both" option. In fact, even people > who did SPF records _didn't all do both_, which means that even among > the tiny minority who used the SPF records, some of them didn't follow > the SHOULD in RFC 4408. > > At some point, you have to say that the running code wins. Of all > people, you should know this, as clarifications to DNS protocol > documents have on occasion been issued precisely because widely > deployed DNS server code bases did not precisely align with the way > the RFC was written. Not always, of course, but it's happened, and > for exactly the same reason as in this particular case: that's just > the way the network is, and it's working, so we should make our > documents align with reality rather than trying to be legislators of > the Internet. > > Again, I wish _very much_ that TXT is not what SPF used lo these > many years ago. I also wish _very much_ that there was any evidence > that the SPF RR offers enough of an advantage that we could expect > people to move over, or that there was any evidence that the > overloading of TXT records does enough harm that we ought to jump up > and down and try to get people to accept that argument in the way > we've done for (say) BCP 38. > > But BCP 38 gives us another instructive example: even when there is > demonstrable, clear, real harm that exposes people to civil liability > when they do not deploy something, if there is not a positive > incentive to deploy it then we should expect that some won't. How > much less the incentive, then, to switch from TXT to SPF, particularly > since 4408bis cannot possibly deprecate the use of TXT and ever be > useful as a protocol document? The most we could do is specify that > (non-existent) SPF records be looked up first. I cheerfully predict > that a document with such a requirement would be widely ignored by the > largest mail sites, because it would involve additional latency and an > additional lookup. If you're processing millions of mails an hour, > those additional lookups add up, and if you have every reason to > believe that the lookup will yield nothing, you just won't do it. The > report in RFC 6686 (which is sketchy and, admittedly, based on a > possibly flawed study, but the only actual evidence we have) confirms > that prediction, I note. The only evidence we have of anyone querying > for TYPE 99 is of someone querying for TYPE 99 and TYPE 16 at the same > time, and presumably taking whatever the first answer to return is. > > Even worse, if you publish both types, then you need some mechanism to > make sure they're identical. There's actually no way to ensure this, > and _much worse_ because of caching effects, it's almost certain that > the two types will be observable on the Internet sometimes with > different RDATA. So the sentence in 4408, "If a domain has records of > both types, they MUST have identical content," is almost guaranteed > not to be true sometimes, and the specification would need to be > considerably more complicated in order to make clear what is ok at > what place in what parts of the DNS. It's true that DNS is > "eventually consistent", but here we're talking about two distinct RRs > that are supposed to have "the same data" in some sense -- a problem > DNS nerds have confronted in other contexts and which is just as > impossible in this case as it is in those other ones. > > The original protocol has DNS problems that can only be resolved > through one of the three courses of action I have already outlined. > As nearly as I can tell, the best trade-off, both operationally and > from a protocol design point of view, is to deprecate RRTYPE 99. This > does not mean I think it is a good design: it is merely the best of > three bad options. You seem to disagree with me, but I've yet to see > a reason I can understand as to why your proposal is better. Because > it increases traffic, it is unlikely to be deployed, so it means the > new RFC just won't get adopted (indeed, what's more likely is that > we'll get 4408bis mostly, except for the parts of 4408 that are > convenient, which means the protocol will acutally be documented > _nowhere_). This state of affairs would make us look foolish, also. > Finally, your proposal does nothing to solve the problem that the two > record types can never be guaranteed to have the same RDATA > everywhere, which means that there is always the potential for > inconsistent data around the network. > > All of the above is already well-hashed in previous conversations on > this in the archives, and as SM has suggested there's no reason to > revisit this decision unless someone has something new to bring to > this topic. Do you? I don't, so this is my last word on it unless > someone comes up with something that hasn't already been considered. > > Best, > > A > From superuser@gmail.com Sat Apr 27 09: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 6BB7F21F96E0 for ; Sat, 27 Apr 2013 09:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-rjJsG5btvH for ; Sat, 27 Apr 2013 09:19:16 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AB5B521F94DF for ; Sat, 27 Apr 2013 09:19:15 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id e11so2687165wgh.13 for ; Sat, 27 Apr 2013 09:19:14 -0700 (PDT) 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=HKlUEyuG9UQT8Is+V/yb/qFI2q+nc+psBWWDzZLzuPA=; b=G8tgStQsvdwl+amzjDCmEEiGDkgdHqCaAdeFsska9fi5oX8b4zTFTe2YiNfE5llR/D tV+xpDyEA+xkKu24KwmS29k+mVt4VN9rBurwN5Z3UX2OBt32jB4AZykE3lYxKyuVVKkD ILwCvAr3DhHpJj+kA6eBlmPXK06OymkGzqRl8B4cO3KtKgyvSWYRejnnNNOMRgltoCLD dlSPC/ju2tI3+9rAiN5hFY3lQ2oilU4sxDqujNTyUP28VUwCrIBQ/mGk+I0RCdaM5AzL gOT5Vfc4V3qNlItIaIZvImvFG9zlJjEhDQoBnPLQMjV+SFcRKALqIj3EoL3eAXq1qWoy C/yw== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr2162892wjb.17.1367079084680; Sat, 27 Apr 2013 09:11:24 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sat, 27 Apr 2013 09:11:24 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130427072046.0b6a9f40@resistor.net> References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <20130424160954.GA31835@simplex.0x539.de> <517807E7.2050005@viagenie.ca> <1620648.vNPTWAe3vH@scott-latitude-e6320> <51780DCC.7020802@viagenie.ca> <517A5345.8090008@tana.it> <6.2.5.6.2.20130427072046.0b6a9f40@resistor.net> Date: Sat, 27 Apr 2013 09:11:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7b5d8cff38ee3d04db59e790 Cc: "spfbis@ietf.org" , Alessandro Vesely , Philipp Kern , Tom Taylor Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 27 Apr 2013 16:19:16 -0000 --047d7b5d8cff38ee3d04db59e790 Content-Type: text/plain; charset=ISO-8859-1 As I understand it, the idea is that a connection arriving via an IPv6-mapped IPv4 address is supposed to be reported to the accepting application as an IPv4 connection, so SPF would never know about the "IPv6-mapped" part in the first place. On Sat, Apr 27, 2013 at 7:49 AM, S Moonesamy wrote: > At 03:13 26-04-2013, Alessandro Vesely wrote: > >> It is not clear to me what underlying layer we'd refer to. The kernel >> obviously cannot do that if the socket is IPv6. >> > > Tim Taylor suggested some text [1]. There is also some text from Scott > Kitterman [2]. Could someone please explain what this "underlying layer" > is? > > > Regards, > S. Moonesamy (as document shepherd) > > 1. http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03440.html > 2. http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03436.html > ______________________________**_________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/**listinfo/spfbis > --047d7b5d8cff38ee3d04db59e790 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As I understand it, the idea is that a connection arriving= via an IPv6-mapped IPv4 address is supposed to be reported to the acceptin= g application as an IPv4 connection, so SPF would never know about the &quo= t;IPv6-mapped" part in the first place.


On Sat,= Apr 27, 2013 at 7:49 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:
At 03:13 26-04-2013, Aless= andro Vesely wrote:
It is not clear to me what underlying layer we'd refer to. =A0The kerne= l
obviously cannot do that if the socket is IPv6.

Tim Taylor suggested some text [1]. =A0There is also some text from Scott K= itterman [2]. =A0Could someone please explain what this "underlying la= yer" is?


Regards,
S. Moonesamy (as document shepherd)

1. http://www.ietf.org/mail-archive/web/spfbis/= current/msg03440.html
2. http://www.ietf.org/mail-archive/web/spfbis/= current/msg03436.html
_______________________________________________
spfbis mailing list
spfbis@ietf.org = https://www.ietf.org/mailman/listinfo/spfbis

--047d7b5d8cff38ee3d04db59e790-- From sm@elandsys.com Sat Apr 27 11:15: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 21CDA21F98EE for ; Sat, 27 Apr 2013 11:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y7A1QHl4nfX for ; Sat, 27 Apr 2013 11:15:23 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6046221F98DE for ; Sat, 27 Apr 2013 11:15:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.148]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3RIF8vV011983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Apr 2013 11:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367086521; bh=2XUxpeDKCwfgjvwvKqbHNE/Wv37WAXDKZRMfGHabaHQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kyt5JOjoTOPYkoQXPBiGY3u+qPYvpPw7WF19bC6tthbbaBdiXjOlfoWwIKCZsvwIo PzY+CNUCXxoPLR0TIF6lIdXmDD3kOAQzBHbPpRGWBnDd1dRmq3sWcoykLIDMbK1tWK Ky3sEFnKQkr6bgCGr8A1EzPT77uEXUPvYhnb0Lpw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367086521; i=@elandsys.com; bh=2XUxpeDKCwfgjvwvKqbHNE/Wv37WAXDKZRMfGHabaHQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=y3BHHlwgkmTFDQqof3e7UVif2uxcoI6O9pb5h2+VKgimyGmmgbSH7pHP6po9m021q jVicp0ApkcoNWwRJXEjKsb3fy8SD6tNCvpbuIjpDuSEJtdVVeeYiwwONTZLoYHVQHm Kwc/RNDXAVX46Zitt7osyD934r+ARf/3Wkbh4c94= Message-Id: <6.2.5.6.2.20130427102849.0c68df60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 27 Apr 2013 10:58:36 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <517BE999.1030800@isdg.net> References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <20130426232858.GV23770@besserwisser.org> <20130427012445.GO809@mx1.yitter.info> <20130427024401.4E3CE3314ABC@drugs.dv.isc.org> <20130427132835.GR809@mx1.yitter.info> <517BE999.1030800@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 27 Apr 2013 18:15:24 -0000 Hi Hector, At 08:07 27-04-2013, Hector Santos wrote: >AUTH-RES was kludged into SPFBIS. It is still not correct, changes >are still required There is a thread at http://www.ietf.org/mail-archive/web/spfbis/current/msg02259.html about the Authentication-Results: header field. >This problem is not being solved correctly and I am growing tired of >my own suggestions being ignored, so why not just ignored SPFBIS? There are two long threads at http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html and www.ietf.org/mail-archive/web/dnsext/current/msg13025.html 73 messages were posted on this thread yesterday. There were 21 messages the day before that. I am not ignoring your suggestions. There is an on-going discussion. >Just get Microsoft rep here to tell us why MS DNS v5.0+ do not >support and will not support unnamed type processing, and I will >finally throw up my own hands on this and perhaps even begin to >produce future TXT-based Domain Policy/Operations I-D proposals too. I sent an email to several implementers of RFC 4408 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03348.html ). I did not receive any reply (excluding implementers already on this mailing list). I cannot get anyone to participate in the WG discussions if they do not want to participate. Regards, S. Moonesamy (as document shepherd) From johnl@iecc.com Sat Apr 27 11:53: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 29E5221F980A for ; Sat, 27 Apr 2013 11:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.939 X-Spam-Level: X-Spam-Status: No, score=-110.939 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddNzUzYtOnU9 for ; Sat, 27 Apr 2013 11:53:24 -0700 (PDT) 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 49AC321F96F7 for ; Sat, 27 Apr 2013 11:53:24 -0700 (PDT) Received: (qmail 94196 invoked from network); 27 Apr 2013 18:53:23 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Apr 2013 18:53:23 -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; s=517c1ea3.xn--hew.k1304; i=johnl@user.iecc.com; bh=Y1cOSgpd6ZyvKEQrcsYqqnNpIMPI0XxuBmp8NrjO0dg=; b=la1n5Sm4OE1NAXN89HeKS0SMlfAOyCWnlCxJGVZkg+gZPeWOy/0n/e1jkiJe6THScwdWR70fMuOcLEjx8KbYvwYI+ydqxo40Zc3idvs+rJZRt49Hs84PJCprwNgV5Y8x7xLVfE5ZZdFD2ZzC549HnnaLN8Jrbrl+VdKtx0LnqoM= 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; s=517c1ea3.xn--hew.k1304; olt=johnl@user.iecc.com; bh=Y1cOSgpd6ZyvKEQrcsYqqnNpIMPI0XxuBmp8NrjO0dg=; b=kzDsHi05zIfEPCJtCkYX76Sn+2w5UtOi5ilqJc2Bg98g8doHC853ihIhxmRILO+IeAkv1pt5I7Ymk9UHq59XP5a1SCH5IuU9YgoNj53oNpOy4+Ly+oHraYj1oD0FmNevcGoIPtQxYbivZj/BMo1ju6wyilxOcQQ4l/WF/b9IuHc= Date: 27 Apr 2013 18:53:01 -0000 Message-ID: <20130427185301.28485.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] IPv4 mapped IPv6 addresses 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, 27 Apr 2013 18:53:25 -0000 >As I understand it, the idea is that a connection arriving via an >IPv6-mapped IPv4 address is supposed to be reported to the accepting >application as an IPv4 connection, so SPF would never know about the >"IPv6-mapped" part in the first place. It depends on the implementation. Here in FreeBSD land, the preferred way to listen to both IPv4 and IPv6 is to set up two sockets and listen to both, but you can also flip a kernel setting, listen on one IPv6 socket, and the IPv4 connections will show up in your application on mapped addresses. The current language on page 21 of the draft seems fine to me, at worst harmless, and addresses the real situation I described above. R's, John From Ted.Lemon@nominum.com Sat Apr 27 13:43: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 473FA21F96BC for ; Sat, 27 Apr 2013 13:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.426 X-Spam-Level: X-Spam-Status: No, score=-106.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY0QTO+xGRB7 for ; Sat, 27 Apr 2013 13:43:40 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 90BFA21F966A for ; Sat, 27 Apr 2013 13:43:33 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUXw4dV9roVXz+FT+IQLVMPYXt77tuhLs@postini.com; Sat, 27 Apr 2013 13:43:40 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 366641B8050 for ; Sat, 27 Apr 2013 13:43:33 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2AA7B190061; Sat, 27 Apr 2013 13:43:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sat, 27 Apr 2013 13:43:27 -0700 From: Ted Lemon To: Scott Kitterman Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQp6UBXubqTI8/ESMN/lsrU52YZjpS5qAgAAE9gCAAAxKgIAAAbKAgAABqICAAAMGAIAAATgAgAAAjoCAAAClAIAAAKcAgAADNwCAAAFigIABlPCA Date: Sat, 27 Apr 2013 20:43:26 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775163359@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <1904246.GKbtVlPDWo@scott-latitude-e6320> <8D23D4052ABE7A4490E77B1A012B630775160DFF@mbx-01.win.nominum.com> <1947641.qMtMBB5hPF@scott-latitude-e6320> In-Reply-To: <1947641.qMtMBB5hPF@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <8FE597879483894996F60C67E9408791@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 27 Apr 2013 20:43:41 -0000 On Fri, 26 Apr 2013 19:38:39 -0400, Scott Kitterman wr= ote: > Should, but they don't. For implementations that don't deal with type SP= F,=20 > SERVFAIL or no answer at all are the most common effects. So failure of = a type=20 > SPF query in one of these manners doesn't tell you anything about what wo= uld=20 > happen with a TXT query. Earlier I said that while I disagree with the working group's decision here= , I don't oppose it anymore. This statement is actually the tipping point= for me: I now understand why the working group made the decision it made, = I think it was the right decision, and I no longer disagree with it. Thanks for the explanation. You can pie me in Berlin. From WebMaster@Commerco.Net Sat Apr 27 14:32: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 98D8021F98BE for ; Sat, 27 Apr 2013 14:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79eVMq+c5TFO for ; Sat, 27 Apr 2013 14:32:55 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id DE5ED21F98A7 for ; Sat, 27 Apr 2013 14:32:54 -0700 (PDT) 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=N0e1L+Jn779RV8JaY19RHqyZ0874WXD+lCV1wzhS+9mmtBmp7mlssZK+ECq8Cr0rf3fKPnxDn4rUj9/R8QbOouwfVwBEWpZWN294ZJPTMNugl8GmP9aKx9DV5gsciAYTMPR3gYcYHV3g5trhoqlndwSMUaxvJ2PeKtlYWtu1hNg= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.6) with ESMTP (EHLO [10.240.241.49]); Sat, 27 Apr 2013 21:32:48 +0000 Message-ID: <517C43F2.8050200@Commerco.Net> Date: Sat, 27 Apr 2013 15:32:34 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130423145447.0c2cb770@elandnews.com> <20130424160954.GA31835@simplex.0x539.de> <517807E7.2050005@viagenie.ca> <1620648.vNPTWAe3vH@scott-latitude-e6320> <51780DCC.7020802@viagenie.ca> <517A5345.8090008@tana.it> <6.2.5.6.2.20130427072046.0b6a9f40@resistor.net> 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] IPv4 mapped IPv6 addresses 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, 27 Apr 2013 21:32:55 -0000 On 4/27/2013 10:11 AM, Murray S. Kucherawy wrote: > As I understand it, the idea is that a connection arriving via an > IPv6-mapped IPv4 address is supposed to be reported to the accepting > application as an IPv4 connection, so SPF would never know about the > "IPv6-mapped" part in the first place. Sort of. There is a defined area of around 4 billion addresses within the IPv6 space that directly one to one map back to the entire IPv4 space, which was limited by addresses that fit into an unsigned 32bit integer and kind of the reason why we ran out of the IPv4 address space to allocate. I think the point of the discussion is that SPF might get requests via IPv6 which talk to using A records in the IPv4 space (that 4 billion limitation thingy). IPv6 uses AAAA records to map the IPv6 addresses to the entire IPv6 name space. However, while the IPv4 space is a rather small area within the IPv6 space, for compatibility it would be rather important for IPv6 to be able to handle both A and AAAA records. SPF must also be able to handle the reality that too it might be dealing with A record requests (from/for either IPv4 or IPv6 connections) and AAAA record requests (exclusively from/for IPv6 connections). I think this is an attempt to acknowledge that SPF must incorporate the same kind of thinking as regards handling either A or AAAA records that the good people who handle DNS implementations have done to properly support the continuing migration from IPv4 to IPv6. Hope that helped. > > > On Sat, Apr 27, 2013 at 7:49 AM, S Moonesamy > wrote: > > At 03:13 26-04-2013, Alessandro Vesely wrote: > > It is not clear to me what underlying layer we'd refer to. The > kernel > obviously cannot do that if the socket is IPv6. > > > Tim Taylor suggested some text [1]. There is also some text from > Scott Kitterman [2]. Could someone please explain what this > "underlying layer" is? > > > Regards, > S. Moonesamy (as document shepherd) > > 1. > http://www.ietf.org/mail-__archive/web/spfbis/current/__msg03440.html > 2. > http://www.ietf.org/mail-__archive/web/spfbis/current/__msg03436.html > > _________________________________________________ Best, Alan M. From WebMaster@Commerco.Net Sat Apr 27 14:38: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 2D41921F9957 for ; Sat, 27 Apr 2013 14:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnibFSGQ4NCO for ; Sat, 27 Apr 2013 14:38:04 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8959A21F9910 for ; Sat, 27 Apr 2013 14:38:04 -0700 (PDT) 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=2tN4Zxrj+VdY4Z2+qByIuFE+fQRXbk8uN+WKC+JVA/EIr4rj+IWK4YbjuNbazqmM5jsd5ewPbwZ71w1OCvlXuHMaSacltbG9IBGtP19dT98ionG0DlOTa/nTiAxx1iD2A1bK342pzR8o9PB4G47o3xoFZdQDsaWQXLsw+TFlBX8= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.6) with ESMTP (EHLO [10.240.241.49]); Sat, 27 Apr 2013 21:38:03 +0000 Message-ID: <517C453A.4080406@Commerco.Net> Date: Sat, 27 Apr 2013 15:38:02 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130427185301.28485.qmail@joyce.lan> In-Reply-To: <20130427185301.28485.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: superuser@gmail.com, John Levine Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 27 Apr 2013 21:38:05 -0000 On 4/27/2013 12:53 PM, John Levine wrote: >> As I understand it, the idea is that a connection arriving via an >> IPv6-mapped IPv4 address is supposed to be reported to the accepting >> application as an IPv4 connection, so SPF would never know about the >> "IPv6-mapped" part in the first place. > > It depends on the implementation. Here in FreeBSD land, the preferred > way to listen to both IPv4 and IPv6 is to set up two sockets and > listen to both, but you can also flip a kernel setting, listen on one > IPv6 socket, and the IPv4 connections will show up in your application > on mapped addresses. > > The current language on page 21 of the draft seems fine to me, at > worst harmless, and addresses the real situation I described above. > > R's, > John +1 From SRS0=h/4cJ=OP==stuart@gathman.org Sat Apr 27 19:29: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 D951221F97CD for ; Sat, 27 Apr 2013 19:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Agec4JWwWHnf for ; Sat, 27 Apr 2013 19:29:48 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 2043421F97BE for ; Sat, 27 Apr 2013 19:29:48 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (PLAIN sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1367116202; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=FxHc+lFbohiZ8wvBjfuCFVg+1aOYoVuaxARbYW4rq80=; b=cT2CHrmzliTREZnGBHbKSIoXu6zFBsjoFiOQ18+IFyoA+NHSJJmSV1qaAlJ/FgfFglhiVs 4UX4RpBhjBrXwHJr7aIAIGpndUliC9EfJRV+6RzAoW3mqqC45lWphGSRSD3WA34RK3VU3K6d 3/ARV6hiW33+oxX5bRAZ9GnFaMGD4= Received: from silver.gathman.org ([IPv6:2001:470:8:809:bdb9:ea2a:5eda:50dd]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3S2TvQb001629 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 27 Apr 2013 22:30:02 -0400 Message-ID: <517C8994.2080102@gathman.org> Date: Sat, 27 Apr 2013 22:29:40 -0400 From: Stuart Gathman Organization: BWI Corporation User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> In-Reply-To: <4272263.gKzvRQiTlr@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 02:31:12 -0000 On 04/26/2013 06:52 PM, Scott Kitterman wrote: > I don't think this is a good idea, but I'll ask a couple of questions anyway. > > What's the appropriate response for SERVFAIL or no response at all (timeout) > on the type SPF query? > > Do you think it is in the scope of the charter language to add a 2119 MUST for > publishing type SPF when it's essentially unused? While the bis WG shouldn't be inventing, last night I thought of one idea to mitigate the widely deployed brain-dead DNS servers/firewalls (that time-out on unknown RRs): 1. When querying for SPF, if there is a timeout, the server is either dead, or the braindead variety. 2. So try a TXT query next. If that times out also, the server is dead. If that succeeds, then the server is the braindead variety. 3. So record the domain with the brain-dead server in a database cache with a TTL of at least 3 days, and don't try SPF with that domain again until the TTL expires. I will be implementing this myself in the next week or so. Should be very simple. As a bonus, said database cache provides a convenient list of brain-dead DNS servers, which can be massaged into a "hall of shame". From spf2@kitterman.com Sat Apr 27 20:42: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 511CB21F961A for ; Sat, 27 Apr 2013 20:42:13 -0700 (PDT) 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.065, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtFrEwF4hUPI for ; Sat, 27 Apr 2013 20:42:12 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8530021F9615 for ; Sat, 27 Apr 2013 20:42:12 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8C49120E40C7; Sat, 27 Apr 2013 23:42:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367120531; bh=1khZ44uT2Uugltby280A060bVU79/Su5eJCSGH476PI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hzbmA/Hyr8WC7iA1qZZvmzMJYlc8sQF/CrDsIbaFbT/VOaN3+8dOAbNvF877RUT7K yp1AzrWqZN2aWbc9YoF6x1PfUMAzVbsJjJMjpDHr28lmhBF/aIRAsekJp4jKYg2Tt5 DmkRVnlLD3510V9Ns8qSs1HSCTpzYXpHuwn1hmIo= 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 7583C20E4090; Sat, 27 Apr 2013 23:42:11 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 27 Apr 2013 23:42:10 -0400 Message-ID: <1457820.oICsLp4n8g@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <517C8994.2080102@gathman.org> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@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] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 03:42:13 -0000 On Saturday, April 27, 2013 10:29:40 PM Stuart Gathman wrote: > On 04/26/2013 06:52 PM, Scott Kitterman wrote: > > I don't think this is a good idea, but I'll ask a couple of questions > > anyway. > > > > What's the appropriate response for SERVFAIL or no response at all > > (timeout) on the type SPF query? > > > > Do you think it is in the scope of the charter language to add a 2119 MUST > > for publishing type SPF when it's essentially unused? > > While the bis WG shouldn't be inventing, last night I thought of one > idea to mitigate the widely deployed brain-dead DNS servers/firewalls > (that time-out on unknown RRs): > > 1. When querying for SPF, if there is a timeout, the server is either > dead, or the braindead variety. > 2. So try a TXT query next. If that times out also, the server is > dead. If that succeeds, then the server is the braindead variety. > 3. So record the domain with the brain-dead server in a database cache > with a TTL of at least 3 days, and don't try SPF with that domain again > until the TTL expires. > > I will be implementing this myself in the next week or so. Should be > very simple. > > As a bonus, said database cache provides a convenient list of brain-dead > DNS servers, which can be massaged into a "hall of shame". If we were keeping type SPF (99) in the protocol, something like that might be useful as a local mitigation of some of the brain damage, but it's not the kind of thing that could ever be standardized. Scott K From ajs@anvilwalrusden.com Sun Apr 28 05:18: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 41A4B21F8FEB for ; Sun, 28 Apr 2013 05:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL700XElh6h0 for ; Sun, 28 Apr 2013 05:18:29 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id CBEF921F8F0F for ; Sun, 28 Apr 2013 05:18:29 -0700 (PDT) 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 BB5038A031 for ; Sun, 28 Apr 2013 12:18:27 +0000 (UTC) Date: Sun, 28 Apr 2013 08:18:23 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130428121807.GA11568@mx1.yitter.info> References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <517C8994.2080102@gathman.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 12:18:30 -0000 No hat. On Sat, Apr 27, 2013 at 10:29:40PM -0400, Stuart Gathman wrote: > I will be implementing this myself in the next week or so. Should > be very simple. I believe it was Mencken who said, "For every complex problem there is an answer that is clear, simple, and wrong." Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From hsantos@isdg.net Sun Apr 28 06:08: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 84A8021F8E6C for ; Sun, 28 Apr 2013 06:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTY9A2gbzHa4 for ; Sun, 28 Apr 2013 06:08:50 -0700 (PDT) Received: from secure.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EA2BC21F86EB for ; Sun, 28 Apr 2013 06:08:49 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=986; t=1367154522; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=NV9bFmZ 6R4QNGbrDBO2Ww5SRn7c=; b=j2H8X6MytQdJLf8rk09Or53MBBYHC3McpMM476x ebsZC8aHSaM2KYrEJLbx0uICJR57QdnRPLFJkqMbLRcihFYqGLVnPbwFAoMtSgN7 En0eboRspzKGTDyK6+CiwK6wy1N8ZJ8w2cGt0gKiGg4DjXEa+CEDpvv2t74bbvJL CnoM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 28 Apr 2013 09:08:42 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1653241532.4028.956; Sun, 28 Apr 2013 09:08:41 -0400 Message-ID: <517D1F06.2080109@isdg.net> Date: Sun, 28 Apr 2013 09:07:18 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <20130428121807.GA11568@mx1.yitter.info> In-Reply-To: <20130428121807.GA11568@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 13:08:51 -0000 But this isn't a complex problem. It is a simple solution. The goal is for the docs to described what DEVELOPERS need to do, or should do, to prepare for the "Future." o Select method of SPF lookups (_) SPF RRTYPE only (*) TXT RRTYPE only (_) BOTH (SPF/TXT) Protocol Options are always part of the design game. The only real problem, is that we currently do not have any control over this future (DNS Servers supporting unnamed type processing). There is seriously a lack of communications going on. Where are these DNS vendors? Who are the key folks who have some "control" over this future? On 4/28/2013 8:18 AM, Andrew Sullivan wrote: > No hat. > > On Sat, Apr 27, 2013 at 10:29:40PM -0400, Stuart Gathman wrote: > >> I will be implementing this myself in the next week or so. Should >> be very simple. > > I believe it was Mencken who said, "For every complex problem there is > an answer that is clear, simple, and wrong." > > Best, > > A > From hsantos@isdg.net Sun Apr 28 06:50: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 3E8BE21F987D for ; Sun, 28 Apr 2013 06:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orPdXqrwaTFB for ; Sun, 28 Apr 2013 06:50:03 -0700 (PDT) Received: from secure.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F06C721F9821 for ; Sun, 28 Apr 2013 06:50:01 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2098; t=1367156996; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=x24nGze f8W0KwMewy+T8Px6Gdko=; b=O3wMG+uJELLqifBwjmkjCnUuwY3uvIaxhqUbADc B2aXO5qhQk7RXKYHIXdnQseVTUGSGs+LTNWIpfsOvGhxQYm01Lju93lN8Ehy6asr AsS5aSMWOf8MvM3B6DXpdsRbo7SXKc7SCCziYREZf4bsbYiZtF46mNNI6BI0FLNh D1Kc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 28 Apr 2013 09:49:56 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1655715817.4028.5192; Sun, 28 Apr 2013 09:49:56 -0400 Message-ID: <517D28B1.1050401@isdg.net> Date: Sun, 28 Apr 2013 09:48:33 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org, "dnsext@ietf.org Group" References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <20130428121807.GA11568@mx1.yitter.info> <517D1F06.2080109@isdg.net> In-Reply-To: <517D1F06.2080109@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 13:50:03 -0000 I would like to suggest before eliminating (deprecating) SPF RRTYPE, in SPFBIS, the SPFBIS/DNS key cogs find out from the DNS vendors (or whoever manages/codes the main infrastructure DNS servers) why they are not supporting unnamed type processing? Are they even aware of this need? I believe BIND supports it, but not Microsoft DNS server. How about others? Are they all/mostly based on Bind source code? I tried to find out last March 2012 in the Microsoft Windows Server Tech Forum [1] if Microsoft DNS v5.0 supported RFC3597 [2] or unnamed type processing, and it wasn't known or I just didn't reach the right folks. It was surprising that not even Ace Fakey was not aware of this need. -- HLS [1] http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/5841e884-db22-42a1-8530-615a375662cc/ [2] http://tools.ietf.org/html/rfc3597 On 4/28/2013 9:07 AM, Hector Santos wrote: > But this isn't a complex problem. It is a simple solution. The goal is > for the docs to described what DEVELOPERS need to do, or should do, to > prepare for the "Future." > > o Select method of SPF lookups > (_) SPF RRTYPE only > (*) TXT RRTYPE only > (_) BOTH (SPF/TXT) > > Protocol Options are always part of the design game. > > The only real problem, is that we currently do not have any control over > this future (DNS Servers supporting unnamed type processing). There is > seriously a lack of communications going on. Where are these DNS > vendors? Who are the key folks who have some "control" over this future? > > > On 4/28/2013 8:18 AM, Andrew Sullivan wrote: >> No hat. >> >> On Sat, Apr 27, 2013 at 10:29:40PM -0400, Stuart Gathman wrote: >> >>> I will be implementing this myself in the next week or so. Should >>> be very simple. >> >> I believe it was Mencken who said, "For every complex problem there is >> an answer that is clear, simple, and wrong." >> >> Best, >> >> A >> > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From sm@elandsys.com Sun Apr 28 08:10: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 D1F6721F9A26 for ; Sun, 28 Apr 2013 08:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhJeUKnzOPC1 for ; Sun, 28 Apr 2013 08:10:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5156421F9A20 for ; Sun, 28 Apr 2013 08:09:56 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.228]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3SF9gVF009565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Apr 2013 08:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367161795; bh=VCoaujF72rwW6X59wUbwGQPIA0ZGKoWxX0zQIu94XCU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Zj48n11O1qUj7XDwepfpAg1BppRynfgc7npZ8ZuLvcOn4HmxPd7mJ8U7cwQOWAV7D NwFLZde+ChyGvDR/QK1E99B7cB/ZzbslqtICQq6YbPA4BTAnFMc02pYvqghEJDuEXB Nz2h0IY372LO589+REHtFg66PZQwYXPmLQi7XAh8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367161795; i=@elandsys.com; bh=VCoaujF72rwW6X59wUbwGQPIA0ZGKoWxX0zQIu94XCU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=op+Wo6EHfk0rHv7BMMueTSGVQtxA0xvCQl5IwbIQeuR/WRXIBuAGEt1zY854u0D9i nYk32pU2s7Zsg0o5bDdYoSppdimBIhrHcDbckwFpLz2dceH5jgxCHU7d4doH/ALEFE TO+8/gYAUyB4JSANs5vMGleBtcGjHdHRoWC/miV8= Message-Id: <6.2.5.6.2.20130428072546.0b5b2778@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 28 Apr 2013 08:06:43 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <517D28B1.1050401@isdg.net> References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <20130428121807.GA11568@mx1.yitter.info> <517D1F06.2080109@isdg.net> <517D28B1.1050401@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 15:10:03 -0000 Hi Hector, At 06:48 28-04-2013, Hector Santos wrote: >I would like to suggest before eliminating (deprecating) SPF RRTYPE, >in SPFBIS, the SPFBIS/DNS key cogs find out from the DNS vendors (or >whoever manages/codes the main infrastructure DNS servers) why they >are not supporting unnamed type processing? Are they even aware of >this need? I believe BIND supports it, but not Microsoft DNS >server. How about others? Are they all/mostly based on Bind source code? The other DNS implementations I know about are not based on the BIND source code. There is some information in the slides at www.ietf.org/proceedings/64/slides/protut-0/protut-0.ppt Regards, S. Moonesamy From spf2@kitterman.com Sun Apr 28 08:36: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 C740F21F9CED for ; Sun, 28 Apr 2013 08:36:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1lzkrUCY1e2 for ; Sun, 28 Apr 2013 08:36:40 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1372721F9CEC for ; Sun, 28 Apr 2013 08:36:39 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0196F20E4116; Sun, 28 Apr 2013 11:36:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367163399; bh=pKFAi2yD9NL0QxBI4rbKWt55Zm+5gHQbb0gHtdi5MnU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UypjskU9z+a7xYHT4IJcvPuHBgOEMqE/Hj/14F6u04wjuPCj3f2uZHpH7pu9+9meT nD9AUwAr/6mdRmLveb2hD4oPXovEJrZABOqruybV9B3chiWcI/JhdhksTRHaFA5QB0 H5l5Y3QhXSJqURlK7vanVPu3L+vFeNc8sQvXlH3U= 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 DE6A220E40F0; Sun, 28 Apr 2013 11:36:38 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 28 Apr 2013 11:36:37 -0400 Message-ID: <1577225.cSozvUzS0R@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130428072546.0b5b2778@resistor.net> References: <20130425013317.36729.qmail@joyce.lan> <517D28B1.1050401@isdg.net> <6.2.5.6.2.20130428072546.0b5b2778@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] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 15:36:40 -0000 On Sunday, April 28, 2013 08:06:43 AM S Moonesamy wrote: > Hi Hector, > > At 06:48 28-04-2013, Hector Santos wrote: > >I would like to suggest before eliminating (deprecating) SPF RRTYPE, > >in SPFBIS, the SPFBIS/DNS key cogs find out from the DNS vendors (or > >whoever manages/codes the main infrastructure DNS servers) why they > >are not supporting unnamed type processing? Are they even aware of > >this need? I believe BIND supports it, but not Microsoft DNS > >server. How about others? Are they all/mostly based on Bind source code? > > The other DNS implementations I know about are not based on the BIND > source code. There is some information in the slides at > www.ietf.org/proceedings/64/slides/protut-0/protut-0.ppt Good to know that the operational problems with new RR types were all solved in 2005 so everything we think we've seen go wrong since is just our imagination. Scott K From hsantos@isdg.net Sun Apr 28 09:19: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 DDA6821F8E7E for ; Sun, 28 Apr 2013 09:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4skNZD95DcL for ; Sun, 28 Apr 2013 09:19:00 -0700 (PDT) Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A84F121F8ECE for ; Sun, 28 Apr 2013 09:19:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1255; t=1367165935; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=UKt4vd1 H+XqNLkrajryjc7rmrz0=; b=csQd292TPwqJQAsTRPDxqyo1m0+bHfElmnQLR+Q v9g+cmSRP8ilSONCg77/tJFx0cGOZlnoDAP+ejGb+Qrd60Q8oslwg5z0yK5OPFyq JenJDS5D6O6rw/X3M63FUxLBPrw3/856QDkr3s7+ULkk2dxGEGCOr9Ht/LFhloEp O0Bs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 28 Apr 2013 12:18:55 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1664654331.4028.4932; Sun, 28 Apr 2013 12:18:54 -0400 Message-ID: <517D4B9B.1080208@isdg.net> Date: Sun, 28 Apr 2013 12:17:31 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: S Moonesamy References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <20130428121807.GA11568@mx1.yitter.info> <517D1F06.2080109@isdg.net> <517D28B1.1050401@isdg.net> <6.2.5.6.2.20130428072546.0b5b2778@resistor.net> In-Reply-To: <6.2.5.6.2.20130428072546.0b5b2778@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 16:19:02 -0000 For those who don't have a PPT viewer on their com-putt-er, there is a web view of these slides: https://docs.google.com/presentation/d/1V6slr2VyCUxSzJU2M1yidxrGjv85pK7rCrKmstMbMsM/pub?start=false&loop=false Can you surmise what these slides say in regards to the key issues or dearth preventing SPF RRTYPE development? -- HLS On 4/28/2013 11:06 AM, S Moonesamy wrote: > Hi Hector, > At 06:48 28-04-2013, Hector Santos wrote: >> I would like to suggest before eliminating (deprecating) SPF RRTYPE, >> in SPFBIS, the SPFBIS/DNS key cogs find out from the DNS vendors (or >> whoever manages/codes the main infrastructure DNS servers) why they >> are not supporting unnamed type processing? Are they even aware of >> this need? I believe BIND supports it, but not Microsoft DNS server. >> How about others? Are they all/mostly based on Bind source code? > > The other DNS implementations I know about are not based on the BIND > source code. There is some information in the slides at > www.ietf.org/proceedings/64/slides/protut-0/protut-0.ppt > > Regards, > S. Moonesamy > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From sm@elandsys.com Sun Apr 28 10:12: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 DA41421F99A4 for ; Sun, 28 Apr 2013 10:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cm9Ii+hFhE30 for ; Sun, 28 Apr 2013 10:12:27 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB6D21F999F for ; Sun, 28 Apr 2013 10:12:27 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.228]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3SHCECY012952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Apr 2013 10:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367169145; bh=m1m82k7/jz53j+PtYQ3geDD9If9PSzfCr/amCkLhyJM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LDJ2LeXV2qT4NUEteSmu86t8TMjOjVte8f0J8kz8LqJJMQN3wvL41LEySynkQTpKT uSReeXuKQWPDeBOEJv2smKBa4wqZSxFAV2VOOh1fel1RzCir6kCJQam76+0FWdpsIN eHGNSV+Q1yk7WLEZewtuejQiMGiotj459aF91V20= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367169145; i=@elandsys.com; bh=m1m82k7/jz53j+PtYQ3geDD9If9PSzfCr/amCkLhyJM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oG4aDb4Awr51Quod6ff0jdmRrGv7q4Qvrj1oXzACMLSGz2h1BRtg44xcLe/S1Lz5D IBG1gGPmN4GNsG1DmnhG3aZW7YL8rNm7kNF154vo7wztgbQwDtGjI+8BpGNaX8kx43 h3FZfSx8V41yTwYrudPMotu4x7T6TAbiFYPFX130= Message-Id: <6.2.5.6.2.20130428092412.0bdfb028@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 28 Apr 2013 09:40:00 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <517D4B9B.1080208@isdg.net> References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <20130428121807.GA11568@mx1.yitter.info> <517D1F06.2080109@isdg.net> <517D28B1.1050401@isdg.net> <6.2.5.6.2.20130428072546.0b5b2778@resistor.net> <517D4B9B.1080208@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 17:12:30 -0000 Hi Hector, At 09:17 28-04-2013, Hector Santos wrote: >Can you surmise what these slides say in regards to the key issues >or dearth preventing SPF RRTYPE development? There is a slide that mentions some DNS implementations. It's not up-to-date information though. Somebody will have to go through all that and do further research. The slides do not mention the SPF RRTYPE. There isn't any new information in them. I will have to go through the SPFBIS mail archives again to be able to comment. I will also have to discuss the entire matter with Andrew first. My focus at the moment is to read the messages being posted to see whether there is any new information I may have missed. Regards, S. Moonesamy From superuser@gmail.com Sun Apr 28 10:42: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 DE86F21F9A92 for ; Sun, 28 Apr 2013 10:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSedc-VQiXZ8 for ; Sun, 28 Apr 2013 10:42:17 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACFD21F9C4A for ; Sun, 28 Apr 2013 10:42:16 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b12so3166846wgh.30 for ; Sun, 28 Apr 2013 10:42:16 -0700 (PDT) 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=2SI1LuqrpU99YnIZ0AWMKgCzFDpRERqMyr9O9+xl4D0=; b=E5Qo5fIpfimJKn5vy4NOME8fvA5HDSxzVT42aXJLs5Yo4w5HQ5gtmi4JnSdoXV0gpr jK/pjSFCahGXEbB6ESjRZE5MsTwxGf1w0oip49kuHCBK5zusq54q1xYCwb93X+Y3OpGb 8YDTvVK4Oj1LApt6fBWvKGq6bg2N/gqzZ5F6BCA8ZBHh86oa2Fz3rLQfo2as1ilP1ET9 VQphE6c1c6yODJRmiWpWerrSaMZINIJtjrhe3znGa3OCLmzMKnFIYdR6xuXCIjdKnJaz Pom2goDMqhg9mOrqK2bXW2n3FJPGmoPMUfnaxobT2iHjaWBR3gZGlrgTRheBCplRhajk HxBg== MIME-Version: 1.0 X-Received: by 10.180.92.229 with SMTP id cp5mr13260495wib.20.1367170936140; Sun, 28 Apr 2013 10:42:16 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sun, 28 Apr 2013 10:42:15 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130428072546.0b5b2778@resistor.net> References: <20130425013317.36729.qmail@joyce.lan> <20130426220717.GI809@mx1.yitter.info> <20130426224519.GU23770@besserwisser.org> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <20130428121807.GA11568@mx1.yitter.info> <517D1F06.2080109@isdg.net> <517D28B1.1050401@isdg.net> <6.2.5.6.2.20130428072546.0b5b2778@resistor.net> Date: Sun, 28 Apr 2013 10:42:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d043c094efef97904db6f4926 Cc: "spfbis@ietf.org" , Hector Santos Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 17:42:18 -0000 --f46d043c094efef97904db6f4926 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 28, 2013 at 8:06 AM, S Moonesamy wrote: > At 06:48 28-04-2013, Hector Santos wrote: > >> I would like to suggest before eliminating (deprecating) SPF RRTYPE, in >> SPFBIS, the SPFBIS/DNS key cogs find out from the DNS vendors (or whoever >> manages/codes the main infrastructure DNS servers) why they are not >> supporting unnamed type processing? Are they even aware of this need? I >> believe BIND supports it, but not Microsoft DNS server. How about others? >> Are they all/mostly based on Bind source code? >> > > The other DNS implementations I know about are not based on the BIND > source code. There is some information in the slides at > www.ietf.org/proceedings/64/slides/protut-0/protut-0.ppt > I don't think anyone is saying DNS servers are the main problem anymore. Rather, it's firewalls, packet filters, and DNS-related UIs that aren't accommodating to anything other than the basic types. The RFC6686 experiments showed that these issues are still out there. -MSK --f46d043c094efef97904db6f4926 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 28, 2013 at 8:06 AM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
At 06:48 28-04-2013, Hector Santos wrote:
I would like to suggest before eliminating (deprecating) SPF RRTYPE, in SPF= BIS, the SPFBIS/DNS key cogs find out from the DNS vendors (or whoever mana= ges/codes the main infrastructure DNS servers) why they are not supporting = unnamed type processing? =A0Are they even aware of this need? =A0I believe = BIND supports it, but not Microsoft DNS server. =A0How about others? =A0Are= they all/mostly based on Bind source code?

The other DNS implementations I know about are not based on the BIND source= code. =A0There is some information in the slides at www= .ietf.org/proceedings/64/slides/protut-0/protut-0.ppt

I don't think anyone is saying DNS ser= vers are the main problem anymore.=A0 Rather, it's firewalls, packet fi= lters, and DNS-related UIs that aren't accommodating to anything other = than the basic types.=A0 The RFC6686 experiments showed that these issues a= re still out there.

-MSK
--f46d043c094efef97904db6f4926-- From superuser@gmail.com Sun Apr 28 10:44: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 D91ED21F9CE1 for ; Sun, 28 Apr 2013 10:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdBG5KAm2ELE for ; Sun, 28 Apr 2013 10:44:51 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFBE21F9C7F for ; Sun, 28 Apr 2013 10:44:51 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id t9so4315687wey.33 for ; Sun, 28 Apr 2013 10:44:50 -0700 (PDT) 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:cc :content-type; bh=GpUEirGcOHtI0VwSYUZzTXxYi7w3wA68iAhBQz4eOp8=; b=H33dT+H7FSM4bzfGAWtChBw+KveUJe54U/5c4RBncLMH0za9CWNCPf/syf+t93KWpW iBZNZ28OEKa9nbcu0RCqw6L7AD5jNmeczAZ9YXZHcoF4s5CG8Zy6qwLbZ3ApUfoLIROR RGIyczOqLR6yuAR8zdQb+7IpGwJxKeid1S++qwUwSy1TsKAF7lPj0A0Uj4fF8xnGh7D/ nlTsPtrbhSNF9QaQH1CLMF3x4bnEImLBHjZv4so0uMqe8GsPvrM8jHLSz8x2bEZBDuyh Y3A0vpdBdLGtF2OVT2GahvsiAzIORo9ctz8IQDaV97xIVoPdam4vN3R09G3/kutWElS+ 1nUQ== MIME-Version: 1.0 X-Received: by 10.194.222.100 with SMTP id ql4mr47946543wjc.59.1367171090302; Sun, 28 Apr 2013 10:44:50 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sun, 28 Apr 2013 10:44:50 -0700 (PDT) Date: Sun, 28 Apr 2013 10:44:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c1b9422f4c0604db6f53ce Cc: "spfbis@ietf.org" Subject: [spfbis] RFC6686 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, 28 Apr 2013 17:44:52 -0000 --001a11c1b9422f4c0604db6f53ce Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 27, 2013 at 6:28 AM, Andrew Sullivan wrote: > The > report in RFC 6686 (which is sketchy and, admittedly, based on a > possibly flawed study, but the only actual evidence we have) confirms > that prediction, I note. The only evidence we have of anyone querying > for TYPE 99 is of someone querying for TYPE 99 and TYPE 16 at the same > time, and presumably taking whatever the first answer to return is. > Can you elaborate on your analysis of RFC6686 a little more, please? -MSK --001a11c1b9422f4c0604db6f53ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 27, 2013 at 6:28 AM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
=A0 The
report in RFC 6686 (which is sketchy and, admittedly, based on a
possibly flawed study, but the only actual evidence we have) confirms
that prediction, I note. =A0The only evidence we have of anyone querying for TYPE 99 is of someone querying for TYPE 99 and TYPE 16 at the same
time, and presumably taking whatever the first answer to return is.

Can you elaborate on your analysis of RFC6686 = a little more, please?

-MSK
--001a11c1b9422f4c0604db6f53ce-- From johnl@iecc.com Sun Apr 28 11: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 7F7BA21F992F for ; Sun, 28 Apr 2013 11:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.982 X-Spam-Level: X-Spam-Status: No, score=-110.982 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gal1IOB1n2VD for ; Sun, 28 Apr 2013 11:34:01 -0700 (PDT) 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 8348921F9871 for ; Sun, 28 Apr 2013 11:34:01 -0700 (PDT) Received: (qmail 82977 invoked from network); 28 Apr 2013 18:34:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Apr 2013 18:34:00 -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; s=517d6b98.xn--30v786c.k1304; i=johnl@user.iecc.com; bh=q4Df/mnnLfIhliAoMUkbbWCWVCogv1KBoTFAOSEn6Ts=; b=pKFwMjhVVvp99WcQ5wpQpDelOt/yOhvc1av9nymk6wR5opfL5XgsLPkVAZ96xgg2WILETvCKeQE2d8ffgHiSs3egPhPCjbCzCE/lDloz4B8Fhbq7UBuEEAwXQWhmTOFtCMKAk0GG0L6Z+OcZIwzgFkAF9XZhXranWAcnxNise8w= 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; s=517d6b98.xn--30v786c.k1304; olt=johnl@user.iecc.com; bh=q4Df/mnnLfIhliAoMUkbbWCWVCogv1KBoTFAOSEn6Ts=; b=RC71T0oU4XebXGdsJVWXnKmsiwbd99SBo4wbBZInrYlCNR/Pf/Y2cJWxezcLk0rJ96sehxG/nq1cR9fLj59Ef4ym6N73w9uiCufeACMkUNBxVThXs69jF2ZzrYHyTUKsIxr223bjujvlcvxKnHTksEaeP7gj6zJS60uyMNSO98I= Date: 28 Apr 2013 18:33:38 -0000 Message-ID: <20130428183338.97350.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] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 18:34:02 -0000 >I don't think anyone is saying DNS servers are the main problem anymore. >Rather, it's firewalls, packet filters, and DNS-related UIs that aren't >accommodating to anything other than the basic types. The RFC6686 >experiments showed that these issues are still out there. More to the point, 4408 has a technical problem with SPF records, we debated at great length the various solutions, and decided that getting rid of type 99 was the least bad. I see no reason to revisit that decision, noting that the recent blast from dnsext raised no new issues and introduced no new facts (well, other than that Cloudflare seems to be able to provision type 99. Wahoo.) I also note that in the six years from 4408 to 6686, the number of type 99 records in the samples described went from zero to about 6000, while the number of TXT records went from something to 400,000. Even if the number of TXT records doesn't grow at all, at that rate it will take about 400 years for SPF to catch up. That's an awfully long time to wait. Heck, by then, we might even be using IPv6. R's, John From mansaxel@besserwisser.org Sun Apr 28 12:52: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 37B7121F9A36 for ; Sun, 28 Apr 2013 12:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDAGAtvn3+21 for ; Sun, 28 Apr 2013 12:52:36 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id 25E3821F9A37 for ; Sun, 28 Apr 2013 12:52:32 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 2C0A79E57; Sun, 28 Apr 2013 21:52:22 +0200 (CEST) Date: Sun, 28 Apr 2013 21:52:22 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Scott Kitterman Message-ID: <20130428195221.GA27654@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <1457820.oICsLp4n8g@scott-latitude-e6320> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 19:52:37 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Sat, Apr 27, 201= 3 at 11:42:10PM -0400 Quoting Scott Kitterman (spf2@kitterman.com): > If we were keeping type SPF (99) in the protocol, something like that mig= ht be=20 > useful as a local mitigation of some of the brain damage, but it's not th= e=20 > kind of thing that could ever be standardized. The fallback could be.=20 The problem with the last posted draft is that it completely fails to implement compatibility, just like 4408 did. Just it fails the other way around. (or so I'm guessing based on the TXT or death! crowd talk here.) There (much so because of a certain corporate email system tied very close to a certain feature-deficient name-server. ) is a large deployed base of kludgy TXT records out there, records that could be SPF data or a groceries list. Or a text-only dungeon game. Let's assume some of them are SPF records. We need to deal with them, and we need to deal with the issue of broken middleboxes and broken name servers. People probably will need to publish their grocery shopping lists in TXT in the future too. The method describe upthread could very well be what we need. I'd suggest that we satisfy the protocol purists in the ivory tower by MUST'ing Type 99 SPF, but also MUST'ing a fallback to the old and b0rkened TXT record, if certain criteria are met. Like SERVFAIL or timeout. But not, perhaps, NXDOMAIN.=20 Or maybe. I take great pride in and work a lot to avoid broken nameservers and middleboxes, which makes me less exposed to their ideosynchraises. Like a lot of us purists have written; we know how to deal with a very long tail of BIND 4 and Server 2008R2 boxes lacking even 10 year old features. This can be made to work. /reporting from the ivory tower=20 --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Used staples are good with SOY SAUCE! --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF9ffUACgkQ02/pMZDM1cUbeQCdE8+X2c5rCVIVDoxh2wNG3pbo X1sAnRYVYYT6ynIVJK0q7XsJQZF3I8s3 =M2j4 -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- From Ted.Lemon@nominum.com Sun Apr 28 13:39: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 CDD0521F9887 for ; Sun, 28 Apr 2013 13:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.684 X-Spam-Level: X-Spam-Status: No, score=-105.684 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RwnEAgKXoEJ for ; Sun, 28 Apr 2013 13:39:05 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 55B1721F9858 for ; Sun, 28 Apr 2013 13:39:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUX2I6PKNIufNt9knAHinU71cjk9vAxD/@postini.com; Sun, 28 Apr 2013 13:39:05 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AB62F1B80D8 for ; Sun, 28 Apr 2013 13:39:04 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9E35C190061; Sun, 28 Apr 2013 13:39:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Sun, 28 Apr 2013 13:38:58 -0700 From: Ted Lemon To: =?iso-8859-1?Q?M=E5ns_Nilsson?= Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQ7g8BXubqTI8/ESMN/lsrU52YZjrcqEAgAEPEgCAAA0EgA== Date: Sun, 28 Apr 2013 20:38:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> In-Reply-To: <20130428195221.GA27654@besserwisser.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 20:39:06 -0000 On Apr 28, 2013, at 3:52 PM, M=E5ns Nilsson wro= te: > I'd suggest that we satisfy the protocol purists in the ivory tower by > MUST'ing Type 99 SPF, but also MUST'ing a fallback to the old and b0rkene= d > TXT record, if certain criteria are met. Like SERVFAIL or timeout. But > not, perhaps, NXDOMAIN.=20 The goal of reaching consensus is not to satisfy group X or group Y, but to= come up with an answer that works well. Putting in kludges that do not f= ollow the spec because of other kludges that don't follow the spec doesn't = make the situation better; that's why I changed my mind about this. I'm not asking you to change your mind, but if you think the consensus is w= rong, you need to say why it is wrong, not what you think it should be. A= nd why it is wrong needs to be something other than "because it wouldn't be= what we'd do if we were designing from a clean slate," because that's not = the current situation. You should be arguing for something that works bet= ter in practice than what is being proposed; if you don't have a thing like= that, you don't have an argument. The fact that implementations currently are doing SPF and TXT queries in pa= rallel is actually a really good illustration of the problem. Think about= why they are doing that. Why aren't they doing what you propose above? = It would work, after all, for some value of work. From SRS0=h/4cJ=OP==stuart@gathman.org Sun Apr 28 16:06: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 6C5FD21F980B for ; Sun, 28 Apr 2013 16:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_43=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8B8E5vUkKhZ for ; Sun, 28 Apr 2013 16:06:54 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 67C3521F97D4 for ; Sun, 28 Apr 2013 16:06:54 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (PLAIN sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1367190429; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=rMwGIvEM44p4sSvqa6dCT37CZqMLlnZLV3GfTcRyDLw=; b=jEIvSHJcUhImK8KnWwOV/x7adWHlKPK1HCw9Gsvd02hWCtlURQhOSlCmOFeljHIw3nT+s0 NdISp86QwxrDzUPPi6ip6ONsZRh7TZUb2dEM9ptL5GLSIixzIeZTO+6Zasn1ayi0VJpdIPXV MCTdqEMoGowBbdMr3A93Eac9hrHPc= Received: from silver.gathman.org ([IPv6:2001:470:8:809:50f0:7607:2d8:5c5e]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3SN77rh005355 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 28 Apr 2013 19:07:09 -0400 Message-ID: <517DAB89.8000409@gathman.org> Date: Sun, 28 Apr 2013 19:06:49 -0400 From: Stuart Gathman Organization: BWI Corporation User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 23:06:55 -0000 On 04/28/2013 04:38 PM, Ted Lemon wrote: > On Apr 28, 2013, at 3:52 PM, Måns Nilsson wrote: >> I'd suggest that we satisfy the protocol purists in the ivory tower by >> MUST'ing Type 99 SPF, but also MUST'ing a fallback to the old and b0rkened >> TXT record, if certain criteria are met. Like SERVFAIL or timeout. But >> not, perhaps, NXDOMAIN. > The goal of reaching consensus is not to satisfy group X or group Y, but to come up with an answer that works well. Putting in kludges that do not follow the spec because of other kludges that don't follow the spec doesn't make the situation better; that's why I changed my mind about this. > > I'm not asking you to change your mind, but if you think the consensus is wrong, you need to say why it is wrong, not what you think it should be. And why it is wrong needs to be something other than "because it wouldn't be what we'd do if we were designing from a clean slate," because that's not the current situation. You should be arguing for something that works better in practice than what is being proposed; if you don't have a thing like that, you don't have an argument. > > The fact that implementations currently are doing SPF and TXT queries in parallel is actually a really good illustration of the problem. Think about why they are doing that. Why aren't they doing what you propose above? It would work, after all, for some value of work. > For this implementer, it was because I didn't think of it (until night before last), and apparently no one else did either. If I had thought of it (keeping track of known broken nameservers) back in 2005, it would have worked much better to try SPF first (except for known broken nameservers). It was just so much easier to try TXT first to get the mail flowing. I am kicking myself! From Ted.Lemon@nominum.com Sun Apr 28 16:25: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 B25A121F9839 for ; Sun, 28 Apr 2013 16:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.409 X-Spam-Level: X-Spam-Status: No, score=-106.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K18N2W+KN41A for ; Sun, 28 Apr 2013 16:25:58 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEEA21F8E7E for ; Sun, 28 Apr 2013 16:25:58 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUX2wBTBDgLjXhxoFfbhthMzM7FAw3xVC@postini.com; Sun, 28 Apr 2013 16:25:58 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B5E1E1B80F9 for ; Sun, 28 Apr 2013 16:25:57 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A5ACC190061; Sun, 28 Apr 2013 16:25:57 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Sun, 28 Apr 2013 16:26:02 -0700 From: Ted Lemon To: Stuart Gathman Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQ7g8BXubqTI8/ESMN/lsrU52YZjrcqEAgAEPEgCAAA0EgIAAKVGAgAAFVoA= Date: Sun, 28 Apr 2013 23:25:56 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> In-Reply-To: <517DAB89.8000409@gathman.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <684844713BE4F3419250F4FF51A3F107@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 28 Apr 2013 23:25:59 -0000 On Apr 28, 2013, at 7:06 PM, Stuart Gathman wrote: > For this implementer, it was because I didn't think of it (until night be= fore last), and apparently no one else did either. If I had thought of it = (keeping track of known broken nameservers) back in 2005, it would have wor= ked much better to try SPF first (except for known broken nameservers). It = was just so much easier to try TXT first to get the mail flowing. I am kic= king myself! So you don't mind keeping the state around for 90 seconds? From marka@isc.org Sun Apr 28 19:50: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 8BC7521F98D9 for ; Sun, 28 Apr 2013 19:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLOFlozPdEUT for ; Sun, 28 Apr 2013 19:50:28 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 722D021F9749 for ; Sun, 28 Apr 2013 19:50:25 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B763A5F9908; Mon, 29 Apr 2013 02:50:14 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367203824; bh=fncnbQl+4aKQ67hfXrvYPS5hLCOboK6fQM/IdNsj9uc=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=c0ASIt/zbLQy3pqUlVMLZ7TwWDgv6eXmm/PMtRz0nMqZZd09iEJgKQbbtCDZwVHDo bDC4+NxG8+oW6ZCAzbotZTRDvBsNs0SKBnXw+jCT4Z/VnulbGnIm6On8T4C3PTO/NQ EpJpgtNI6NMqfNEQSlmuFn/PjZRVnrkzSkWpN2W8= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:f089:9360:9986:7cea]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E719D216C43; Mon, 29 Apr 2013 02:50:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id A69473323956; Mon, 29 Apr 2013 12:49:17 +1000 (EST) To: "John Levine" From: Mark Andrews References: <20130428183338.97350.qmail@joyce.lan> In-reply-to: Your message of "28 Apr 2013 18:33:38 +0000." <20130428183338.97350.qmail@joyce.lan> Date: Mon, 29 Apr 2013 12:49:13 +1000 Message-Id: <20130429024917.A69473323956@drugs.dv.isc.org> Cc: spfbis@ietf.org, superuser@gmail.com Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 02:50:29 -0000 In message <20130428183338.97350.qmail@joyce.lan>, "John Levine" writes: > >I don't think anyone is saying DNS servers are the main problem anymore. > >Rather, it's firewalls, packet filters, and DNS-related UIs that aren't > >accommodating to anything other than the basic types. The RFC6686 > >experiments showed that these issues are still out there. > > More to the point, 4408 has a technical problem with SPF records, we > debated at great length the various solutions, and decided that > getting rid of type 99 was the least bad. I see no reason to revisit > that decision, noting that the recent blast from dnsext raised no new > issues and introduced no new facts (well, other than that Cloudflare > seems to be able to provision type 99. Wahoo.) > > I also note that in the six years from 4408 to 6686, the number of > type 99 records in the samples described went from zero to about 6000, > while the number of TXT records went from something to 400,000. Even > if the number of TXT records doesn't grow at all, at that rate it will > take about 400 years for SPF to catch up. ISC released BIND 9.4.0 which included SPF in Feb 2007, the first .0 released after RFC 4408 was published. Libspf2, with type SPF, support didn't come out until October 2008. No releases were made between Feb 2005 and October 2008[1]. The SPF camp complain about lack of type SPF record deployment yet they took over 2 years to release a library which supported type SPF when it was about a 10 minute fix to add support for it to the library. No effort was made to update documentation to say add both SPF and TXT records as far as I can see to bring it into line with RFC 4408. They then start measuring support before a hardware deprecation cycle has even completed. If I had known that there was going to be a survey about type SPF support so early in the transition process which I assumed would take 10 to 15 years or more to complete I would have added code to complain about missing SPF records. Now that you want to deprecate SPF I need to add code to tell those that have SPF records without TXT records that they need to add TXT records. Mark [1] http://www.libspf2.org/spf/. > That's an awfully long time to wait. Heck, by then, we might even be > using IPv6. > > R's, > John > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mansaxel@besserwisser.org Sun Apr 28 20:40: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 7EE7521F9832 for ; Sun, 28 Apr 2013 20:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.499 X-Spam-Level: * X-Spam-Status: No, score=1.499 tagged_above=-999 required=5 tests=[J_CHICKENPOX_16=0.6, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNB-oFini-4S for ; Sun, 28 Apr 2013 20:40:29 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7B621F9814 for ; Sun, 28 Apr 2013 20:40:28 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 589709E5B; Mon, 29 Apr 2013 05:40:27 +0200 (CEST) Date: Mon, 29 Apr 2013 05:40:27 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Ted Lemon Message-ID: <20130429034026.GB27654@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 03:40:30 -0000 --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Sun, Apr 28, 201= 3 at 08:38:58PM +0000 Quoting Ted Lemon (Ted.Lemon@nominum.com): > On Apr 28, 2013, at 3:52 PM, M=C3=A5ns Nilsson wrote: > > I'd suggest that we satisfy the protocol purists in the ivory tower by > > MUST'ing Type 99 SPF, but also MUST'ing a fallback to the old and b0rke= ned > > TXT record, if certain criteria are met. Like SERVFAIL or timeout. But > > not, perhaps, NXDOMAIN.=20 >=20 > The goal of reaching consensus is not to satisfy group X or group Y, but = to come up with an answer that works well. Putting in kludges that do not= follow the spec because of other kludges that don't follow the spec doesn'= t make the situation better; that's why I changed my mind about this. Ok, I've been reading too much ITU specs last week. Design by comittee is c= ontagious.=20 > I'm not asking you to change your mind, but if you think the consensus is= wrong, you need to say why it is wrong, not what you think it should be. = And why it is wrong needs to be something other than "because it wouldn't = be what we'd do if we were designing from a clean slate," because that's no= t the current situation. You should be arguing for something that works b= etter in practice than what is being proposed; if you don't have a thing li= ke that, you don't have an argument. >=20 > The fact that implementations currently are doing SPF and TXT queries in = parallel is actually a really good illustration of the problem. Think abo= ut why they are doing that. Why aren't they doing what you propose above?= It would work, after all, for some value of work. I think this problem stems from the failure of middle boxes and name servers (and to some extent full-service resolvers) to handle new record types. Especially one vendor in the name server case. I think Hector made a valid point; this will take time, and until broken devices are fixed, people will opt to use TXT, because it is the quicker fix. That does not mean we shouldn't fix it. It just means that while the mechanism and the potential were there for allocating new RR types, it was so infrequent that many believed it wouldn't happen. And we've got a lot of outdated=20 stuff to deal with. No wonder with DNS now being close to 30 years old.=20 =20 Remembering the Design by comittee statement from above, I still believe=20 that we need to handle this, and my suggestion is this, to preserve the=20 functionality people depend on today while limiting the long-run=20 damage to the DNS from parseable code in comments.=20 We should=20 * Mandate SPF/99. This is for the long run.=20 * For this specification we're doing now, _also_ mandate checking TXT,=20 if indicates that SPF RR is either not present or not reachable.=20 * The specification should allow entering TXT records, but should=20 state that their usage SHOULD be limited to damage control in the face of broken infrastructure.=20 * The specification could allow dual records to be entered, providing they tell the same story, to cater for other peoples broken infrastructure. * Subsequent versions of this standard could evolve, given the=20 evolution of middle boxes and name servers and resolvers into modern standards (like not more than 10 years old) and then=20 demote TXT gradually.=20 * Some effort needs to be made to come up with a decision logic to=20 discern between zone failure / TXT in lieu of SPF / path failure,=20 so as to recheck and/or abort properly and timely.=20 * The result of the above process might be expensive to achieve, why I think we should SHOULD a caching mechanism for scalability. Especially so since path failures often involve pathetic caching failure as well (caching or lack thereof in full-service resolvers, that is.) * To help with scalability, we might want to prescribe via SHOULD a longer TTL for records involved. This is bordering on ops, but might take a lot of load away. Even though I'm pretty certain 2x question rate is no major issue for most. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Eisenhower!! Your mimeograph machine upsets my stomach!! --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF966oACgkQ02/pMZDM1cWLsQCfYHI6jytCeZvR23KXdJkDHbul 1TUAniuWjWMibQWFdMTLAB/cGgNSbheP =VFoY -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5-- From spf2@kitterman.com Sun Apr 28 20:49: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 564F721F991C for ; Sun, 28 Apr 2013 20:49:51 -0700 (PDT) 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=[J_CHICKENPOX_16=0.6, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FE2IJ90wnNMD for ; Sun, 28 Apr 2013 20:49:50 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8F621F960E for ; Sun, 28 Apr 2013 20:49:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9606F20E4116; Sun, 28 Apr 2013 23:49:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367207389; bh=h4TcioB+iRig0ejWGPWELMl2lMEbZ4VCs30wM+KNg5E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Y0RN+mHp6BvXrrshhiEJwS2IoI4gmmsBcv8WWmrMIv6fTb26M2fcOyMCX8fxmy8hj Y1cWCBSDfAUwHtKoYEvhKymA9FZt/4q0RH5vQuss18ViE68TiJq4gg8LT5ZrfkZnCP dQvVXCnIN8moSgVdIV78eQwO0nlS/3xT4gLUq5+w= 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 45EAE20E40F0; Sun, 28 Apr 2013 23:49:48 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 28 Apr 2013 23:49:48 -0400 Message-ID: <3951802.crpRgfJC3o@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130429034026.GB27654@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <20130429034026.GB27654@besserwisser.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 03:49:51 -0000 On Monday, April 29, 2013 05:40:27 AM M=E5ns Nilsson wrote: > Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Sun, Apr 2= 8, 2013=20 at 08:38:58PM +0000 Quoting Ted Lemon (Ted.Lemon@nominum.com): > > On Apr 28, 2013, at 3:52 PM, M=E5ns Nilsson =20 wrote: > > > I'd suggest that we satisfy the protocol purists in the ivory tow= er by > > > MUST'ing Type 99 SPF, but also MUST'ing a fallback to the old and= > > > b0rkened > > > TXT record, if certain criteria are met. Like SERVFAIL or timeout= . But > > > not, perhaps, NXDOMAIN. > >=20 > > The goal of reaching consensus is not to satisfy group X or group Y= , but > > to come up with an answer that works well. Putting in kludges tha= t do > > not follow the spec because of other kludges that don't follow the = spec > > doesn't make the situation better; that's why I changed my mind abo= ut > > this. > Ok, I've been reading too much ITU specs last week. Design by comitte= e is > contagious. > > I'm not asking you to change your mind, but if you think the consen= sus is > > wrong, you need to say why it is wrong, not what you think it shoul= d be.=20 > > And why it is wrong needs to be something other than "because it > > wouldn't be what we'd do if we were designing from a clean slate," > > because that's not the current situation. You should be arguing f= or > > something that works better in practice than what is being proposed= ; if > > you don't have a thing like that, you don't have an argument. > >=20 > > The fact that implementations currently are doing SPF and TXT queri= es in > > parallel is actually a really good illustration of the problem. T= hink > > about why they are doing that. Why aren't they doing what you pro= pose > > above? It would work, after all, for some value of work. > I think this problem stems from the failure of middle boxes and name > servers (and to some extent full-service resolvers) to handle new rec= ord > types. Especially one vendor in the name server case. I think Hector = made > a valid point; this will take time, and until broken devices are fixe= d, > people will opt to use TXT, because it is the quicker fix. That does = not > mean we shouldn't fix it. It just means that while the mechanism and = the > potential were there for allocating new RR types, it was so infrequen= t > that many believed it wouldn't happen. And we've got a lot of outdate= d > stuff to deal with. No wonder with DNS now being close to 30 years ol= d. >=20 > Remembering the Design by comittee statement from above, I still beli= eve > that we need to handle this, and my suggestion is this, to preserve t= he > functionality people depend on today while limiting the long-run > damage to the DNS from parseable code in comments. >=20 > We should >=20 > * Mandate SPF/99. This is for the long run. >=20 > * For this specification we're doing now, _also_ mandate checking TXT= , > if indicates that SPF RR is either not present > or not reachable. >=20 > * The specification should allow entering TXT records, but should > state that their usage SHOULD be limited to damage control in the f= ace > of broken infrastructure. >=20 > * The specification could allow dual records to be entered, providing= they > tell the same story, to cater for other peoples broken infrastructu= re. >=20 > * Subsequent versions of this standard could evolve, given the > evolution of middle boxes and name servers and resolvers into > modern standards (like not more than 10 years old) and then > demote TXT gradually. >=20 > * Some effort needs to be made to come up with a decision logic to > discern between zone failure / TXT in lieu of SPF / path failure, > so as to recheck and/or abort properly and timely. >=20 > * The result of the above process might be expensive to achieve, > why I think we should SHOULD a caching mechanism for scalability. > Especially so since path failures often involve pathetic caching > failure as well (caching or lack thereof in full-service resolvers,= > that is.) >=20 > * To help with scalability, we might want to prescribe via SHOULD a > longer TTL for records involved. This is bordering on ops, but migh= t > take a lot of load away. Even though I'm pretty certain 2x question= > rate is no major issue for most. This is a broken proposal that would be harmful to interoperability if=20= implemented. The reasons why have been repeatedly explained in this th= read=20 and should be pretty obvious. Scott K From marka@isc.org Sun Apr 28 21:25: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 3CDA621F9985 for ; Sun, 28 Apr 2013 21:25:10 -0700 (PDT) X-Quarantine-ID: <24oOSxe+9bqR> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[AWL=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24oOSxe+9bqR for ; Sun, 28 Apr 2013 21:25:09 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 94FB221F997D for ; Sun, 28 Apr 2013 21:25:09 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 3B921C94B7; Mon, 29 Apr 2013 04:25:07 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367209509; bh=tkEfOXSUJZ9YgIIIQXYIf6KqVFW55ZS0sz0V8+tvbPE=; h=To:cc:Cc:From:References:Subject:In-reply-to:Date; b=crDDsqjln0Y4LiHDAGTlbd5pfGAYmIzQB1hv7oHA/T7tZ9qpogh30TTlVcz1MRKCP vApA88kOXxv25vRzCnjKIzX1EREhfGvpO/Dqmg2MJlU9pnXx4W1GUDPH3OVd2xBwwq fx5jIGfxKvoa5Q0j8/YDKyleBrv179z8uPRyZjgc= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Mon, 29 Apr 2013 04:25:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D19D6216C43; Mon, 29 Apr 2013 04:25:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5C15D3327201; Mon, 29 Apr 2013 14:24:57 +1000 (EST) To: "John R Levine" From: Mark Andrews References: <20130428183338.97350.qmail@joyce.lan> <20130429024917.A69473323956@drugs.dv.isc.org> In-reply-to: Your message of "28 Apr 2013 22:55:36 -0400." Date: Mon, 29 Apr 2013 14:24:57 +1000 Message-Id: <20130429042457.5C15D3327201@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org, superuser@gmail.com Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 04:25:10 -0000 In message , "John R Levine" writes: > > The SPF camp complain about lack of type SPF record deployment ... > > The message to which you replied, and which you quoted, pointed out that's > not the reason we're deprecating type 99. > > If you're not even going to read the messages you're replying to, I don't > see any point in wasting further time on this. Last time I looked at the definition of "technical reason" it didn't include "fail to spend money to upgrade equipment to be compatible with spec". > R's, > John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Sun Apr 28 22:02: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 4A67F21F9A14 for ; Sun, 28 Apr 2013 22:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.05 X-Spam-Level: * X-Spam-Status: No, score=1.05 tagged_above=-999 required=5 tests=[AWL=-1.050, J_CHICKENPOX_16=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHA8foGmjJg5 for ; Sun, 28 Apr 2013 22:02:56 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5315A21F99D8 for ; Sun, 28 Apr 2013 22:02:52 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id C99025F988D; Mon, 29 Apr 2013 05:02:41 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367211771; bh=crb7bORVF32LJBl7QTVKuGjdCpaPu3mUVRfUdQ/b6UQ=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=JyaoRmFMdrM3UdN3Upk5vJU9BapV57rZdXWZSUCRLlzm5jyP+xMiMDUSuaTPu+fQ4 bK/0ULA0kE0769Nb3t4lrVw8sklG9aMdOOH8w7XwuuQOf+oGpICRkaDbm9JGStT/bM ojqhnmsnZDxAb8ZhdcceiCk/Utoi5koFrndFvaDw= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B9C88216C40; Mon, 29 Apr 2013 05:02:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0B5DA3327423; Mon, 29 Apr 2013 15:02:36 +1000 (EST) To: =?utf-8?B?TcOlbnM=?= Nilsson From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <20130429034026.GB27654@besserwisser.org> In-reply-to: Your message of "Mon, 29 Apr 2013 05:40:27 +0200." <20130429034026.GB27654@besserwisser.org> Date: Mon, 29 Apr 2013 15:02:35 +1000 Message-Id: <20130429050236.0B5DA3327423@drugs.dv.isc.org> Cc: "spfbis@ietf.org" , Ted Lemon , Scott Kitterman Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 05:02:57 -0000 In message <20130429034026.GB27654@besserwisser.org>, =?utf-8?B?TcOlbnM=?= Nilsson writes: > > Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Sun, Apr 28, > 2013 at 08:38:58PM +0000 Quoting Ted Lemon (Ted.Lemon@nominum.com): > > On Apr 28, 2013, at 3:52 PM, MÃ¥ns Nilsson > > wrote: > > > I'd suggest that we satisfy the protocol purists in the ivory tower by > > > MUST'ing Type 99 SPF, but also MUST'ing a fallback to the old and > > > b0rkened > > > TXT record, if certain criteria are met. Like SERVFAIL or timeout. But > > > not, perhaps, NXDOMAIN. > > > > The goal of reaching consensus is not to satisfy group X or group Y, > > but to come up with an answer that works well. Putting in kludges that > > do not follow the spec because of other kludges that don't follow the > > spec doesn't make the situation better; that's why I changed my mind > > about this. > > Ok, I've been reading too much ITU specs last week. Design by comittee is > contagious. > > > I'm not asking you to change your mind, but if you think the consensus > > is wrong, you need to say why it is wrong, not what you think it should > > be. And why it is wrong needs to be something other than "because it > > wouldn't be what we'd do if we were designing from a clean slate," > > because that's not the current situation. You should be arguing for > > something that works better in practice than what is being proposed; if > > you don't have a thing like that, you don't have an argument. > > > > The fact that implementations currently are doing SPF and TXT queries > > in parallel is actually a really good illustration of the problem. > > Think about why they are doing that. Why aren't they doing what you > > propose above? It would work, after all, for some value of work. > > I think this problem stems from the failure of middle boxes and name > servers (and to some extent full-service resolvers) to handle new record > types. Especially one vendor in the name server case. I think Hector made > a valid point; this will take time, and until broken devices are fixed, > people will opt to use TXT, because it is the quicker fix. That does not > mean we shouldn't fix it. It just means that while the mechanism and the > potential were there for allocating new RR types, it was so infrequent > that many believed it wouldn't happen. And we've got a lot of outdated > stuff to deal with. No wonder with DNS now being close to 30 years old. New types have been added very year or so for the life of the DNS: Base spec 1987, RP 1990, X25 1990, ISDN 1990, RT 1990, AFSDB 1990, NSAP 1992, GPOS 1994, AAAA 1995, LOC 1996, SIG 1997, KEY 1997, NXT 1997, KX 1997, PX 1998, DNAME 1999, ATMA 2000, OPT 2001, APL 2001, DS 2003, DNSKEY 2004, RRSIG 2004, NSEC 2004, PSECKEY 2005, SSHFP 2006, CERT 2006, SPF 2006, DLV 2006, NSEC3 2008, NSEC3PARAM 2008, HIP 2008, URI 2011, TLSA 2012, NID 2012, L32 2012, L64 2012, EUI48 2013, EUI64 2013. Some of those record are infrequently used but others are wildly deployed and used including behind firewalls inspect DNS record contents. > Remembering the Design by comittee statement from above, I still believe > that we need to handle this, and my suggestion is this, to preserve the > functionality people depend on today while limiting the long-run > damage to the DNS from parseable code in comments. > > We should > > * Mandate SPF/99. This is for the long run. > > * For this specification we're doing now, _also_ mandate checking TXT, > if indicates that SPF RR is either not present > or not reachable. > > * The specification should allow entering TXT records, but should > state that their usage SHOULD be limited to damage control in the face > of broken infrastructure. > > * The specification could allow dual records to be entered, providing they > tell the same story, to cater for other peoples broken infrastructure. > > * Subsequent versions of this standard could evolve, given the > evolution of middle boxes and name servers and resolvers into > modern standards (like not more than 10 years old) and then > demote TXT gradually. > > * Some effort needs to be made to come up with a decision logic to > discern between zone failure / TXT in lieu of SPF / path failure, > so as to recheck and/or abort properly and timely. > > * The result of the above process might be expensive to achieve, > why I think we should SHOULD a caching mechanism for scalability. > Especially so since path failures often involve pathetic caching > failure as well (caching or lack thereof in full-service resolvers, > that is.) > > * To help with scalability, we might want to prescribe via SHOULD a > longer TTL for records involved. This is bordering on ops, but might > take a lot of load away. Even though I'm pretty certain 2x question > rate is no major issue for most. > > -- > M=C3=A5ns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > Eisenhower!! Your mimeograph machine upsets my stomach!! -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From superuser@gmail.com Mon Apr 29 01:21: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 6D8BA21F8523 for ; Mon, 29 Apr 2013 01:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLiELfxmjdJp for ; Mon, 29 Apr 2013 01:21:28 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id D5A5321F846C for ; Mon, 29 Apr 2013 01:21:25 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id t11so2016963wey.9 for ; Mon, 29 Apr 2013 01:21:25 -0700 (PDT) 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=lly1EnBvIAwemorQTCkqBcdHliDKWiee2791vbB6cG8=; b=kK5a+zgC9wiRgWx2O34CGpeDvES7pu1ggSD41ria1Kw3eUtd82X6+utrvweqKYDoQO zGIZP9aMICnjr0u6ZFkc4VRG/bxqOee3+dpV/6mEx9njAPi9gDzYblo7XKfL2tS5Udcn MOVrCD9aFuJehfjV3GvVV59GQc8I8CS4MbAA6O8j6Af/CDGLF13dDaeErV3M5+vNOhTd FyH0nd0APh+u/1DYCwwNyF5Mm19EFrRaPevsGnDA5RY2eCtkCCc7qJlPrKAkI6WZnl+l /b0qZJX1SQ5RrEV0cTae4fk72iby9iptCeuXKXNFtfDlJb+bz+1Oiy9BUoBNejfOANOy I+Og== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr8648557wjb.17.1367223682914; Mon, 29 Apr 2013 01:21:22 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 29 Apr 2013 01:21:22 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> Date: Mon, 29 Apr 2013 01:21:22 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7b5d8cfff2de4b04db7b9106 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 08:21:32 -0000 --047d7b5d8cfff2de4b04db7b9106 Content-Type: text/plain; charset=ISO-8859-1 Scott and I talked a bit about some of these points, and I thought it might help if I went through the whole thing and commented on it. I hope this is helpful. I've chopped out stuff where I have no specific response or opinion about the points made, so this is only a nearly-complete reply. On Tue, Apr 23, 2013 at 4:08 PM, S Moonesamy wrote: > In the Abstract: > > "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." > > ADMD should be expanded in the above. This was pointed out in a review > posted on August 26, 2012 [1]. > Agree. > In Section 2.1: > > 'It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" > identity, but also separately check the "HELO" identity by applying > the check_host() function (Section 4) to the "HELO" identity as the > .' > > As a note this "RECOMMENDED" is also in RFC 4408. > You made these notes throughout your review. I take it there's no action for the WG here; you are just auditing "out loud" what normative things in 4408bis were also present as-is in 4408, and which have changed. > 'Note that requirements for the domain presented in the EHLO or HELO > command are not always clear to the sending party, and SPF verifiers > MUST be prepared for the "HELO" identity to be malformed or an IP > address literal.' > > This RFC 2119 "MUST" is not in RFC 4408. It is a substantive change in my > opinion. > This was probably at my suggestion. The issue here is that RFC2119 doesn't say "must" has any different meaning than "MUST" does, so we should either be consistant and uppercase-ize it, or use some other word. In any event, I don't agree that this is actually a substantive change. > "This SPF check can only be performed when the "HELO" string is a > valid fully qualified domain." > > What is a valid fully qualified domain? > I believe it means "a name comprising a sequence of DNS labels, separated by dot characters, which when queried resolve to an A or MX record". It may have a proper definition in some other RFC too. Should we add one in the Introduction or Definitions? > In Section 2.3: > > "An SPF-compliant domain MUST have valid SPF records as described in > Section 3." > > As a note the RFC 4408 text is: > > "An SPF-compliant domain MUST publish a valid SPF record as described > in Section 3." > > The RFC 2119 MUST is redundant. > In a recent conversation, Pete described this as "not really wrong, but it's shouting." I guess that means changing "MUST publish" to "publishes" or something like that. > 'If domain owners choose to publish SPF records and want to support > receivers making negative authorization determinations, then they MUST > publish records that end in "-all", or redirect to other records that > do, > otherwise, no definitive determination of authorization can be made.' > > The document uses ADMD while there is "domain owners" in the above. I > suggest reviewing that. > I think they're synonymous. Going with ADMD is probably a good idea. > The RFC 2119 MUST is a substantive change. Why is this a MUST? > It is the only way within the protocol to cause negative authorization determinations to occur. It is an interoperability requirement. I believe this is correct. > In Section 2.4: > > 'At least the "MAIL FROM" identity MUST be checked, but it > is RECOMMENDED that the "HELO" identity also be checked beforehand.' > > There is already a RFC 2119 MUST in Section 2.2. There is also a RFC 2119 > RECOMMENDED in Section 2.1. The above text restates existing RFC 2119 > requirements or recommendations. > I agree; the redundancy should be resolved. The cited sentence in 2.4 can probably go. > 'Without explicit approval of the domain owner, checking other > identities against SPF version 1 records is NOT RECOMMENDED because > there are cases that are known to give incorrect results.' > > How should this explicit approval be sought? This recommendation does not > make sense. > Adding "out-of-band" or "private" after "explicit" would probably clear this one up. > In Section 2.4: > > 'When a mail receiver decides to perform an SPF check, it MUST use a > correctly-implemented check_host() function (Section 4) evaluated > with the correct parameters.' > > This RFC 2119 requirement states the obvious. It basically says that > there is a requirement in draft-ietf-spfbis-4408bis-14 to use a correct > implementation of draft-ietf-spfbis-4408bis-14. > I agree, that sentence can probably go. > "Implementations have to take care to correctly extract the > from the data given with the SMTP MAIL FROM command as many MTAs will > still accept such things as source routes ..." > > The definition of is: > > 'the domain portion of the "MAIL FROM" or "HELO" identity.' > > I am not sure whether it is even a definition. From an implementation > perspective the last paragraph of Section 2.4 is unclear. > I don't agree. I imagine by now you're aware of what this is for; can you suggest some other text that accomplishes the intent? > 'Performing the authorization other than using the return-path and > client address at the time of the MAIL command during the SMTP > transaction can cause problems, ..' > > Shouldn't that be "authorization check"? > Yes. > 'Generating non-delivery notifications to forged identities that have > failed the authorization check is a source of backscatter and SHOULD > be avoided.' > > This RFC 2119 SHOULD is not in RFC 4408. The above does not have anything > to do with Sender Policy Framework. It was mentioned during WG discussions > that "SPF can help the backscatter problem" [2]. This text may have been > introduced in response to a review [3]. Is this an enhancement or a > clarification? > I think it documents operational experience acquired since RFC4408 was published. As for whether RFC2119 language is appropriate, I agree that it isn't; it has nothing to do with SPF itself, though it is a side effect of its use. I suggest changing SHOULD to "needs to". > In Section 2.6: > > "An SPF verifier implements something semantically identical to the > function defined there." > > John Levine commented about this during the WGLC [4]. I am listing this > as a reminder for myself. > I agree with John. > In Section 2.6.1: > > 'A result of "none" means either (a) no syntactically valid DNS domain > name was extracted from the SMTP session that could be used as the > one to be authorized, or (b) no TXT records were retrieved from the > DNS that appeared to be intended for use by SPF verifiers.' > > I suggest "DNS TXT records". What is a syntactically valid DNS domain > name? The definition of "none" in RFC 4408 is clear (to me). > "DNS TXT records" is fine but probably not necessary at this point in the document. We discussed the "syntactically valid" thing above. This definition of "none" is more precise than it was in RFC4408. The 4408 definition was: A result of "None" means that no records were published by the domain or that no checkable sender domain could be determined from the given identity. The checking software cannot ascertain whether or not the client host is authorized. This text did not account for the notion that TXT records were returned that didn't start "v=spf1". It also wasn't clear about what "checkable" meant. I believe the bis definition is better. > In Section 2.6.2: > > 'The domain owner has explicitly stated that it is not asserting > whether the IP address is authorized. This result MUST be treated > exactly like the "none" result; the distinction exists only for > informational purposes.' > > As a note, the RFC 2119 MUST is in RFC 4408. The Introduction Section > mentions "ADMDs can authorize hosts to use their domain names". The above > uses "domain owner". > Covered earlier. > In Section 2.6.7: > > 'A "permerror" result means the domain's published records could not > be correctly interpreted. This signals an error condition that > definitely requires manual intervention to be resolved.' > > What is "manual intervention" in the above? > "Operator intervention" might be more consistent with common IETF usage. > In Section 3: > > 'An SPF record is a DNS record that declares which hosts are, and are > not, authorized to use a domain name for the "HELO" and "MAIL FROM" > identities.' > > How are hosts which are not authorized to use a domain name listed in a > SPF record? > It's implicit in that the set that is not authorized is the complement to the set that is authorized. If we want to make it clear, we could say "which hosts are, and thus also which are not," or something like that. > "The SPF record is a single string of text." > > What is a single string of text? It may be easier to state this in terms > of record format. > I don't think that statement is unclear, but I agree with the improvement suggestion. Maybe: "An SPF policy statement is expressed as a single string of text encoded in a DNS TXT record." > 'ADMDs publishing SPF records SHOULD try to keep the number of > "include" mechanisms and chained "redirect" modifiers to a minimum.' > > What is the minimum? Note that this RFC 2119 SHOULD is in RFC 4408. > There isn't a specific minimum. The expression means "don't use this technique unless you absolutely need it". > 'ADMDs SHOULD also try to minimize the amount of other DNS information > needed to evaluate a record.' > > This RFC 2119 SHOULD is also in RFC 4408. There are two RFC 2119 SHOULDs > in the last paragraph of Section 3. This usage of RFC 2119 key words does > not help the SPF "publisher". In my opinion the "SHOULD try" in this > context uses the RFC 2119 key word in unorthodox ways. > I agree with "SHOULD try", as that's arguably not actionable. "SHOULD minimize" is probably fine, however. > In Section 3.1: > > 'SPF records MUST be published as a DNS TXT (type 16) Resource Record > (RR) [RFC1035] only.' > > I would ask why "MUST be published ... only". By the way, Section 3 has a > reference to Section 4 for record format instead of Section 3.1. Is that > correct? > The text is not incorrect, but it's also not necessary. Dropping "only" is probably sufficient. The reference is indeed incorrect. > In Section 3.2: > > "A domain name MUST NOT have multiple records that would cause an > authorization check to select more than one record." > > This RFC 2119 MUST NOT was in RFC 4408. Is this to help the SPF > "publisher" and if so, how does it help? > I believe it is an advisory to publishers of the consequences of having more than one "v=spf1" record published. In Section 3.3: > > "As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS > record can be composed of more than one string." > > See previous comment about " a single string". > This use is correct, as it describes the fact that there are many ways to encode a single high-level string into multiple low-level "character-strings" as defined in RFC1035. > "If a published record contains multiple character-strings, then the > record MUST be treated as if those strings are concatenated together > without adding spaces." > > This RFC 2119 MUST is also in RFC 4408. I suggest removing the "MUST" in > the example. > I disagree. It's required for interoperability. > "TXT records containing multiple strings are useful in constructing > records that would exceed the 255-byte maximum length of a character- > string within a single TXT record." > > I suggest using "octet" instead of "byte". I'll point the working group > to CVE-2008-2469 in case it might wish to consider that issue. > How is an octet different from a byte in this context? This strikes me as a stylistic issue at best. > In Section 4: > > "A compliant SPF implementation MUST do something semantically > equivalent to > this description." > > It's unusual to see a "do something" RFC 2119 requirement in a > specification. Is the SPFBIS WG working on compliance for SPF > implementations? > RFC6376 is an example of a standards track document that uses RFC2119 MUST in this way. I'm sure I've seen others but I can't think of them at this hour. I think it's fine. "Mail receivers that perform this check MUST correctly evaluate the > check_host() function as described here." > > Where does "mail receivers" fit in the Sender Policy Framework? The "MUST > correctly evaluate" is stating the obvious. > I'm not understanding how the answer to the first question isn't obvious. I agree with the second point. > "Implementations MAY use a different algorithm than the canonical > algorithm defined here, so long as the results are the same in all > cases." > > Why is this a RFC 2119 MAY? I am aware that the text is in RFC 4408. > This seems to me to be another stylistic question, since MAY in RFC2119 terms doesn't mean much. > In Section 4.1: > > ' - the domain that provides the sought-after authorization > information; initially, the domain portion of the "MAIL > FROM" or "HELO" identity.' > > The above text is different from the text in Section 2.4. > I think I agree; I would prefer to have it defined in one place, and have other points in the document reference it. > In Section 4.3: > > "If the is malformed (e.g. label longer than 63 characters, > zero-length label not at the end, etc.)" > > That should be "octets". > Since the DNS is all in ASCII, they're synonymous. That said, we may as well be consistent. > "Properly formed domains are fully qualified email domains as > described in [RFC5321] Section 2.3.5." > > What are "properly qualified email domains"? > Is the reference defining that term not appropriate? > "Internationalized domain names MUST be encoded as A-labels, as > described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]." > > I'm listing the above and leave it to Area Director guidance. Please note > that it is a new RFC 2119 requirement. > I'm pretty sure RFC4408 pre-dates most of the IDN work, so this is a modernization step. I think it's important to include, and it also does the same thing DKIM did, which is now Draft Standard. If we don't, there's no guidance for use of SPF in the IDN context. The alternative is to spin up another document (which we're not chartered to do) that discusses use of SPF in the IDN context. > In Section 4.4: > > "In accordance with how the records are published (see Section 3 > above), a DNS query needs to be made for the name, querying > for type TXT only." > > I don't understand the sentence. > Query the HELO domain or the MAIL FROM domain, as described in Section 3. > 'Alternatively, for a server failure (RCODE 2) result, check_host() > MAY track failures and treat multiple failures within 24 hours for > the same domain as "permerror".' > > This text is not in RFC 4408. I found a note in Issue #1 [5] and in a > message [6]. > Are there any implementations that do this? If so, that's the justification; it's practical experience. If not, we should consider dropping it. > In Section 4.6.2: > > "If there are no more mechanisms, the result is specified in > Section 4.7." > > This sentence does not make sense. > How about: "After all mechanisms have been processed and no matches are found, the result is determined according to Section 4.7." "If this number is exceeded during a check, a permerror MUST be returned." > > I read this as if an implementation-specific limit is reached a permerror > is returned. There are two RFC 2119 MUST in the above. That can be > reduced to one MUST. > I'm not sure I agree. SecDir has pushed the fixed query limit on other topics in the past, which is the first MUST, and the second MUST prescribes a specific result that has to occur when the limit is reached which is important for interoperability. > 'MTAs or other processors SHOULD impose a limit on the maximum amount > of elapsed time to evaluate check_host(). Such a limit SHOULD allow > at least 20 seconds. If such a limit is exceeded, the result of > authorization SHOULD be "temperror".' > > There are three RFC 2119 SHOULDs in the above. I suggest rewriting the > text to reduce that. > All three of them seem to be important interoperability points. We could common factor the SHOULD and then present three bullets in a list, but the meaning is the same. > 'SPF implementations SHOULD limit "void lookups" to two.' > > What are void lookups? > Last paragraph of Section 4.6. > "In this case, a default of two is RECOMMENDED." > > Why is "two" recommended? > Interoperability; if one is two while another is 10, different SPF results can be returned. > 'Note that records SHOULD always use either a "redirect" modifier or > an "all" mechanism to explicitly terminate processing.' > > Why is there a RFC 2119 key word in a note? > Since the explanation I've been given is that it's better for human debugging, I think I agree since the advice is not specific to the protocol itself. > In Section 4.8: > > 'e.g., "foo..example.com") or overlong labels (more than 63 > characters).' > > I suggest octets. > Again, synonymous. > in Section 5: > > 'SPF implementations on IPv6 servers need to handle both "AAAA" and "A" > secords, for clients on IPv4 mapped IPv6 addresses [RFC4291].' > > There is a typo, "records". > > I'll flag the above for review by people with IPv6 expertise. > This was covered in a different thread. I believe a proposed text fix was made that people seemed to like. In Section 5.3: > > 'a = "a" [ ":" domain-spec ] [ dual-cidr-length ]' > > "dual-cidr-length" is introduced in this sub-section. I had to search > through the draft to find out what it means. > That happens sometimes. :-) > In Section 5.4: > > 'Note regarding implicit MXs: If the has no MX records, > check_host() MUST NOT pretend the target is its single MX, and MUST > NOT default to an A or AAAA lookup on the directly.' > > There are two RFC 2119 MUSTs in the above. This is over-usage of RFC 2119 > key words. This text was in RFC 4408. This is not a divergence from RFC > 5321, it is a contrary to Section 5 of RFC 5321. > I believe the advice should remain, but it could be simplified: "Note regarding implicit MXes: If the has no MX records, check_host() MUST NOT apply the implicit MX rules of RFC5321 by querying for an A record for the same name." In Section 5.5: > > "This mechanism SHOULD NOT be used." > > I suggest providing a reason for this. > The very next sentence is "See below for discussion." > "To prevent DoS attacks, more than 10 PTR names > MUST NOT be looked up during the evaluation of a "ptr" mechanism > (see Section 4.6.4)." > > The above restates a previous RFC 2119 MUST. > Agreed. > "If used, proper PTR records MUST be in place for the domain's hosts > and the "ptr" mechanism SHOULD be one of the last mechanisms checked." > > Those RFC 2119 key words are not in RFC 4408. I don't see how this RFC > 2119 change qualifies as a clarification or explanation. > It was "must" vs. MUST in RFC4408. It's otherwise unchanged. > "It is, however, still in use and part of the SPF protocol, so compliant > check_host() implementations MUST support it." > > What is a compliant check_host() implementation? > One that complies with this specification. > In Section 5.6: > > "ip6-network = " > > I suggest that the above reference be verified for correctness. > Looks right to me. The CIDR expression is in the optional token next to it, so this has to be just a plain IPv6 address, so that's the right reference. > In Section 5.7: > > 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{**d} -all' > > I'll flag this for review by DNS folks. > What's the specific question being asked of DNSDIR here? > In Section 6: > > 'The modifiers defined in this document ("redirect" and "exp") MAY > appear anywhere in the record, but SHOULD appear at the end, after > all mechanisms.' > > This text is in RFC 4408. I would label the RFC 2119 usage as defective. > Why? > In Section 6.2: > > "Since the explanation string is intended for an SMTP response and > [RFC5321] Section 2.4 says that responses are in [US-ASCII], the > explanation string MUST be limited to US-ASCII.' > > It would be easier to defer to RFC 5321 instead of setting a RFC 2119 > requirement in this draft. I note that this requirement was not in RFC > 4408. > I agree that this could be expressed non-normatively (e.g. "needs to be"). > "Software SHOULD make it clear that the explanation string > comes from a third party." > > I could not understand what that means in RFC 2119 terms. The draft uses > RFC 2119 key words by example instead of providing an explanation. > I agree; we're talking about interoperability between humans here, and not between implementations. > In Section 7.1: > > 'The "toplabel" construction is subject to the LDH rule plus > additional top-level domain (TLD) restrictions.' > > Where can I find these restrictions? Please note that I have read the > Informational RFC. > I'm pretty sure it's referring to common TLD conventions. In Section 7.3: > > "-exists:%(ir).sbl.spamhaus.**example.org > " > > I commented about vendor-neutral previously [8]. The above is a way to > get around the objection [9]. I suggest cleaning this up. > Sure. > "so trailing dots SHOULD NOT be published by domain owners" > > Why is it "domain owners"? > ADMDs is fine here. > "This macro SHOULD NOT be used. See Section 5.5 for the discussion > about why not." > > This comes out as a flippant explanation for the RFC 2119 SHOULD. > I think it's fine, though I suggest changing "the discussion about why not" to just "discussion". > "This SHOULD be a fully qualified domain name, but if one does not > exist (as when the checking is done by a MUA) or if policy restrictions > dictate otherwise, the word "unknown" SHOULD be substituted." > > The RFC 2119 key words are in RFC 2119. I don't know what to say. > I think that looks fine as-is, though we could change the first SHOULD to "ought to" because it's a transformation of other input and not an implementation choice. (And I assume you mean they were in RFC4408.) > "When the result of macro expansion is used in a domain name query, if > the expanded domain name exceeds 253 characters (the maximum length > of a domain name), the left side is truncated to fit, by removing > successive domain labels (and their following dots) until the total > length does not exceed 253 characters." > > Where is it specified that the maximum length of a domain name is 253 > characters? > RFC1035 says it's 255. "Care has to be taken by the sending ADMD so that macro expansion for > legitimate email does not exceed the 63-character limit on DNS labels." > > Where is that 63-character limit specified? > RFC1035, Section 2.3.1. > It is odd to have RFC 2119 requirements under a "Notes" heading. > Agreed. > In Section 8.2: > > 'A "neutral" result MUST be treated exactly like the "none" result; > the distinction exists only for informational purposes.' > > Why is an existing RFC 2119 restated? > Agreed. > In Section 8.5: > > "The domain owner believes the host is not authorized but is not willing > to make a strong policy statement." > > Why is it domain owner? > ADMD. > In Section 9.1: > > "The Received-SPF header field is a trace field (see [RFC5322] Section > 3.6.7) and SHOULD be prepended to the existing header, above the > Received: field that is generated by the SMTP receiver." > > "prepended to the existing header" does not sound right. > It's correct; "header" is the entire header block, while "header field" is one field in it. (Section 2.1 of RFC5322.) > "It MUST appear above all other Received-SPF fields in the message." > > How does this fit into the previous RFC 2119 SHOULD? > It SHOULD be prepended to the whole header block, but even if it isn't, it MUST appear above any other Received-SPF field. > in Section 10: > > "This section is not a "how-to" manual, or a "best practices" document, > and it is not a comprehensive list of what such entities SHOULD do in > light of this document." > > What is the meaning of the RFC 2119 SHOULD in the above? > Agreed, it's inappropriate here. > In Section 10.1.2: > > "Publishing SPF records for domains that send no mail is > a well established best practice." > > I am not aware of that best practice. I did a few DNS queries: > > ;; QUESTION SECTION: > ;bing.com. IN TXT > > ;; ANSWER SECTION: > bing.com. 3600 IN TXT "v=msv1 > t=6097A7EA-53F7-4028-BA76-**6869CB284C54" > > ;; QUESTION SECTION: > ;com.com. IN TXT > > ;; ANSWER SECTION: > com.com. 293 IN TXT "google-site-verification:** > esSnoZdChIkkfCfS9MMgqNhE0yaXfn**nZWdZPuBf7e8k" > What are you saying here? This is an existence proof of non-mailing domains that don't publish SPF records, but it doesn't contradict the statement made in the draft. > In Section 10.1.3: > > "SPF functionality is enhanced by administrators ensuring this > identity is set correctly and has an appropriate SPF record." > > How is SPF functionality enhanced? > When MAIL FROM is null, it's important that HELO be right in order to get any useful result from SPF. > In Section 10.2: > > "As stated elsewhere in this document, there is no normative requirement > for specific handling of a message based on any SPF result." > > The "as stated elsewhere" is vague. > Section 8 discusses it, if you're saying you'd like a specific reference. > 'The primary considerations are that SPF might return "pass" for mail > that is ultimately harmful (e.g., spammers that arrange for SPF to > pass using nonsense domain names' > > What are "nonsense" domain names? > "arbitrary", "discardable", something like that. > In Section 10.3: > > "The mediator can make the newly-posted message be as similar or as > different from the original message as they wish." > > The sentence seems incomplete, i.e. similar to what. > The original message. > "For the operation of SPF, the essential concern is the email > address in the 5321.MailFrom command for the new message." > > What does this mean? > In the context of mediators (which is the title of this subsection), the RFC5321.MailFrom field used by the mediator to inject a new message is the most important consideration. > 'Because SPF evaluation is based on the IP Address of the "last" > sending SMTP server, the address of the mediator will be used, rather > than the address of the SMTP server that sent the message to the > mediator.' > > I'll note that this is a mix of RFC 5321 and RFC 5598. The result is > clear or unclear depending on the background of the reader. > I think this is clear. You're familiar with the architecture here; what do you think would fix it? > In Section 11.5: > > "An SPF compliant receiver gathers information from the SMTP commands > it receives and from the published DNS records of the sending domain > holder" > > I suggest explaining the untrusted part. > Agreed. A second sentence indicating most of that input is unverified is probably in order, with references if possible. > In Section 11.6: > > "Checking SPF records causes DNS queries to be sent to the domain > owner." > > How are DNS queries sent to domain owners? > "to the ADMD infrastructure" > In Section 13.1: > > "The format of this type is identical to the TXT RR [RFC1035]" > > The format is not identical, i.e. it's a different RR. I suggest keeping > the IANA Considerations Section simple, i.e. clearly explain to IANA what > action is requested. > The format is indeed identical, right down to the octet. > References: > > Why is RFC 1123 a normative reference? > It defines the "%"-hack, of which implementers need to be aware (i.e., code needs to be able to handle that syntax). > Why is RFC 3864 a normative reference? > A BCP (e.g., a registration procedure) followed is always a normative reference, I believe. > Where can I find "Designated Mailers Protocol"? > > Where can I find "Domain-Authorized SMTP Mail"? > Agree, those need fixing. > ABNF: > > Did anyone verify the ABNF? > It's been some time but I did a full pass over it previously. > In Appendix C: > > In Section E.1: > > 'This would cause a lookup on an DNS white list (DNSWL) and cause a > result of "fail" only for email not either coming from the > domain's mx host(s) (SPF pass) or white listed sources (SPF > neutral).' > > I didn't find any discussion about this on the SPFBIS mailing list. is > there an explanation for this change between RFC 4408 and this draft? > It was in 9.3 in the previous document and has been reworded a little. It's otherwise unchanged. > In Appendix I: > > Appendix I is about "Protocol Status". This draft is intended as a > Proposed Standard. From an IETF perspective that is what it will be. > Describing it as something different can be misleading. > > "[RFC4408] was designed to clearly document the protocol defined by > earlier draft specifications of SPF as used in existing > implementations. This updated specification is intended to clarify > identified ambiguities in [RFC4408], resolve techincal issues > identified in post-RFC 4408 deplyment experience, and document widely > deployed extensions to SPF that have been developed since [RFC4408] > was published." > There are two typos in there (techincal, deplyment). > Extensions to the SPF protocol are clearly mentioned in the charter as > being out of scope. The "document widely deployed extensions" is > problematic. > Agreed. > "This document updates and replaces RFC 4408 that was part of a group > of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, > RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the > community observe the success or failure of the two approaches > documented in these RFCs during the two years following publication, > in order that a community consensus could be reached in the future." > > Why is this needed? The SPFBIS WG produced RFC 6686 to resolve the > experiment. > > "SPF is widely deployed by large and small email providers alike. > There are multiple, interoperable implementations." > > Someone might point out that this is marketing instead of text relevant to > a protocol. I'll mention that one or more significant issues (e.g. Issue > #9) was identified during the WG discussions. Issue #9 was not listed as > the errata. I suggest removing the section as it will be less text and > there is already two informative references to help the reader find > background information. > I propose leaving this stuff in there as information to the IESG. If they think it's unnecessary, they can ask that we remove it, or they can do so in a note to the RFC Editor. -MSK --047d7b5d8cfff2de4b04db7b9106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Scott and I talked a bit about some of these points, and I= thought it might help if I went through the whole thing and commented on i= t.=A0 I hope this is helpful.=A0 I've chopped out stuff where I have no= specific response or opinion about the points made, so this is only a near= ly-complete reply.

On Tue, Apr 23, 2013 at 4:08 PM, S Moonesamy <sm+ietf@ela= ndsys.com> wrote:
In the Abstract:

=A0 "This document describes version 1 of the Sender Policy Framework<= br> =A0 =A0(SPF) protocol, whereby an ADMD can explicitly authorize the hosts =A0 =A0that are allowed to use its domain names, and a receiving host can =A0 =A0check such authorization."

ADMD should be expanded in the above. =A0This was pointed out in a review p= osted on August 26, 2012 [1].

Agree.=A0
In Section 2.1:

=A0 'It is RECOMMENDED that SPF verifiers not only check the "MAIL= FROM"
=A0 =A0identity, but also separately check the "HELO" identity by= applying
=A0 =A0the check_host() function (Section 4) to the "HELO" identi= ty as the
=A0 =A0<sender>.'

As a note this "RECOMMENDED" is also in RFC 4408.

You made these notes throughout your review.=A0 I take= it there's no action for the WG here; you are just auditing "out = loud" what normative things in 4408bis were also present as-is in 4408= , and which have changed.
=A0
=A0=A0 'Note that requirements for the domain presented in the EHLO or = HELO
=A0 =A0 command are not always clear to the sending party, and SPF verifier= s
=A0 =A0 MUST be prepared for the "HELO" identity to be malformed = or an IP
=A0 =A0 address literal.'

This RFC 2119 "MUST" is not in RFC 4408. =A0It is a substantive c= hange in my opinion.

This was probably = at my suggestion.=A0 The issue here is that RFC2119 doesn't say "m= ust" has any different meaning than "MUST" does, so we shoul= d either be consistant and uppercase-ize it, or use some other word.

In any event, I don't agree that this is actually a subs= tantive change.
=A0
=A0 "This SPF check can only be performed when the "HELO" st= ring is a
=A0 =A0valid fully qualified domain."

What is a valid fully qualified domain?

I believe it means "a name comprising a sequence of DNS labels, separ= ated by dot characters, which when queried resolve to an A or MX record&quo= t;.=A0 It may have a proper definition in some other RFC too.=A0 Should we = add one in the Introduction or Definitions?
=A0
In Section 2= .3:

=A0 "An SPF-compliant domain MUST have valid SPF records as described = in
=A0 =A0Section 3."

As a note the RFC 4408 text is:

=A0 "An SPF-compliant domain MUST publish a valid SPF record as descri= bed
=A0 =A0in Section 3."

The RFC 2119 MUST is redundant.

In a re= cent conversation, Pete described this as "not really wrong, but it= 9;s shouting."=A0 I guess that means changing "MUST publish"= to "publishes" or something like that.
=A0
=A0 'If domain owners choose to publish SPF records and want to support=
=A0 =A0receivers making negative authorization determinations, then they MU= ST
=A0 =A0publish records that end in "-all", or redirect to other r= ecords that do,
=A0 =A0otherwise, no definitive determination of authorization can be made.= '

The document uses ADMD while there is "domain owners" in the abov= e. =A0I suggest reviewing that.

I think= they're synonymous.=A0 Going with ADMD is probably a good idea.
=A0=
The RFC 2119 MUST is a substantive change. =A0Why is this a MUST?

It is the only way within the protocol to cause = negative authorization determinations to occur.=A0 It is an interoperabilit= y requirement.=A0 I believe this is correct.
=A0
In Section 2.4:

=A0 'At least the "MAIL FROM" identity MUST be checked, but i= t
=A0 =A0is RECOMMENDED that the "HELO" identity also be checked be= forehand.'

There is already a RFC 2119 MUST in Section 2.2. =A0There is also a RFC 211= 9 RECOMMENDED in Section 2.1. =A0The above text restates existing RFC 2119 = requirements or recommendations.

I agre= e; the redundancy should be resolved.=A0 The cited sentence in 2.4 can prob= ably go.
=A0
=A0 'Without explicit approval of the domain owner, checking other
=A0 =A0identities against SPF version 1 records is NOT RECOMMENDED because<= br> =A0 =A0there are cases that are known to give incorrect results.'

How should this explicit approval be sought? =A0This recommendation does no= t make sense.

Adding "out-of-band&= quot; or "private" after "explicit" would probably clea= r this one up.
=A0
In Section 2.4:

=A0 'When a mail receiver decides to perform an SPF check, it MUST use = a
=A0 =A0correctly-implemented check_host() function (Section 4) evaluated =A0 =A0with the correct parameters.'

This RFC 2119 requirement states the obvious. =A0It basically says that the= re is a requirement in draft-ietf-spfbis-4408bis-14 to use a correct implem= entation of draft-ietf-spfbis-4408bis-14.

I agree, that sentence can probably go.
=A0
=A0 "Implementations have to take care to correctly extract the <do= main>
=A0 =A0from the data given with the SMTP MAIL FROM command as many MTAs wil= l
=A0 =A0still accept such things as source routes ..."

The definition of <domain> is:

=A0 'the domain portion of the "MAIL FROM" or "HELO"= ; identity.'

I am not sure whether it is even a definition. =A0From an implementation pe= rspective the last paragraph of Section 2.4 is unclear.

I don't agree.=A0 I imagine by now you're aware of= what this is for; can you suggest some other text that accomplishes the in= tent?
=A0
=A0 'Performing the authorization other than using the return-path and<= br> =A0 =A0client address at the time of the MAIL command during the SMTP
=A0 =A0transaction can cause problems, ..'

Shouldn't that be "authorization check"?

Yes.
=A0
=A0 'Generating non-delivery notifications to forged identities that ha= ve
=A0 =A0failed the authorization check is a source of backscatter and SHOULD=
=A0 =A0be avoided.'

This RFC 2119 SHOULD is not in RFC 4408. =A0The above does not have anythin= g to do with Sender Policy Framework. =A0It was mentioned during WG discuss= ions that "SPF can help the backscatter problem" [2]. =A0This tex= t may have been introduced in response to a review [3]. =A0Is this an enhan= cement or a clarification?

I think it documents operational experienc= e acquired since RFC4408 was published.=A0 As for whether RFC2119 language = is appropriate, I agree that it isn't; it has nothing to do with SPF it= self, though it is a side effect of its use.=A0 I suggest changing SHOULD t= o "needs to".
=A0
In Section 2.6:

=A0 "An SPF verifier implements something semantically identical to th= e
=A0 =A0function defined there."

John Levine commented about this during the WGLC [4]. =A0I am listing this = as a reminder for myself.

I agree with = John.
=A0
In Section 2.6.1:

=A0 'A result of "none" means either (a) no syntactically val= id DNS domain
=A0 =A0name was extracted from the SMTP session that could be used as the =A0 =A0one to be authorized, or (b) no TXT records were retrieved from the<= br> =A0 =A0DNS that appeared to be intended for use by SPF verifiers.'

I suggest "DNS TXT records". =A0What is a syntactically valid DNS= domain name? =A0The definition of "none" in RFC 4408 is clear (t= o me).

"DNS TXT records" is f= ine but probably not necessary at this point in the document.

We discussed the "syntactically valid" thing above= .

This definition of "none" is more precise tha= n it was in RFC4408.=A0 The 4408 definition was:
   A re=
sult of "None" means that no records were published by the domain
   or that no checkable sender domain could be determined from the given
   identity.  The checking software cannot ascertain whether or not the
   client host is authorized.
This text did not account for the notion= that TXT records were returned that didn't start "v=3Dspf1".= =A0 It also wasn't clear about what "checkable" meant.=A0 I b= elieve the bis definition is better.
=A0
In Section 2.6.2:

=A0 'The domain owner has explicitly stated that it is not asserting =A0 =A0whether the IP address is authorized. =A0This result MUST be treated=
=A0 =A0exactly like the "none" result; the distinction exists onl= y for
=A0 =A0informational purposes.'

As a note, the RFC 2119 MUST is in RFC 4408. =A0The Introduction Section me= ntions "ADMDs can authorize hosts to use their domain names". =A0= The above uses "domain owner".

Covered earlier.
=A0
In Section 2.6.7:

=A0 'A "permerror" result means the domain's published re= cords could not
=A0 =A0be correctly interpreted. =A0This signals an error condition that =A0 =A0definitely requires manual intervention to be resolved.'

What is "manual intervention" in the above?
=
"Operator intervention" might be more consistent w= ith common IETF usage.
=A0
In Section 3:

=A0 'An SPF record is a DNS record that declares which hosts are, and a= re
=A0 =A0not, authorized to use a domain name for the "HELO" and &q= uot;MAIL FROM"
=A0 =A0identities.'

How are hosts which are not authorized to use a domain name listed in a SPF= record?

It's implicit in that the = set that is not authorized is the complement to the set that is authorized.= =A0 If we want to make it clear, we could say "which hosts are, and th= us also which are not," or something like that.
=A0
=A0 "The SPF record is a single string of text."

What is a single string of text? =A0It may be easier to state this in terms= of record format.

I don't think th= at statement is unclear, but I agree with the improvement suggestion.=A0 Ma= ybe:

"An SPF policy statement is expressed as a single string of text e= ncoded in a DNS TXT record."
=A0
=A0 'ADMDs publishing SPF records SHOULD try to keep the number of
=A0 =A0"include" mechanisms and chained "redirect" modi= fiers to a minimum.'

What is the minimum? =A0Note that this RFC 2119 SHOULD is in RFC 4408.
<= /blockquote>

There isn't a specific minimum.=A0 The = expression means "don't use this technique unless you absolutely n= eed it".
=A0
=A0 'ADMDs SHOULD also try to minimize the amount of other DNS informat= ion
=A0 =A0needed to evaluate a record.'

This RFC 2119 SHOULD is also in RFC 4408. =A0There are two RFC 2119 SHOULDs= in the last paragraph of Section 3. =A0This usage of RFC 2119 key words do= es not help the SPF "publisher". =A0 In my opinion the "SHOU= LD try" in this context uses the RFC 2119 key word in unorthodox ways.=

I agree with "SHOULD try", as th= at's arguably not actionable.=A0 "SHOULD minimize" is probabl= y fine, however.
=A0
In Section 3.1:

=A0 'SPF records MUST be published as a DNS TXT (type 16) Resource Reco= rd
=A0 =A0(RR) [RFC1035] only.'

I would ask why "MUST be published ... only". =A0By the way, Sect= ion 3 has a reference to Section 4 for record format instead of Section 3.1= . =A0Is that correct?

The text is not i= ncorrect, but it's also not necessary.=A0 Dropping "only" is = probably sufficient.

The reference is indeed incorrect.
=A0
In Section 3.2:

=A0 "A domain name MUST NOT have multiple records that would cause an<= br> =A0 =A0authorization check to select more than one record."

This RFC 2119 MUST NOT was in RFC 4408. =A0Is this to help the SPF "pu= blisher" and if so, how does it help?

<= div>I believe it is an advisory to publishers of the consequences of having= more than one "v=3Dspf1" record published.

In Section 3.3:

=A0 "As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DN= S
=A0 =A0record can be composed of more than one string."

See previous comment about " a single string".

This use is correct, as it describes the fact that there = are many ways to encode a single high-level string into multiple low-level = "character-strings" as defined in RFC1035.
=A0
=A0 "If a published record contains multiple character-strings, then t= he
=A0 =A0record MUST be treated as if those strings are concatenated together=
=A0 =A0without adding spaces."

This RFC 2119 MUST is also in RFC 4408. =A0I suggest removing the "MUS= T" in the example.

I disagree.=A0 = It's required for interoperability.
=A0
=A0 "TXT records containing multiple strings are useful in constructin= g
=A0 =A0records that would exceed the 255-byte maximum length of a character= -
=A0 =A0string within a single TXT record."

I suggest using "octet" instead of "byte". =A0I'll = point the working group to CVE-2008-2469 in case it might wish to consider = that issue.

How is an octet different f= rom a byte in this context?=A0 This strikes me as a stylistic issue at best= .
=A0
In Section 4:

=A0 "A compliant SPF implementation MUST do something semantically equ= ivalent to
=A0 this description."

It's unusual to see a "do something" RFC 2119 requirement in = a specification. =A0Is the SPFBIS WG working on compliance for SPF implemen= tations?

=A0RFC6376 is an example of a = standards track document that uses RFC2119 MUST in this way.=A0 I'm sur= e I've seen others but I can't think of them at this hour.=A0 I thi= nk it's fine.

=A0 "Mail receivers that perform this check MUST correctly evaluate th= e
=A0 =A0check_host() function as described here."

Where does "mail receivers" fit in the Sender Policy Framework? = =A0The "MUST correctly evaluate" is stating the obvious.

I'm not understanding how the answer to the= first question isn't obvious.

I agree with the second point.

=A0
=A0 "Implementations MAY use a different algorithm than the canonical<= br> =A0 =A0algorithm defined here, so long as the results are the same in all =A0 =A0cases."

Why is this a RFC 2119 MAY? =A0I am aware that the text is in RFC 4408.
=

This seems to me to be another stylistic q= uestion, since MAY in RFC2119 terms doesn't mean much.
=A0
In Section 4.1:

=A0 '<domain> - the domain that provides the sought-after authori= zation
=A0 =A0 =A0 =A0 =A0 =A0 =A0 information; initially, the domain portion of t= he "MAIL
=A0 =A0 =A0 =A0 =A0 =A0 =A0 FROM" or "HELO" identity.'
The above text is different from the text in Section 2.4.
<= div>
I think I agree; I would prefer to have it defined in on= e place, and have other points in the document reference it.
=A0
In Section 4.3:

=A0 "If the <domain> is malformed (e.g. label longer than 63 cha= racters,
=A0 =A0zero-length label not at the end, etc.)"

=A0That should be "octets".

S= ince the DNS is all in ASCII, they're synonymous.=A0 That said, we may = as well be consistent.
=A0
=A0 "Properly formed domains are fully qualified email domains as
=A0 =A0described in [RFC5321] Section 2.3.5."

What are "properly qualified email domains"?

Is the reference defining that term not appropriate?
=A0=
=A0 "Internationalized domain names MUST be encoded as A-labels, as =A0 described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]."

I'm listing the above and leave it to Area Director guidance. =A0Please= note that it is a new RFC 2119 requirement.

I'm pretty sure RFC4408 pre-dates most of the IDN work, so this i= s a modernization step.=A0 I think it's important to include, and it al= so does the same thing DKIM did, which is now Draft Standard.=A0 If we don&= #39;t, there's no guidance for use of SPF in the IDN context.=A0 The al= ternative is to spin up another document (which we're not chartered to = do) that discusses use of SPF in the IDN context.
=A0
In Section 4.4:

=A0 "In accordance with how the records are published (see Section 3 =A0 =A0above), a DNS query needs to be made for the <domain> name, qu= erying
=A0 =A0for type TXT only."

I don't understand the sentence.

Qu= ery the HELO domain or the MAIL FROM domain, as described in Section 3.
= =A0
=A0 'Alternatively, for a server failure (RCODE 2) result, check_host()=
=A0 =A0MAY track failures and treat multiple failures within 24 hours for =A0 =A0the same domain as "permerror".'

This text is not in RFC 4408. =A0I found a note in Issue #1 [5] and in a me= ssage [6].

Are there any implementation= s that do this?=A0 If so, that's the justification; it's practical = experience.=A0 If not, we should consider dropping it.
=A0
In Section 4.6.2:

=A0 "If there are no more mechanisms, the result is specified in
=A0 =A0Section 4.7."

This sentence does not make sense.

How = about: "After all mechanisms have been processed and no matches are fo= und, the result is determined according to Section 4.7."

=A0 "If this number is exceeded during a check, a permerror MUST be re= turned."

I read this as if an implementation-specific limit is reached a permerror i= s returned. =A0There are two RFC 2119 MUST in the above. =A0That can be red= uced to one MUST.

I'm not sure I ag= ree.=A0 SecDir has pushed the fixed query limit on other topics in the past= , which is the first MUST, and the second MUST prescribes a specific result= that has to occur when the limit is reached which is important for interop= erability.
=A0
=A0 'MTAs or other processors SHOULD impose a limit on the maximum amou= nt
=A0 =A0of elapsed time to evaluate check_host(). =A0Such a limit SHOULD all= ow
=A0 =A0at least 20 seconds. =A0If such a limit is exceeded, the result of =A0 =A0authorization SHOULD be "temperror".'

There are three RFC 2119 SHOULDs in the above. =A0I suggest rewriting the t= ext to reduce that.

All three of them s= eem to be important interoperability points.=A0 We could common factor the = SHOULD and then present three bullets in a list, but the meaning is the sam= e.
=A0
=A0 'SPF implementations SHOULD limit "void lookups" to two.&= #39;

What are void lookups?

Last paragraph o= f Section 4.6.
=A0
=A0 "In this case, a default of two is RECOMMENDED."

Why is "two" recommended?

Int= eroperability; if one is two while another is 10, different SPF results can= be returned.
=A0
=A0 'Note that records SHOULD always use either a "redirect" = modifier or
=A0 =A0an "all" mechanism to explicitly terminate processing.'= ;

Why is there a RFC 2119 key word in a note?

=
Since the explanation I've been given is that it's better for = human debugging, I think I agree since the advice is not specific to the pr= otocol itself.
=A0
In Section 4.8:

=A0 'e.g., "foo..= example.com") or overlong labels (more than 63
=A0 =A0characters).'

I suggest octets.

Again, synonymous.=A0
in Section 5:

=A0 'SPF implementations on IPv6 servers need to handle both "AAAA= " and "A"
=A0 =A0secords, for clients on IPv4 mapped IPv6 addresses [RFC4291].'

There is a typo, "records".

I'll flag the above for review by people with IPv6 expertise.

This was covered in a different thread.=A0 I bel= ieve a proposed text fix was made that people seemed to like.

In Section 5.3:

=A0 'a =A0 =3D "a" =A0 =A0 =A0[ ":" domain-spec ] [= dual-cidr-length ]'

"dual-cidr-length" is introduced in this sub-section. =A0I had to= search through the draft to find out what it means.
<= br>
That happens sometimes.=A0 :-)
=A0
In Section 5.4:

=A0 'Note regarding implicit MXs: If the <target-name> has no MX = records,
=A0 =A0check_host() MUST NOT pretend the target is its single MX, and MUST<= br> =A0 =A0NOT default to an A or AAAA lookup on the <target-name> direct= ly.'

There are two RFC 2119 MUSTs in the above. =A0This is over-usage of RFC 211= 9 key words. =A0This text was in RFC 4408. =A0This is not a divergence from= RFC 5321, it is a contrary to Section 5 of RFC 5321.
=
I believe the advice should remain, but it could be simplified:
"Note regarding implicit MXes: If t= he <target-name> has no MX records, check_host() MUST NOT apply the i= mplicit MX rules of RFC5321 by querying for an A record for the same name.&= quot;

In Section 5.5:

=A0"This mechanism SHOULD NOT be used."

I suggest providing a reason for this.

= The very next sentence is "See below for discussion."
=A0
=A0 "To prevent DoS attacks, more than 10 PTR names
=A0 =A0MUST NOT be looked up during the evaluation of a "ptr" mec= hanism
=A0 =A0(see Section 4.6.4)."

The above restates a previous RFC 2119 MUST.

Agreed.
=A0
=A0 "If used, proper PTR records MUST be in place for the domain's= hosts
=A0 =A0and the "ptr" mechanism SHOULD be one of the last mechanis= ms checked."

Those RFC 2119 key words are not in RFC 4408. =A0I don't see how this R= FC 2119 change qualifies as a clarification or explanation.

It was "must" vs. MUST in RFC4408.=A0 It'= ;s otherwise unchanged.
=A0
=A0 "It is, however, still in use and part of the SPF protocol, so com= pliant
=A0 check_host() implementations MUST support it."

What is a compliant check_host() implementation?

<= /div>
One that complies with this specification.
=A0
In Section 5.6:

=A0 "ip6-network =A0 =A0 =A0=3D <as per [RFC 4291], section 2.2>= "

I suggest that the above reference be verified for correctness.

Looks right to me.=A0 The CIDR expression is in th= e optional token next to it, so this has to be just a plain IPv6 address, s= o that's the right reference.
=A0
In Section 5.7:

=A0 'v=3Dspf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all'

I'll flag this for review by DNS folks.

=
What's the specific question being asked of DNSDIR here?
=A0
In Section 6:

=A0 'The modifiers defined in this document ("redirect" and &= quot;exp") MAY
=A0 =A0appear anywhere in the record, but SHOULD appear at the end, after =A0 =A0all mechanisms.'

This text is in RFC 4408. =A0I would label the RFC 2119 usage as defective.=

Why?
=A0
In Section 6.2:

=A0 "Since the explanation string is intended for an SMTP response and=
=A0 =A0[RFC5321] Section 2.4 says that responses are in [US-ASCII], the
=A0 =A0explanation string MUST be limited to US-ASCII.'

It would be easier to defer to RFC 5321 instead of setting a RFC 2119 requi= rement in this draft. =A0I note that this requirement was not in RFC 4408.<= br>

I agree that this could be expressed no= n-normatively (e.g. "needs to be").
=A0
=A0 "Software SHOULD make it clear that the explanation string
=A0 =A0comes from a third party."

I could not understand what that means in RFC 2119 terms. =A0The draft uses= RFC 2119 key words by example instead of providing an explanation.

I agree; we're talking about interoperabil= ity between humans here, and not between implementations.
=A0
In Section 7.1:

=A0 'The "toplabel" construction is subject to the LDH rule p= lus
=A0 =A0additional top-level domain (TLD) restrictions.'

Where can I find these restrictions? =A0Please note that I have read the In= formational RFC.

I'm pretty sure it'= s referring to common TLD conventions.

In Section 7.3:

=A0 "-exists:%(ir).sbl.spamhaus.example.org"

I commented about vendor-neutral previously [8]. =A0The above is a way to g= et around the objection [9]. =A0I suggest cleaning this up.

Sure.
=A0
=A0"so trailing dots SHOULD NOT be published by domain owners"
Why is it "domain owners"?

AD= MDs is fine here.
=A0
=A0 "This macro SHOULD NOT be used. =A0See Section 5.5 for the discuss= ion
=A0 =A0about why not."

This comes out as a flippant explanation for the RFC 2119 SHOULD.

I think it's fine, though I suggest changing= "the discussion about why not" to just "discussion". =A0
=A0 "This SHOULD be a fully qualified domain name, but if one does not=
=A0 =A0exist (as when the checking is done by a MUA) or if policy restricti= ons
=A0 =A0dictate otherwise, the word "unknown" SHOULD be substitute= d."

The RFC 2119 key words are in RFC 2119. =A0I don't know what to say.

I think that looks fine as-is, though we = could change the first SHOULD to "ought to" because it's a tr= ansformation of other input and not an implementation choice.=A0 (And I ass= ume you mean they were in RFC4408.)
=A0
=A0 "When the result of macro expansion is used in a domain name query= , if
=A0 =A0the expanded domain name exceeds 253 characters (the maximum length<= br> =A0 =A0of a domain name), the left side is truncated to fit, by removing =A0 =A0successive domain labels (and their following dots) until the total<= br> =A0 =A0length does not exceed 253 characters."

Where is it specified that the maximum length of a domain name is 253 chara= cters?

RFC1035 says it's 255.
=A0 "Care has to be taken by the sending ADMD so that macro expansion = for
=A0 =A0legitimate email does not exceed the 63-character limit on DNS label= s."

Where is that 63-character limit specified?

=
RFC1035, Section 2.3.1.
=A0
It is odd to have RFC 2119 requirements under a "Notes" heading.<= br>

Agreed.
=A0
In Section 8.2:

=A0 'A "neutral" result MUST be treated exactly like the &quo= t;none" result;
=A0 =A0the distinction exists only for informational purposes.'

Why is an existing RFC 2119 restated?

A= greed.
=A0
In Section 8.5:

=A0 "The domain owner believes the host is not authorized but is not w= illing
=A0 =A0to make a strong policy statement."

Why is it domain owner?

ADMD.
=A0
In Section 9.1:

=A0 "The Received-SPF header field is a trace field (see [RFC5322] Sec= tion
=A0 =A03.6.7) and SHOULD be prepended to the existing header, above the
=A0 =A0Received: field that is generated by the SMTP receiver."

"prepended to the existing header" does not sound right.

It's correct; "header" is the ent= ire header block, while "header field" is one field in it.=A0 (Se= ction 2.1 of RFC5322.)
=A0
=A0 "It MUST appear above all other Received-SPF fields in the message= ."

How does this fit into the previous RFC 2119 SHOULD?
<= br>
It SHOULD be prepended to the whole header block, but even if= it isn't, it MUST appear above any other Received-SPF field.
=A0
in Section 10:

=A0 "This section is not a "how-to" manual, or a "best = practices" document,
=A0 =A0and it is not a comprehensive list of what such entities SHOULD do i= n
=A0 =A0light of this document."

What is the meaning of the RFC 2119 SHOULD in the above?

Agreed, it's inappropriate here.
=A0
In Section 10.1.2:

=A0 "Publishing SPF records for domains that send no mail is
=A0 =A0a well established best practice."

I am not aware of that best practice. =A0I did a few DNS queries:

;; QUESTION SECTION:
;bing.com. =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IN =A0 =A0 =A0TXT

;; ANSWER SECTION:
bing.com. =A0 =A0 =A0 =A0= =A0 =A0 =A0 3600 =A0 =A0IN =A0 =A0 =A0TXT =A0 =A0 "v=3Dmsv1 t=3D6097A= 7EA-53F7-4028-BA76-6869CB284C54"

;; QUESTION SECTION:
;com.com. =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 IN =A0 =A0 =A0TXT

;; ANSWER SECTION:
com.com. =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0293 =A0 =A0 IN =A0 =A0 =A0TXT "google-site-verification= :esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k"

What are you saying here?=A0 This is an existence proof of non-mailing doma= ins that don't publish SPF records, but it doesn't contradict the s= tatement made in the draft.
=A0
In Section 10.1.3:

=A0 "SPF functionality is enhanced by administrators ensuring this
=A0 identity is set correctly and has an appropriate SPF record."

How is SPF functionality enhanced?

When= MAIL FROM is null, it's important that HELO be right in order to get a= ny useful result from SPF.
=A0
In Section 10.2:

=A0 "As stated elsewhere in this document, there is no normative requi= rement
=A0 =A0for specific handling of a message based on any SPF result."
The "as stated elsewhere" is vague.

Section 8 discusses it, if you're saying you'd like a specif= ic reference.
=A0
=A0 'The primary considerations are that SPF might return "pass&qu= ot; for mail
=A0 =A0that is ultimately harmful (e.g., spammers that arrange for SPF to =A0 =A0pass using nonsense domain names'

What are "nonsense" domain names?

=
"arbitrary", "discardable", something like that.
=A0
In Section 10.3:

=A0 "The mediator can make the newly-posted message be as similar or a= s
=A0 =A0different from the original message as they wish."

The sentence seems incomplete, i.e. similar to what.
<= br>
The original message.
=A0
=A0 "For the operation of SPF, the essential concern is the email
=A0 =A0address in the 5321.MailFrom command for the new message."

What does this mean?

In the context of = mediators (which is the title of this subsection), the RFC5321.MailFrom fie= ld used by the mediator to inject a new message is the most important consi= deration.
=A0
=A0 'Because SPF evaluation is based on the IP Address of the "las= t"
=A0 =A0sending SMTP server, the address of the mediator will be used, rathe= r
=A0 =A0than the address of the SMTP server that sent the message to the
=A0 =A0mediator.'

I'll note that this is a mix of RFC 5321 and RFC 5598. =A0The result is= clear or unclear depending on the background of the reader.

I think this is clear.=A0 You're familiar with th= e architecture here; what do you think would fix it?
=A0
In Section 11.5:

=A0 "An SPF compliant receiver gathers information from the SMTP comma= nds
=A0 =A0it receives and from the published DNS records of the sending domain=
=A0 =A0holder"

I suggest explaining the untrusted part.

Agreed.=A0 A second sentence indicating most of that input is unverified = is probably in order, with references if possible.
=A0
In Section 11.6:

=A0 "Checking SPF records causes DNS queries to be sent to the domain<= br> =A0 =A0owner."

How are DNS queries sent to domain owners?

<= div>"to the ADMD infrastructure"
=A0
In Section 13.1:

=A0 "The format of this type is identical to the TXT RR [RFC1035]"= ;

The format is not identical, i.e. it's a different RR. =A0I suggest kee= ping the IANA Considerations Section simple, i.e. clearly explain to IANA w= hat action is requested.

The format is = indeed identical, right down to the octet.
=A0
References:

Why is RFC 1123 a normative reference?

= It defines the "%"-hack, of which implementers need to be aware (= i.e., code needs to be able to handle that syntax).
=A0
Why is RFC 3864 a normative reference?

= A BCP (e.g., a registration procedure) followed is always a normative refer= ence, I believe.
=A0
Where can I find "Designated Mailers Protocol"?

Where can I find "Domain-Authorized SMTP Mail"?
<= div>
Agree, those need fixing.
=A0
ABNF:

Did anyone verify the ABNF?

It's be= en some time but I did a full pass over it previously.
=A0
In Appendix C:

In Section E.1:

=A0 'This would cause a lookup on an DNS white list (DNSWL) and cause a=
=A0 =A0result of "fail" only for email not either coming from the=
=A0 =A0domain's mx host(s) (SPF pass) or white listed sources (SPF
=A0 =A0neutral).'

I didn't find any discussion about this on the SPFBIS mailing list. =A0= is there an explanation for this change between RFC 4408 and this draft?

It was in 9.3 in the previous document an= d has been reworded a little.=A0 It's otherwise unchanged.
=A0
In Appendix I:

Appendix I is about "Protocol Status". =A0This draft is intended = as a Proposed Standard. From an IETF perspective that is what it will be. = =A0Describing it as something different can be misleading.

=A0 "[RFC4408] was designed to clearly document the protocol defined b= y
=A0 =A0earlier draft specifications of SPF as used in existing
=A0 =A0implementations. =A0This updated specification is intended to clarif= y
=A0 =A0identified ambiguities in [RFC4408], resolve techincal issues
=A0 =A0identified in post-RFC 4408 deplyment experience, and document widel= y
=A0 =A0deployed extensions to SPF that have been developed since [RFC4408]<= br> =A0 =A0was published."

There are t= wo typos in there (techincal, deplyment).
=A0
Extensions to the SPF protocol are clearly mentioned in the charter as bein= g out of scope. =A0The "document widely deployed extensions" is p= roblematic.

Agreed.
=A0
=A0 "This document updates and replaces RFC 4408 that was part of a gr= oup
=A0 =A0of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, =A0 =A0RFC 4407, and RFC 4408) in 2006. =A0At that time the IESG requested = the
=A0 =A0community observe the success or failure of the two approaches
=A0 =A0documented in these RFCs during the two years following publication,=
=A0 =A0in order that a community consensus could be reached in the future.&= quot;

Why is this needed? =A0The SPFBIS WG produced RFC 6686 to resolve the exper= iment.

=A0 "SPF is widely deployed by large and small email providers alike.<= br> =A0 =A0There are multiple, interoperable implementations."

Someone might point out that this is marketing instead of text relevant to = a protocol. =A0I'll mention that one or more significant issues (e.g. I= ssue #9) was identified during the WG discussions. =A0Issue #9 was not list= ed as the errata. =A0I suggest removing the section as it will be less text= and there is already two informative references to help the reader find ba= ckground information.

I propose leaving this stuff in there as i= nformation to the IESG.=A0 If they think it's unnecessary, they can ask= that we remove it, or they can do so in a note to the RFC Editor.

-MSK
--047d7b5d8cfff2de4b04db7b9106-- From vesely@tana.it Mon Apr 29 02:27: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 D1EE521F99CB for ; Mon, 29 Apr 2013 02:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiOwZu0t5YLA for ; Mon, 29 Apr 2013 02:27:32 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B3F6B21F9911 for ; Mon, 29 Apr 2013 02:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367227649; bh=7n7+cQSzsqYmqsStYZ69YWQk6Hh7fNOfu2f9WAk8yoM=; l=1533; h=Date:From:To:References:In-Reply-To; b=THzYKJWkpiFiwfypLMblQ5l3klSwrHUdX5/5I/JAx17ZgE1/p9qU89kYghDPtZWyj dn5VeaPSAkz2tDjTXa2TxgGKC33SgvIv0M2eneaWY4jeBC2S5nzK079Y9nbyh7rTpL qFA4V3v2V3W2ztiMbnFnczZnkZ7T4hBpMlU9Ufj8= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 29 Apr 2013 11:27:29 +0200 id 00000000005DC035.00000000517E3D01.00007F59 Message-ID: <517E3D01.1070508@tana.it> Date: Mon, 29 Apr 2013 11:27:29 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130427185301.28485.qmail@joyce.lan> In-Reply-To: <20130427185301.28485.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] IPv4 mapped IPv6 addresses 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, 29 Apr 2013 09:27:32 -0000 On Sat 27/Apr/2013 20:53:01 +0200 John Levine wrote: >> As I understand it, the idea is that a connection arriving via an >> IPv6-mapped IPv4 address is supposed to be reported to the accepting >> application as an IPv4 connection, so SPF would never know about the >> "IPv6-mapped" part in the first place. > > It depends on the implementation. Here in FreeBSD land, the preferred > way to listen to both IPv4 and IPv6 is to set up two sockets and > listen to both, but you can also flip a kernel setting, listen on one > IPv6 socket, and the IPv4 connections will show up in your application > on mapped addresses. AFAIK, the latter is the only case where mapped addresses show up. > The current language on page 21 of the draft seems fine to me, at > worst harmless, and addresses the real situation I described above. +1, but if we are to improve that wording by using layers, the only layering we can meaningfully refer to is that between the message handler part of the verifier and check_host(). In that case, it makes more sense to check for mapped addresses in the library, which is what Mail::SPF does. Accordingly, I'd address that point in the "Initial Processing" section as mentioned at the end of http://www.ietf.org/mail-archive/web/spfbis/current/msg03520.html That would match smoothly with wordings such as "when is an IPv4", as used in mechanism definitions. In either case, wordings such as "appropriate for the connection type" might appear ambiguous to an idiotic reader. From sm@elandsys.com Mon Apr 29 07:20: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 1886321F9D8C for ; Mon, 29 Apr 2013 07:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwETSapBqS9i for ; Mon, 29 Apr 2013 07:20:18 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE6A21F9D83 for ; Mon, 29 Apr 2013 07:20:18 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3TEJo8U008461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Apr 2013 07:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367245205; bh=hERGUM4Hyb+2dazs+FAv/H/K1JufMml14KWxZT6XgQE=; h=Date:To:From:Subject:Cc; b=2GP46WwUQ8w8OxDSGVyL7tNulhurJThVw/5dzV9HZRxUJ7sJHM06RcrkndUhHHI+3 i3DJuuxAxLOlHemkMzHXHfXtX9fZtM3QZ7FJm1+r9xAYsv8Eo+7hGcizG1DFii2joU FkPPPeYkzrC8Qg9B5Amo67n8/y5HTOGPz7u+mtJM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367245205; i=@elandsys.com; bh=hERGUM4Hyb+2dazs+FAv/H/K1JufMml14KWxZT6XgQE=; h=Date:To:From:Subject:Cc; b=Y+p+1cOYJPrdStAALJSUyJ9h+Uu7lQyxJsT6kFx81C6hhlyRxY+D7OxtRBknaTeAH tVqGGVrWCn+DGT2xWt1EnIWULj7i3CQOJo86zVNfITUlD3LfMPrsCqGx2jVOoZ7WFw +qVPMXagEmcDp/HMrc1RhVBKH3/R5OLwjN67Hh+c= Message-Id: <6.2.5.6.2.20130429065657.0d392368@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 29 Apr 2013 07:05:57 -0700 To: Cyrus Daboo From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] APPSDIR review of draft-ietf-spfbis-4408bis-14.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, 29 Apr 2013 14:20:20 -0000 Hi Cyrus, Thanks for the review. I am forwarding it to the=20 SPFBIS mailing list for the working group to=20 discuss. I'll follow-up on apps-discuss@ after that. Regards, S. Moonesamy (as document shepherd) >I have been selected as the Applications Area=20 >Directorate reviewer for this draft (for=20 >background on appsdir, please see=20 >=E2=80=8Bhttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDire= ctorate ). > >Please resolve these comments along with any=20 >other Last Call comments you may receive. Please=20 >wait for direction from your document shepherd=20 >or AD before posting a new version of the draft. > >Document: draft-ietf-spfbis-4408bis-14.txt >Title: Sender Policy Framework (SPF) for=20 >Authorizing Use of Domains in Email, Version 1 >Reviewer: Cyrus Daboo >Review Date: 2013-04-29 > >Summary: This draft is almost ready for=20 >publication as an RFC, subject to some minor issues that should be= resolved. > >Overview: This document is an update to RFC4408=20 >that seeks to upgrade the specification from=20 >experimental status, clarifying a number of=20 >issues in the original specification, providing=20 >in depth detail of actual deployment experience,=20 >and documenting various extensions now in common=20 >use. The new draft achieves these aims and=20 >provides a good reference for implementors. > >Major Issues: None > >Minor Issues: > > Section 4.6.1 ABNF terms "A / MX / PTR=20 > / IP4 / IP6" are upper case but terminal terms=20 > are lower case in Section 5 (but uppercase in=20 > Appendix A). Looks like these need fixing in Section 5. > > Section 6.2 Paragraph 6 There is a=20 > reference to Section 2.6.4 but that section=20 > does not contain anything relevant. Either=20 > remove the reference or point to a relevant section. > > Section 7.1 Paragraph 2 States "subject=20 > to LDH rule" - that needs a reference to=20 > RFC3696 Section 2 (reference was in RFC 4408). > >Section 11.3 Why no mention of DNSSEC as a way=20 >to alleviate this issue? Has anyone been using=20 >DNSSEC with SPF? If not, why not? > >Nits: > > Section 2.4 (argument list) and Section=20 > 4.1 appear to duplicate similar information -=20 > consider removing the list of args in Section 2.4 and add a reference to= $4.1. > > Section 2.5 Paragraph 2 First part of=20 > sentence hard to read - break it up with commas. > > Section 2.6 and Section 8 appear to=20 > duplicate a lot of similar information. Please=20 > consider trimming down Section 2.6 and have it=20 > refer to Section 8 for full details. > > Section 3.5 Paragraph 1 Has the word=20 > "discouraged". Shouldn't this use a 2119 term, e.g.: "NOT RECOMMENDED"? > > Section 6.1 Paragraph 1 Remove second=20 > sentence - pretty much the same as the first one. > > Section 6.2 Paragraph 4 Put exp in double-quotes. > > Section 10 Paragraph 1 SHOULD - in this=20 > context it is not really appropriate to use a 2119 term. Please rephrase. > > Various places: permerror is sometimes=20 > used without double-quotes around it - I think=20 > all uses should have double-quotes. > > >-- >Cyrus Daboo > From dhc@dcrocker.net Mon Apr 29 07:36: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 0C17B21F9E4C for ; Mon, 29 Apr 2013 07:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiLCN8IKQ5km for ; Mon, 29 Apr 2013 07:36:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 117A321F9E4B for ; Mon, 29 Apr 2013 07:36:44 -0700 (PDT) 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 r3TEaQCe028973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Apr 2013 07:36:29 -0700 Message-ID: <517E856A.6060205@dcrocker.net> Date: Mon, 29 Apr 2013 07:36:26 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20130423063319.0d04e118@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.66]); Mon, 29 Apr 2013 07:36:30 -0700 (PDT) Cc: "spfbis@ietf.org" , S Moonesamy Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 14:36:48 -0000 On 4/29/2013 1:21 AM, Murray S. Kucherawy wrote: > This RFC 2119 "MUST" is not in RFC 4408. It is a substantive change > in my opinion. > > > This was probably at my suggestion. The issue here is that RFC2119 > doesn't say "must" has any different meaning than "MUST" does, so we > should either be consistant and uppercase-ize it, or use some other word. > > In any event, I don't agree that this is actually a substantive change. +1. 2119 terms are case-insensitive. > "This SPF check can only be performed when the "HELO" string is a > valid fully qualified domain." > > What is a valid fully qualified domain? Internet Users' Glossary", FYI 18, RFC 1983 http://tools.ietf.org/html/rfc1983 Fully Qualified Domain Name (FQDN) The FQDN is the full name of a system, rather than just its hostname. For example, "venera" is a hostname and "venera.isi.edu" is an FQDN. See also: hostname, Domain Name System. I suggest merely citing this RFC. > "Implementations have to take care to correctly extract the > from the data given with the SMTP MAIL FROM command as many MTAs > will > still accept such things as source routes ..." > > The definition of is: > > 'the domain portion of the "MAIL FROM" or "HELO" identity.' > > I am not sure whether it is even a definition. From an > implementation perspective the last paragraph of Section 2.4 is unclear. > > > I don't agree. I imagine by now you're aware of what this is for; can > you suggest some other text that accomplishes the intent? On reflection, it might avoid some reader confusion to define have the label be something like , so that isn't overloaded with a specialized definition for this document. > This RFC 2119 SHOULD is not in RFC 4408. The above does not have > anything to do with Sender Policy Framework. It was mentioned > during WG discussions that "SPF can help the backscatter problem" > [2]. This text may have been introduced in response to a review > [3]. Is this an enhancement or a clarification? > > > I think it documents operational experience acquired since RFC4408 was > published. As for whether RFC2119 language is appropriate, I agree that > it isn't; it has nothing to do with SPF itself, though it is a side > effect of its use. I suggest changing SHOULD to "needs to". +1 > 'Because SPF evaluation is based on the IP Address of the "last" > sending SMTP server, the address of the mediator will be used, > rather > than the address of the SMTP server that sent the message to the > mediator.' > > I'll note that this is a mix of RFC 5321 and RFC 5598. The result > is clear or unclear depending on the background of the reader. > > > I think this is clear. You're familiar with the architecture here; what > do you think would fix it? I don't understand the confusion either;. The text looks reasonable, clear and reasonably concise. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From vesely@tana.it Mon Apr 29 07: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 F2A3721F9E73 for ; Mon, 29 Apr 2013 07:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h36xlfvym5MP for ; Mon, 29 Apr 2013 07:50:01 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 441AB21F9E72 for ; Mon, 29 Apr 2013 07:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367247000; bh=xSyQr6gD5mEYWv40FarGgB4KLboAuTtia1LW2pknDR8=; l=1525; h=Date:From:To:CC:References:In-Reply-To; b=W/+E7wsmY5B7Ny3kW2nzyxZw7YlhLdOPzTozrERLCxGQLrpJgeKqHHeE/iuuV25hx KCD8IXVVps97J5bgby2sxrZrT9dN+4/uOtJLbAdctv9n1p6tEAf5j2URLzIxLgH5a/ sl+iCquqj6D2Gzr/uqHwAy4dHoUMH9sjENoxmDbI= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 29 Apr 2013 16:50:00 +0200 id 00000000005DC039.00000000517E8898.00005D0D Message-ID: <517E8895.1020609@tana.it> Date: Mon, 29 Apr 2013 16:49:57 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Doug Barton References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179C72F.1070703@dougbarton.us> In-Reply-To: <5179C72F.1070703@dougbarton.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 14:50:02 -0000 On Fri 26/Apr/2013 02:15:43 +0200 Doug Barton wrote: > > 4. Lots of messages along the lines of, "We've always used TXT for > this, so we should keep using it." These arguments all seem focused > around the concept that having 2 ways to do the same thing is kind of > a pain, so let's just use the one that is most popular. > > [...] > > #4 Is not a "reasoned technical argument." Maintaining spf records --whether SPF or TXT-- is a pain in the first place, especially for larger organizations that have lots of IP addresses and internal chains of responsibility delegation. An annoying feature is the recommendation to stay within UDP size limit, which forces to use included records containing several lists of addresses each. Asking to duplicate the records on top of that is not a trivial request. There are no automated tools that duplicate records to different type, and if RR types make any sense at all, I'd guess there will never be. There are domains with SPF and TXT records different from one another, hence the possibility to introduce errors or inaccuracies is non-zero. On the other hand, the domain maintainer gets zero advantages. They just wont' do it, people would rather stop using spf than mess it up with double records. Is that a technical argument? I'm surprised that nobody objects that spf syntax uses a variable number of characters, not less than 7, to express an IPv4 address, while the rest of the world use exactly 4 bytes. If it has to be text, why not TXT? From SRS0=V8mI1=OQ==stuart@gathman.org Mon Apr 29 08:14: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 D2D5921F95EA for ; Mon, 29 Apr 2013 08:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIyKpknt0vDD for ; Mon, 29 Apr 2013 08:14:30 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 15A7C21F9579 for ; Mon, 29 Apr 2013 08:14:29 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1367248486; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=D1es4c43MbBKdpDVVKFSfhEM8KNxRXlFKDbq911yurw=; b=HoqPxg+YmgTm2WuoZgQjSvOTZV0rWlVFKtcVkG9/qvqFdVBQ2GRrXQi/U4MGQXFt+HW4XT 7G0aa0HEExqu/mtnVCnUIZpH709vQeU47pWmaVmJy9Jj79rdfeY4qJ5sWAQSbqraZMDuqQ2H jqLLVZ0tQtUIbQYl0nhWWz/2qoK5Y= Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3TFEkJr007310 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 29 Apr 2013 11:14:46 -0400 Message-ID: <517E8E53.6000504@gathman.org> Date: Mon, 29 Apr 2013 11:14:27 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130428183338.97350.qmail@joyce.lan> <20130429024917.A69473323956@drugs.dv.isc.org> In-Reply-To: <20130429024917.A69473323956@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 15:27:02 -0000 Long ago, Nostradamus foresaw that on 04/28/2013 10:49 PM, Mark Andrews would write: > > ISC released BIND 9.4.0 which included SPF in Feb 2007, the first .0 > released after RFC 4408 was published. > > Libspf2, with type SPF, support didn't come out until October 2008. > No releases were made between Feb 2005 and October 2008[1]. > > The SPF camp complain about lack of type SPF record deployment yet > they took over 2 years to release a library which supported type > SPF when it was about a 10 minute fix to add support for it to the > library. > > No effort was made to update documentation to say add both SPF and > TXT records as far as I can see to bring it into line with RFC 4408. > > They then start measuring support before a hardware deprecation > cycle has even completed. > > If I had known that there was going to be a survey about type SPF > support so early in the transition process which I assumed would > take 10 to 15 years or more to complete I would have added code to > complain about missing SPF records. > > Now that you want to deprecate SPF I need to add code to tell those > that have SPF records without TXT records that they need to add TXT > records. Mark, the problem wasn't lack of deployment. The problem was TIMEOUTs from certain DNS servers/firewalls on unexpected RR types. This was a frustrating problem, and I wish I had put more thought into solving it. Dear WG, please note that publishing SPF *only* (as Mark mentions) solves the problem also - as client libraries have had a long time to check both records (and pyspf support both types very early). Most libraries do check TXT first, to avoid the TIMEOUT problem. But recording domains that TIMEOUT on SPF queries solves the problem on the client end and allows checking SPF first. From SRS0=V8mI1=OQ==stuart@gathman.org Mon Apr 29 08:24: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 4CD5121F9D98 for ; Mon, 29 Apr 2013 08:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-5kdNTYq-B2 for ; Mon, 29 Apr 2013 08:24:23 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 96E4221F9D42 for ; Mon, 29 Apr 2013 08:24:23 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1367249081; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=qxz2g/O2bkYT4cocdjjtxFUSU5nzccOI6xh9k2X7xvo=; b=ZpDYI9gbhvHnK967x+to+ZDjzDothigy11iM5vcq30ijHwlTWcy2MyigAHPAxp0xvC84Bu fys/udBtVKM3UBqFuS9q9qzveBu/qsy0NRu4QAmRjJY+3fhjSnwMBOkSvb/tpCG4DyR4d2QY /mmvMe3h1CcYnxp0gvDuTxGd/cxJY= Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3TFOeXG007338 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 29 Apr 2013 11:24:41 -0400 Message-ID: <517E90A6.6090108@gathman.org> Date: Mon, 29 Apr 2013 11:24:22 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 15:27:11 -0000 Long ago, Nostradamus foresaw that on 04/28/2013 07:25 PM, Ted Lemon would write: > On Apr 28, 2013, at 7:06 PM, Stuart Gathman wrote: >> For this implementer, it was because I didn't think of it (until night before last), and apparently no one else did either. If I had thought of it (keeping track of known broken nameservers) back in 2005, it would have worked much better to try SPF first (except for known broken nameservers). It was just so much easier to try TXT first to get the mail flowing. I am kicking myself! > So you don't mind keeping the state around for 90 seconds? The idea is that you endure the TIMEOUT the first time only. If a TXT query then succeeds, you know you are dealing with a braindead server/firewall, and record the domain and timestamp in a database. You check the database before making any SPF (type 99) query to avoid trying known braindead servers. From SRS0=V8mI1=OQ==stuart@gathman.org Mon Apr 29 08:31: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 1AF4B21F99EC for ; Mon, 29 Apr 2013 08:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y84-hv7DaLTV for ; Mon, 29 Apr 2013 08:31:46 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 3883B21F98E4 for ; Mon, 29 Apr 2013 08:31:46 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1367249524; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=Vfq3pPjLwvMHTSnNIHrPQXPPU6gqBuhf2nu9aoftDeQ=; b=o1OaU2XLuqrFxr0iC9d3SJ+IXRkBPAOm2YRIRdKwlVjpzIcwVDauFjwUgzUa69OwFvo/Fn hoTiu9rpsKvtwmjfrzufetxAOd9YOzyVNrai5R/kJpjOkV0NgCUdaBzC3OM2F5xIitZjKV92 6ybSzKv8LevpVqUYRKWIDB7roNdQM= Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3TFW3dC007389 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 29 Apr 2013 11:32:03 -0400 Message-ID: <517E9261.1010904@gathman.org> Date: Mon, 29 Apr 2013 11:31:45 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <8CD461F5-2A96-4BC5-8934-1181CB134F7E@virtualized.org> <6703991.tZ8WHlYQKG@scott-latitude-e6320> <20130426153816.E2DD133105A9@drugs.dv.isc.org> In-Reply-To: <20130426153816.E2DD133105A9@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 15:31:47 -0000 Long ago, Nostradamus foresaw that on 04/26/2013 11:38 AM, Mark Andrews would write: > > An SPF-compliant domain name SHOULD have SPF records of both RR > types. > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > Now if your nameserver doesn't support type SPF that is a good > reason not to publish it but otherwise I can't think of a reason > that meets SHOULD for not publishing type SPF if you are publishing > TXT spf record. > > As for publishing a SPF record without a TXT record. That is the > expected end state but it was still a while off and would be a > judgement call for as to when to do this as it will result in some > additional blow back / forged mail getting through. > > This is similar as to when one decided to go MX only for email and > not supply fallback A records. A similar decision about when to > stop adverting A records and just rely on AAAA records is also in > the future. > > As for looking up SPF and not falling back to TXT when it is not > available is just a broken implementation. Similarly if you only > look up TXT you are not conforment and will at some point not > interoperate with those that choose to only publish SPF records. > > So as far as I can see the entire interop arguement was a load of > garbage. +1 But I think we need to suggest at least one practical workaround for the braindead DNS/firewall problem - which is what has prompted the current retreat from type 99. (And parallel queries as suggested in 4408 was not practical.) From vesely@tana.it Mon Apr 29 08:32: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 A3E8821F9DCD for ; Mon, 29 Apr 2013 08:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.419 X-Spam-Level: X-Spam-Status: No, score=-5.419 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmIMubt3Wskx for ; Mon, 29 Apr 2013 08:32:18 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9357021F9DCC for ; Mon, 29 Apr 2013 08:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367249536; bh=kxNIL76MIbo83ynxJ9skUnpbYfyspVazMoLe0jcTWLA=; l=30183; h=Date:From:To:References:In-Reply-To; b=jF2zaQ9yNKdpJaSg1BA/YX/fIGaTeAReQ1pY+iUvCPoELkQ/MIQSGULwSFl9XowMh HNUPPYvopSUm9EpLHbK2sabnVQMDZlEJhDoKyk0SzRVEarjHYVYk3LgxsNI/TJZ9Vy 1yl27Rm5d5H9CSQIKt60oAGsvO5ra8qMD6MknkaI= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 29 Apr 2013 17:32:16 +0200 id 00000000005DC035.00000000517E9280.0000211D Message-ID: <517E9280.6040102@tana.it> Date: Mon, 29 Apr 2013 17:32:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 15:32:20 -0000 On Mon 29/Apr/2013 10:21:22 +0200 Murray S. Kucherawy wrote: > Scott and I talked a bit about some of these points, and I thought it might > help if I went through the whole thing and commented on it. I hope this is > helpful. I've chopped out stuff where I have no specific response or > opinion about the points made, so this is only a nearly-complete reply. I add a few lines, in case consensus needs to be gauged. > On Tue, Apr 23, 2013 at 4:08 PM, S Moonesamy wrote: > >> In the Abstract: >> >> "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." >> >> ADMD should be expanded in the above. This was pointed out in a review >> posted on August 26, 2012 [1]. > > Agree. +1, good style. >> In Section 2.1: >> >> 'It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" >> identity, but also separately check the "HELO" identity by applying >> the check_host() function (Section 4) to the "HELO" identity as the >> .' >> >> As a note this "RECOMMENDED" is also in RFC 4408. > > You made these notes throughout your review. I take it there's no action > for the WG here; you are just auditing "out loud" what normative things in > 4408bis were also present as-is in 4408, and which have changed. > >> 'Note that requirements for the domain presented in the EHLO or HELO >> command are not always clear to the sending party, and SPF verifiers >> MUST be prepared for the "HELO" identity to be malformed or an IP >> address literal.' >> >> This RFC 2119 "MUST" is not in RFC 4408. It is a substantive change in my >> opinion. > > This was probably at my suggestion. The issue here is that RFC2119 doesn't > say "must" has any different meaning than "MUST" does, so we should either > be consistant and uppercase-ize it, or use some other word. +1 for some other word. > In any event, I don't agree that this is actually a substantive change. +1, sanitizing input is part of any protocol. >> "This SPF check can only be performed when the "HELO" string is a >> valid fully qualified domain." >> >> What is a valid fully qualified domain? > > I believe it means "a name comprising a sequence of DNS labels, separated > by dot characters, which when queried resolve to an A or MX record". It > may have a proper definition in some other RFC too. Should we add one in > the Introduction or Definitions? "What is a Fully Qualified Domain Name?" is the title of Section 5.2 of RFC 1594. >> In Section 2.3: >> >> "An SPF-compliant domain MUST have valid SPF records as described in >> Section 3." >> >> As a note the RFC 4408 text is: >> >> "An SPF-compliant domain MUST publish a valid SPF record as described >> in Section 3." >> >> The RFC 2119 MUST is redundant. > > In a recent conversation, Pete described this as "not really wrong, but > it's shouting." I guess that means changing "MUST publish" to "publishes" > or something like that. +1, that would be the definition of an SPF-compliant domain. >> 'If domain owners choose to publish SPF records and want to support >> receivers making negative authorization determinations, then they MUST >> publish records that end in "-all", or redirect to other records that do, >> otherwise, no definitive determination of authorization can be made.' >> >> The document uses ADMD while there is "domain owners" in the above. I >> suggest reviewing that. > > I think they're synonymous. Going with ADMD is probably a good idea. Just mentioning that they they are synonyms, e.g. in the 1st paragraph of the introduction, might be handier to readers who are not familiar with the term. >> The RFC 2119 MUST is a substantive change. Why is this a MUST? > > It is the only way within the protocol to cause negative authorization > determinations to occur. It is an interoperability requirement. I believe > this is correct. +1, an equivalent wording could be: An SPF-compliant domain needing to support receivers making negative authorization determinations MUST... >> In Section 2.4: >> >> 'At least the "MAIL FROM" identity MUST be checked, but it >> is RECOMMENDED that the "HELO" identity also be checked beforehand.' >> >> There is already a RFC 2119 MUST in Section 2.2. There is also a RFC 2119 >> RECOMMENDED in Section 2.1. The above text restates existing RFC 2119 >> requirements or recommendations. > > I agree; the redundancy should be resolved. The cited sentence in 2.4 can > probably go. -1, Section 2.4 is the proper place to say that. Sections 2.1 and 2.2 should be just definitions. They are garbled and it's they who deserve corrections. >> 'Without explicit approval of the domain owner, checking other >> identities against SPF version 1 records is NOT RECOMMENDED because >> there are cases that are known to give incorrect results.' >> >> How should this explicit approval be sought? This recommendation does not >> make sense. > > Adding "out-of-band" or "private" after "explicit" would probably clear > this one up. How about defining the concept of (private or standard) "extension"? >> In Section 2.4: >> >> 'When a mail receiver decides to perform an SPF check, it MUST use a >> correctly-implemented check_host() function (Section 4) evaluated >> with the correct parameters.' >> >> This RFC 2119 requirement states the obvious. It basically says that >> there is a requirement in draft-ietf-spfbis-4408bis-14 to use a correct >> implementation of draft-ietf-spfbis-4408bis-14. > > I agree, that sentence can probably go. +1 >> "Implementations have to take care to correctly extract the >> from the data given with the SMTP MAIL FROM command as many MTAs will >> still accept such things as source routes ..." >> >> The definition of is: >> >> 'the domain portion of the "MAIL FROM" or "HELO" identity.' >> >> I am not sure whether it is even a definition. From an implementation >> perspective the last paragraph of Section 2.4 is unclear. > > I don't agree. I imagine by now you're aware of what this is for; can you > suggest some other text that accomplishes the intent? I don't think we need to specify how to treat archaic input. To mention it is right and proper, though. >> 'Performing the authorization other than using the return-path and >> client address at the time of the MAIL command during the SMTP >> transaction can cause problems, ..' >> >> Shouldn't that be "authorization check"? > > Yes. +1 >> 'Generating non-delivery notifications to forged identities that have >> failed the authorization check is a source of backscatter and SHOULD >> be avoided.' >> >> This RFC 2119 SHOULD is not in RFC 4408. The above does not have anything >> to do with Sender Policy Framework. It was mentioned during WG discussions >> that "SPF can help the backscatter problem" [2]. This text may have been >> introduced in response to a review [3]. Is this an enhancement or a >> clarification? > > I think it documents operational experience acquired since RFC4408 was > published. As for whether RFC2119 language is appropriate, I agree that it > isn't; it has nothing to do with SPF itself, though it is a side effect of > its use. I suggest changing SHOULD to "needs to". +1, note that both RFC 5321 (silent dropping of messages should be considered) and RFC 3464 (should take appropriate precautions) have lowercase "should". >> In Section 2.6: >> >> "An SPF verifier implements something semantically identical to the >> function defined there." >> >> John Levine commented about this during the WGLC [4]. I am listing this >> as a reminder for myself. > > I agree with John. +1 for "semantically equivalent". >> In Section 2.6.1: >> >> 'A result of "none" means either (a) no syntactically valid DNS domain >> name was extracted from the SMTP session that could be used as the >> one to be authorized, or (b) no TXT records were retrieved from the >> DNS that appeared to be intended for use by SPF verifiers.' >> >> I suggest "DNS TXT records". What is a syntactically valid DNS domain >> name? The definition of "none" in RFC 4408 is clear (to me). > > "DNS TXT records" is fine but probably not necessary at this point in the > document. +1 > We discussed the "syntactically valid" thing above. > > This definition of "none" is more precise than it was in RFC4408. The 4408 > definition was: > > A result of "None" means that no records were published by the domain > or that no checkable sender domain could be determined from the given > identity. The checking software cannot ascertain whether or not the > client host is authorized. > > This text did not account for the notion that TXT records were returned > that didn't start "v=spf1". It also wasn't clear about what "checkable" > meant. I believe the bis definition is better. +1 >> In Section 2.6.2: >> >> 'The domain owner has explicitly stated that it is not asserting >> whether the IP address is authorized. This result MUST be treated >> exactly like the "none" result; the distinction exists only for >> informational purposes.' >> >> As a note, the RFC 2119 MUST is in RFC 4408. The Introduction Section >> mentions "ADMDs can authorize hosts to use their domain names". The above >> uses "domain owner". > > Covered earlier. >> In Section 2.6.7: >> >> 'A "permerror" result means the domain's published records could not >> be correctly interpreted. This signals an error condition that >> definitely requires manual intervention to be resolved.' >> >> What is "manual intervention" in the above? > > "Operator intervention" might be more consistent with common IETF usage. Either wording tends to imply that it is clear who should do what in order to resolve the permerror. That's not always the case (e.g. multiple void lookups). >> In Section 3: >> >> 'An SPF record is a DNS record that declares which hosts are, and are >> not, authorized to use a domain name for the "HELO" and "MAIL FROM" >> identities.' >> >> How are hosts which are not authorized to use a domain name listed in a >> SPF record? > > It's implicit in that the set that is not authorized is the complement to > the set that is authorized. If we want to make it clear, we could say > "which hosts are, and thus also which are not," or something like that. Well, not authorized is "-", authorized is "+", but we cannot make it clear without mentioning the other qualifiers too. I suggest leaving that as is. >> "The SPF record is a single string of text." >> >> What is a single string of text? It may be easier to state this in terms >> of record format. > > I don't think that statement is unclear, but I agree with the improvement > suggestion. Maybe: > > "An SPF policy statement is expressed as a single string of text encoded in > a DNS TXT record." Leave off "single string" (Section 3.3 title is "Multiple Strings in a Single DNS record"). We could reuse "string of octects" from RFC 1035, e.g.: The SPF record is a variable length string of octets encoded in a DSN TXT record. >> 'ADMDs publishing SPF records SHOULD try to keep the number of >> "include" mechanisms and chained "redirect" modifiers to a minimum.' >> >> What is the minimum? Note that this RFC 2119 SHOULD is in RFC 4408. > > There isn't a specific minimum. The expression means "don't use this > technique unless you absolutely need it". Yes, that sense is conveyed with "SHOULD try" --must consider some alternative ways that result in a smaller number of include/redirect. >> 'ADMDs SHOULD also try to minimize the amount of other DNS information >> needed to evaluate a record.' >> >> This RFC 2119 SHOULD is also in RFC 4408. There are two RFC 2119 SHOULDs >> in the last paragraph of Section 3. This usage of RFC 2119 key words does >> not help the SPF "publisher". In my opinion the "SHOULD try" in this >> context uses the RFC 2119 key word in unorthodox ways. > > I agree with "SHOULD try", as that's arguably not actionable. "SHOULD > minimize" is probably fine, however. "SHOULD minimize" conflicts with one intended use, namely v=spf1 redirect=_spf.example.com Exemplified in Section 6.1, that use does not attain the minimum. >> In Section 3.1: >> >> 'SPF records MUST be published as a DNS TXT (type 16) Resource Record >> (RR) [RFC1035] only.' >> >> I would ask why "MUST be published ... only". By the way, Section 3 has a >> reference to Section 4 for record format instead of Section 3.1. Is that >> correct? > > The text is not incorrect, but it's also not necessary. Dropping "only" is > probably sufficient. +1, we don't need to stress that the other type was discontinued. > The reference is indeed incorrect. Should we say "is described along with its interpretation in Section 4.5"? How about changing the title of Section 4.5 to "Record Format"? >> In Section 3.2: >> >> "A domain name MUST NOT have multiple records that would cause an >> authorization check to select more than one record." >> >> This RFC 2119 MUST NOT was in RFC 4408. Is this to help the SPF >> "publisher" and if so, how does it help? > > I believe it is an advisory to publishers of the consequences of having > more than one "v=spf1" record published. Yup >> In Section 3.3: >> >> "As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS >> record can be composed of more than one string." >> >> See previous comment about " a single string". > > This use is correct, as it describes the fact that there are many ways to > encode a single high-level string into multiple low-level > "character-strings" as defined in RFC1035. +1, but I wouldn't mention the level of strings in the I-D... >> "If a published record contains multiple character-strings, then the >> record MUST be treated as if those strings are concatenated together >> without adding spaces." >> >> This RFC 2119 MUST is also in RFC 4408. I suggest removing the "MUST" in >> the example. > > I disagree. It's required for interoperability. +1, are there DNS libraries that do otherwise? >> "TXT records containing multiple strings are useful in constructing >> records that would exceed the 255-byte maximum length of a character- >> string within a single TXT record." >> >> I suggest using "octet" instead of "byte". I'll point the working group >> to CVE-2008-2469 in case it might wish to consider that issue. > > How is an octet different from a byte in this context? This strikes me as > a stylistic issue at best. +1 for s/byte/octet/, even if it's stylistic: The size of the byte has historically been hardware dependent and no definitive standards existed that mandated the size. http://en.wikipedia.org/wiki/Byte >> In Section 4: >> >> "A compliant SPF implementation MUST do something semantically >> equivalent to this description." >> >> It's unusual to see a "do something" RFC 2119 requirement in a >> specification. Is the SPFBIS WG working on compliance for SPF >> implementations? > > RFC6376 is an example of a standards track document that uses RFC2119 MUST > in this way. I'm sure I've seen others but I can't think of them at this > hour. I think it's fine. Would it be better to s/do something/behave in a way/? >> "Mail receivers that perform this check MUST correctly evaluate the >> check_host() function as described here." >> >> Where does "mail receivers" fit in the Sender Policy Framework? The "MUST >> correctly evaluate" is stating the obvious. > > I'm not understanding how the answer to the first question isn't obvious. > > I agree with the second point. I propose to remove that sentence. >> "Implementations MAY use a different algorithm than the canonical >> algorithm defined here, so long as the results are the same in all >> cases." >> >> Why is this a RFC 2119 MAY? I am aware that the text is in RFC 4408. > > This seems to me to be another stylistic question, since MAY in RFC2119 > terms doesn't mean much. It helps understanding the previous MUST, they are two poles that implementations have to stay in between. >> In Section 4.1: >> >> ' - the domain that provides the sought-after authorization >> information; initially, the domain portion of the "MAIL >> FROM" or "HELO" identity.' >> >> The above text is different from the text in Section 2.4. > > I think I agree; I would prefer to have it defined in one place, and have > other points in the document reference it. +1, Section 2.4 can refer to Section 4.1. However, Section 2.4 needs to mention how the parameter should be set in each of the checks. >> In Section 4.3: >> >> "If the is malformed (e.g. label longer than 63 characters, >> zero-length label not at the end, etc.)" >> >> That should be "octets". > > Since the DNS is all in ASCII, they're synonymous. That said, we may as > well be consistent. Yeah, but ASCII is 7-bit... >> "Properly formed domains are fully qualified email domains as >> described in [RFC5321] Section 2.3.5." >> >> What are "properly qualified email domains"? > > Is the reference defining that term not appropriate? IMHO the reference is fine. The term "email domain" lacks a formal definition, and is used improperly in Section 4.3 since HELO needs not be an email domain in some sense. I'd s/fully qualified email domains/fully-qualified domain names/. >> "Internationalized domain names MUST be encoded as A-labels, as >> described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]." >> >> I'm listing the above and leave it to Area Director guidance. Please note >> that it is a new RFC 2119 requirement. > > I'm pretty sure RFC4408 pre-dates most of the IDN work, so this is a > modernization step. I think it's important to include, and it also does > the same thing DKIM did, which is now Draft Standard. If we don't, there's > no guidance for use of SPF in the IDN context. The alternative is to spin > up another document (which we're not chartered to do) that discusses use of > SPF in the IDN context. Fully agree with Murray. However, it is not layer-wise clear whether any A-label conversion is to be carried out as initial processing within check_host(). >> In Section 4.4: >> >> "In accordance with how the records are published (see Section 3 >> above), a DNS query needs to be made for the name, querying >> for type TXT only." >> >> I don't understand the sentence. > > Query the HELO domain or the MAIL FROM domain, as described in Section 3. In this case, I'd keep the trailing "only" as is. >> 'Alternatively, for a server failure (RCODE 2) result, check_host() >> MAY track failures and treat multiple failures within 24 hours for >> the same domain as "permerror".' >> >> This text is not in RFC 4408. I found a note in Issue #1 [5] and in a >> message [6]. > > Are there any implementations that do this? If so, that's the > justification; it's practical experience. If not, we should consider > dropping it. +1 for dropping it. This would be needed for type 99, where bad firewall rules could produce effects similar to network errors except that they'd never get resolved. For "normal" SERVFAIL cases, the meaning of temperror as derived from RFC 2308 is just fine. >> In Section 4.6.2: >> >> "If there are no more mechanisms, the result is specified in >> Section 4.7." >> >> This sentence does not make sense. > > How about: "After all mechanisms have been processed and no matches are > found, the result is determined according to Section 4.7." +1, better style. >> "If this number is exceeded during a check, a permerror MUST be returned." >> >> I read this as if an implementation-specific limit is reached a permerror >> is returned. There are two RFC 2119 MUST in the above. That can be >> reduced to one MUST. > > I'm not sure I agree. SecDir has pushed the fixed query limit on other > topics in the past, which is the first MUST, and the second MUST prescribes > a specific result that has to occur when the limit is reached which is > important for interoperability. +1, while it is possible to say "MUST return permerror if more than 10", the resulting text would be less readable. >> 'MTAs or other processors SHOULD impose a limit on the maximum amount >> of elapsed time to evaluate check_host(). Such a limit SHOULD allow >> at least 20 seconds. If such a limit is exceeded, the result of >> authorization SHOULD be "temperror".' >> >> There are three RFC 2119 SHOULDs in the above. I suggest rewriting the >> text to reduce that. > > All three of them seem to be important interoperability points. We could > common factor the SHOULD and then present three bullets in a list, but the > meaning is the same. +1, for the same readability reason. >> 'SPF implementations SHOULD limit "void lookups" to two.' >> >> What are void lookups? > > Last paragraph of Section 4.6. >> "In this case, a default of two is RECOMMENDED." >> >> Why is "two" recommended? > > Interoperability; if one is two while another is 10, different SPF results > can be returned. This is a protocol change, marked as such in Appendix C, 2nd bullet. >> 'Note that records SHOULD always use either a "redirect" modifier or >> an "all" mechanism to explicitly terminate processing.' >> >> Why is there a RFC 2119 key word in a note? > > Since the explanation I've been given is that it's better for human > debugging, I think I agree since the advice is not specific to the protocol > itself. Scott removed the "Note that". >> In Section 4.8: >> >> 'e.g., "foo..example.com") or overlong labels (more than 63 >> characters).' >> >> I suggest octets. > > Again, synonymous. +1 for SM, again. >> in Section 5: >> >> 'SPF implementations on IPv6 servers need to handle both "AAAA" and "A" >> secords, for clients on IPv4 mapped IPv6 addresses [RFC4291].' >> > >> There is a typo, "records". >> >> I'll flag the above for review by people with IPv6 expertise. > > This was covered in a different thread. I believe a proposed text fix was > made that people seemed to like. >> In Section 5.3: >> >> 'a = "a" [ ":" domain-spec ] [ dual-cidr-length ]' >> >> "dual-cidr-length" is introduced in this sub-section. I had to search >> through the draft to find out what it means. > > That happens sometimes. :-) >> In Section 5.4: >> >> 'Note regarding implicit MXs: If the has no MX records, >> check_host() MUST NOT pretend the target is its single MX, and MUST >> NOT default to an A or AAAA lookup on the directly.' >> >> There are two RFC 2119 MUSTs in the above. This is over-usage of RFC 2119 >> key words. This text was in RFC 4408. This is not a divergence from RFC >> 5321, it is a contrary to Section 5 of RFC 5321. > > I believe the advice should remain, but it could be simplified: > > "Note regarding implicit MXes: If the has no MX records, > check_host() MUST NOT apply the implicit MX rules of RFC5321 by querying > for an A record for the same name." +1, s/A/A or AAAA/ >> In Section 5.5: >> >> "This mechanism SHOULD NOT be used." >> >> I suggest providing a reason for this. > > The very next sentence is "See below for discussion." >> "To prevent DoS attacks, more than 10 PTR names >> MUST NOT be looked up during the evaluation of a "ptr" mechanism >> (see Section 4.6.4)." >> >> The above restates a previous RFC 2119 MUST. > > Agreed. +1, since we collected those limits. I propose to replace the second sentence in that bullet with something like: This is where to apply the rule of Section 4.6.4 to ignore records other than the first 10. >> "If used, proper PTR records MUST be in place for the domain's hosts >> and the "ptr" mechanism SHOULD be one of the last mechanisms checked." >> >> Those RFC 2119 key words are not in RFC 4408. I don't see how this RFC >> 2119 change qualifies as a clarification or explanation. > > It was "must" vs. MUST in RFC4408. It's otherwise unchanged. >> "It is, however, still in use and part of the SPF protocol, so compliant >> check_host() implementations MUST support it." >> >> What is a compliant check_host() implementation? > > One that complies with this specification. >> In Section 5.6: >> >> "ip6-network = " >> >> I suggest that the above reference be verified for correctness. > > Looks right to me. The CIDR expression is in the optional token next to > it, so this has to be just a plain IPv6 address, so that's the right > reference. I'd rather import IPv6address and IPv4address from http://tools.ietf.org/html/rfc3986#section-3.2.2 >> In Section 5.7: >> >> 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{**d} -all' >> >> I'll flag this for review by DNS folks. > > What's the specific question being asked of DNSDIR here? >> In Section 6: >> >> 'The modifiers defined in this document ("redirect" and "exp") MAY >> appear anywhere in the record, but SHOULD appear at the end, after >> all mechanisms.' >> >> This text is in RFC 4408. I would label the RFC 2119 usage as defective. > > Why? >> In Section 6.2: >> >> "Since the explanation string is intended for an SMTP response and >> [RFC5321] Section 2.4 says that responses are in [US-ASCII], the >> explanation string MUST be limited to US-ASCII.' >> >> It would be easier to defer to RFC 5321 instead of setting a RFC 2119 >> requirement in this draft. I note that this requirement was not in RFC >> 4408. > > I agree that this could be expressed non-normatively (e.g. "needs to be"). -1, it means the value of "exp" must be ASCII. >> "Software SHOULD make it clear that the explanation string >> comes from a third party." >> >> I could not understand what that means in RFC 2119 terms. The draft uses >> RFC 2119 key words by example instead of providing an explanation. > > I agree; we're talking about interoperability between humans here, and not > between implementations. +1, something like "implementers are advised to make it clear..." >> In Section 7.1: >> >> 'The "toplabel" construction is subject to the LDH rule plus >> additional top-level domain (TLD) restrictions.' >> >> Where can I find these restrictions? Please note that I have read the >> Informational RFC. > > I'm pretty sure it's referring to common TLD conventions. The "LDH rule" is explained in the Informational RFC. It is the Letter-Digit-Hyphen convention defined in RFC 952 and later modified by RFC 1123 [http://www.icann.org/en/node/1145376] >> in Section 10: >> >> "This section is not a "how-to" manual, or a "best practices" document, >> and it is not a comprehensive list of what such entities SHOULD do in >> light of this document." >> >> What is the meaning of the RFC 2119 SHOULD in the above? > > Agreed, it's inappropriate here. I think Scott removed it already. >> In Section 10.1.2: >> >> "Publishing SPF records for domains that send no mail is >> a well established best practice." >> >> I am not aware of that best practice. I did a few DNS queries: >> >> ;; QUESTION SECTION: >> ;bing.com. IN TXT >> >> ;; ANSWER SECTION: >> bing.com. 3600 IN TXT "v=msv1 >> t=6097A7EA-53F7-4028-BA76-**6869CB284C54" >> >> ;; QUESTION SECTION: >> ;com.com. IN TXT >> >> ;; ANSWER SECTION: >> com.com. 293 IN TXT "google-site-verification:** >> esSnoZdChIkkfCfS9MMgqNhE0yaXfn**nZWdZPuBf7e8k" >> > > What are you saying here? This is an existence proof of non-mailing > domains that don't publish SPF records, but it doesn't contradict the > statement made in the draft. It doesn't mean there's a BCP. s/best/good/? >> In Section 13.1: >> >> "The format of this type is identical to the TXT RR [RFC1035]" >> >> The format is not identical, i.e. it's a different RR. I suggest keeping >> the IANA Considerations Section simple, i.e. clearly explain to IANA what >> action is requested. > > The format is indeed identical, right down to the octet. The format of RDATA, that is. I'd leave the definition of the obsolete type with the obsolete RFC 4408. >> In Section E.1: >> >> 'This would cause a lookup on an DNS white list (DNSWL) and cause a >> result of "fail" only for email not either coming from the >> domain's mx host(s) (SPF pass) or white listed sources (SPF >> neutral).' >> >> I didn't find any discussion about this on the SPFBIS mailing list. is >> there an explanation for this change between RFC 4408 and this draft? > > It was in 9.3 in the previous document and has been reworded a little. > It's otherwise unchanged. See http://www.ietf.org/mail-archive/web/spfbis/current/msg02276.html >> In Appendix I: >> >> Appendix I is about "Protocol Status". This draft is intended as a >> Proposed Standard. From an IETF perspective that is what it will be. >> Describing it as something different can be misleading. >> >> "[RFC4408] was designed to clearly document the protocol defined by >> earlier draft specifications of SPF as used in existing >> implementations. This updated specification is intended to clarify >> identified ambiguities in [RFC4408], resolve techincal issues >> identified in post-RFC 4408 deplyment experience, and document widely >> deployed extensions to SPF that have been developed since [RFC4408] >> was published." > > There are two typos in there (techincal, deplyment). >> Extensions to the SPF protocol are clearly mentioned in the charter as >> being out of scope. The "document widely deployed extensions" is >> problematic. > > Agreed. Yes, in some sense. I'd s/extensions/changes/. From SRS0=V8mI1=OQ==stuart@gathman.org Mon Apr 29 08:45: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 3CA3221F9E25 for ; Mon, 29 Apr 2013 08:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itNEC1N2spVb for ; Mon, 29 Apr 2013 08:45:20 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 7121621F9E24 for ; Mon, 29 Apr 2013 08:45:20 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1367250338; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=75vMaz2G5O+TOOIFDH7dgP87DwvR8zRnbE/qQp0xNeU=; b=K3OjpF2BAXLDGFhZCfMcZzAUryojPKUDrYhuGRFK/eTym8rzP50CGh5jYvbDLZWpls9wHc jD+VLN7yOacNxGwHltXcGNpO+GwD9kFEwiMuyrTChIIm28Ww4t7uRgAxwkhWglkTUcDclR1D M3nlTo03FaCyYn0tJWI9t77QkcIos= Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r3TFjb1W007411 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 29 Apr 2013 11:45:38 -0400 Message-ID: <517E958F.50709@gathman.org> Date: Mon, 29 Apr 2013 11:45:19 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179C72F.1070703@dougbarton.us> <517E8895.1020609@tana.it> In-Reply-To: <517E8895.1020609@tana.it> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 15:45:21 -0000 Long ago, Nostradamus foresaw that on 04/29/2013 10:49 AM, Alessandro Vesely would write: > > Maintaining spf records --whether SPF or TXT-- is a pain in the first > place, especially for larger organizations that have lots of IP > addresses and internal chains of responsibility delegation. An > annoying feature is the recommendation to stay within UDP size limit, > which forces to use included records containing several lists of > addresses each. > > Asking to duplicate the records on top of that is not a trivial > request. There are no automated tools that duplicate records to > different type, and if RR types make any sense at all, I'd guess there > will never be. There are domains with SPF and TXT records different > from one another, hence the possibility to introduce errors or > inaccuracies is non-zero. On the other hand, the domain maintainer > gets zero advantages. They just wont' do it, people would rather > stop using spf than mess it up with double records. Is that a > technical argument? > RFC 4408 has said SHOULD publish both SPF and TXT for many years now. As Mark Andrews pointed out, an equally simple way to avoid the duplication is to say SHOULD publish *only* SPF. That still leaves leeway for checkers to check TXT. As long as there is a practical workaround for the braindead DNS server/firewall problem, there is no reason *not* to do this. Very *un*technical observation: I was so pleased when upgrading mail servers to RHEL6 - the supported BIND *finally* has the SPF keyword! I had been running scripts to generate hex coded TYPE99 records for older BIND versions. How disappointed I was to shortly afterwards read that SPFBIS was dropping SPF entirely! :-( From vesely@tana.it Mon Apr 29 09:00: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 1B05821F9E44 for ; Mon, 29 Apr 2013 09:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsopOtdsoRyB for ; Mon, 29 Apr 2013 09:00:19 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CE87021F9E3B for ; Mon, 29 Apr 2013 09:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367251216; bh=vYb7gKxv7Rj1pXq9/Gw6RkCTiQ6QVhXo1b/JjILmOIA=; l=1114; h=Date:From:To:CC:References:In-Reply-To; b=BCE5vAkblOPBPEhN8GfGCfN7m0tIUkJRuZ4O2QrqkAF/0nGQpuscypZc8pd9D70sr r19LFC88IbYQqBFU3/H4jkJoXfVmyD4JGISybg8/bp7Fs7doFrSZyzUqr399imDIR4 LpAIbAao+2X6rSCLjYWctkAoFYgicMPuo6BNsGoo= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 29 Apr 2013 18:00:16 +0200 id 00000000005DC042.00000000517E9910.000023A6 Message-ID: <517E9910.3050602@tana.it> Date: Mon, 29 Apr 2013 18:00:16 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <20130429034026.GB27654@besserwisser.org> <20130429050236.0B5DA3327423@drugs.dv.isc.org> In-Reply-To: <20130429050236.0B5DA3327423@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 16:00:21 -0000 On Mon 29/Apr/2013 07:02:35 +0200 Mark Andrews wrote: > > New types have been added very year or so for the life of the DNS: > > Base spec 1987, RP 1990, X25 1990, ISDN 1990, RT 1990, AFSDB 1990, > NSAP 1992, GPOS 1994, AAAA 1995, LOC 1996, SIG 1997, KEY 1997, NXT > 1997, KX 1997, PX 1998, DNAME 1999, ATMA 2000, OPT 2001, APL 2001, > DS 2003, DNSKEY 2004, RRSIG 2004, NSEC 2004, PSECKEY 2005, SSHFP > 2006, CERT 2006, SPF 2006, DLV 2006, NSEC3 2008, NSEC3PARAM 2008, > HIP 2008, URI 2011, TLSA 2012, NID 2012, L32 2012, L64 2012, EUI48 > 2013, EUI64 2013. > > Some of those record are infrequently used but others are wildly > deployed and used including behind firewalls inspect DNS record > contents. May I ask how many of those types have a TXT equivalent? A good deal of this thread assumes that TXT records are bad. Would anyone say why? I read RFC 5507, and I'd agree that not using a prefix such as _spf creates unneeded conflicts. However, I'm unable to understand the reasons why "TXT is evil". Do we need to create new types whenever the use changes, as we do file extensions? From presnick@qti.qualcomm.com Mon Apr 29 09:10: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 B2A1221F9E3E for ; Mon, 29 Apr 2013 09:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-nAH6yi1-Pj for ; Mon, 29 Apr 2013 09:10:18 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id E37AA21F9E3C for ; Mon, 29 Apr 2013 09:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1367251817; x=1398787817; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=x50F6t0KkdI3gK/Gr2PLAm1FCqlmSPkZIP64xu6ruBI=; b=yy8wnnfzpi9KQF+BlRMGMlhORBlTruBlrwtE/V4/g4eeTsEZg9ct6rA+ Ixqsf9U7lj7kCxghveQFlO2y28hLm7J6NBlnNI/tu5QvO/CUeVaW97P0y SMjEJP8aa3fGOV9LOa9IDl6B212juc0PkdUXDiltfWMN7mrFAUtyoadt9 g=; X-IronPort-AV: E=Sophos;i="4.87,574,1363158000"; d="scan'208";a="37231124" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 29 Apr 2013 09:10:16 -0700 X-IronPort-AV: E=Sophos;i="4.87,574,1363158000"; d="scan'208";a="440255439" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Apr 2013 09:10:15 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 29 Apr 2013 09:10:14 -0700 Message-ID: <517E9B64.80605@qti.qualcomm.com> Date: Mon, 29 Apr 2013 11:10:12 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <517E856A.6060205@dcrocker.net> In-Reply-To: <517E856A.6060205@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: "spfbis@ietf.org" , Dave Crocker , "Murray S. Kucherawy" , S Moonesamy Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 16:10:18 -0000 On 4/29/13 9:36 AM, Dave Crocker wrote: > On 4/29/2013 1:21 AM, Murray S. Kucherawy wrote: > >>> 'Note that requirements for the domain presented in the EHLO or HELO >>> command are not always clear to the sending party, and SPF >>> verifiers >>> MUST be prepared for the "HELO" identity to be malformed or an IP >>> address literal.' >> >> This RFC 2119 "MUST" is not in RFC 4408. It is a substantive change >> in my opinion. >> >> This was probably at my suggestion. The issue here is that RFC2119 >> doesn't say "must" has any different meaning than "MUST" does, so we >> should either be consistant and uppercase-ize it, or use some other >> word. >> >> In any event, I don't agree that this is actually a substantive change. > > +1. 2119 terms are case-insensitive. That 2119 terms are case-insensitive is at least a controversial claim. And if I were doing a review, my concern here would be that 4408 could have meant "must" colloquially and not as a 2119 requirement. Whether it's a substantive change or not comes down to how it was originally intended. It seems to me that interpreting the above as 2119 language is a bit weird: This is in a sentence that starts "Note that...", which doesn't seem terribly requirement laden. Also "MUST be prepared" is a weird construct: MUSTs are normally instructions for protocol actions or implementation coding, and "be prepared" seems like an odd one of those. And of course, was this intended as a new requirement of SPF, or was it just reiterating something from SMTP? If the latter, that would sound like the "must" was meant colloquially and "need to" might be a reasonable substitute. As many of you know, 2119 misuse is a pet peeve of mine, so I presume SM was going through looking for things that might pique my interest. But I have already decided that when I do my "Ready to go to Last Call" AD review, I am going to explicitly ignore 2119 misuse when (a) it was in 4408 already and (b) won't cause serious problems. So it's only changes to the text of 4408 when 2119 terms are used that are going to get any "are they using it right?" scrutiny. If SM has identified any of those, an explanation would be useful. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From hsantos@isdg.net Mon Apr 29 09:30: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 929BB21F9DBD for ; Mon, 29 Apr 2013 09:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NReKBuLWS4+m for ; Mon, 29 Apr 2013 09:30:09 -0700 (PDT) Received: from groups.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A3FE521F9DB8 for ; Mon, 29 Apr 2013 09:30:08 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2414; t=1367252998; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=QkFMNVb jHmmjqYdiz91IgwrlF9o=; b=GhVe2MWHAsr58xSGf3BS6C8FKD5i19e3CCApsK5 BXv2Z2lytqzxc9pFXTdgJ+ga6KzXHF5/IXzUiyCHeIpwuiNaLQzwZVNtbh4qQiDb VUbfrXdIAYXgDDjPGLFxn9bPAfIDSlW+UPuPMeo3qN18gywEIbguE5DAWD3nD0xY z+h4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 29 Apr 2013 12:29:58 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1751715853.5068.5656; Mon, 29 Apr 2013 12:29:57 -0400 Message-ID: <517E9FB0.5020807@isdg.net> Date: Mon, 29 Apr 2013 12:28:32 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> In-Reply-To: <517E90A6.6090108@gathman.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 16:30:10 -0000 Exactly, and it all be done with a installation wizard by the implementation package. It can do do a test and spit out a warning: +-[ SPF Setup Check ]-------------------------------------------+ | | | Your DNS resolver does not appear to support SPF RRTYPE | | and/or unnamed types processing. Your setup will default to | | TXT only SPF queries. | | | | [OK] [CANCEL] [RETRY] | +---------------------------------------------------------------+ Keep in mind issues will be random and based on the path a DNS client takes. This is really not a big thing. We are making it a big thing. The goal of the functional specs is to spell it all out for the developers to decide what to do. But also we really do need to get a handle on what exactly are the barriers here: DNS Servers? DNS Proxies at NATs, Routers? Firewalls? Overall, recursive queries need to support a passthru concept for unnamed types. Thats the problem I believe overall, that even your own local resolvers is supportive, there could be an uplink that doesn't/ That was I recall seeing even with SRV support. Even XMPP had a dual discovery concept and I recall the many earlier failures and fall backs to A records logged. Overtime, it finally began to work better. -- HLS On 4/29/2013 11:24 AM, Stuart Gathman wrote: > Long ago, Nostradamus foresaw that on 04/28/2013 07:25 PM, Ted Lemon > would write: >> On Apr 28, 2013, at 7:06 PM, Stuart Gathman wrote: >>> For this implementer, it was because I didn't think of it (until night before last), and apparently no one else did either. If I had thought of it (keeping track of known broken nameservers) back in 2005, it would have worked much better to try SPF first (except for known broken nameservers). It was just so much easier to try TXT first to get the mail flowing. I am kicking myself! >> So you don't mind keeping the state around for 90 seconds? > The idea is that you endure the TIMEOUT the first time only. If a TXT > query then succeeds, you know you are dealing with a braindead > server/firewall, and record the domain and timestamp in a database. > You check the database before making any SPF (type 99) query to avoid > trying known braindead servers. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From dhc@dcrocker.net Mon Apr 29 09:34: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 625AE21F9E26 for ; Mon, 29 Apr 2013 09:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AZNOC90LTC4 for ; Mon, 29 Apr 2013 09:34:53 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0BE21F9E1F for ; Mon, 29 Apr 2013 09:34:53 -0700 (PDT) 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 r3TGYb8M032066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Apr 2013 09:34:40 -0700 Message-ID: <517EA118.5000800@dcrocker.net> Date: Mon, 29 Apr 2013 09:34:32 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pete Resnick References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <517E856A.6060205@dcrocker.net> <517E9B64.80605@qti.qualcomm.com> In-Reply-To: <517E9B64.80605@qti.qualcomm.com> 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.66]); Mon, 29 Apr 2013 09:34:40 -0700 (PDT) Cc: "spfbis@ietf.org" , "Murray S. Kucherawy" , S Moonesamy Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 16:34:54 -0000 On 4/29/2013 9:10 AM, Pete Resnick wrote: > On 4/29/13 9:36 AM, Dave Crocker wrote: >> On 4/29/2013 1:21 AM, Murray S. Kucherawy wrote: >> >>>> 'Note that requirements for the domain presented in the EHLO or HELO >>>> command are not always clear to the sending party, and SPF >>>> verifiers >>>> MUST be prepared for the "HELO" identity to be malformed or an IP >>>> address literal.' >>> >>> This RFC 2119 "MUST" is not in RFC 4408. It is a substantive change >>> in my opinion. >>> >>> This was probably at my suggestion. The issue here is that RFC2119 >>> doesn't say "must" has any different meaning than "MUST" does, so we >>> should either be consistant and uppercase-ize it, or use some other >>> word. >>> >>> In any event, I don't agree that this is actually a substantive change. >> >> +1. 2119 terms are case-insensitive. > > That 2119 terms are case-insensitive is at least a controversial claim. > And if I were doing a review, my concern here would be that 4408 could > have meant "must" colloquially and not as a 2119 requirement. Whether > it's a substantive change or not comes down to how it was originally > intended. As you know, I'm a fan of using the vocabulary only normatively, specifically to avoid both the controversy and, more importantly, possible/likely reader confusion: http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119-02 > It seems to me that interpreting the above as 2119 language is a bit > weird:This is in a sentence that starts "Note that...", which > doesn't My overriding point on this topic is that making the interpretation of normative vocabulary be context sensitive in stupidly fragile for a standards organization. So the fact that your otherwise reasonable analysis relies on a reader's needing to realize that it doesn't make "sense" to treat the words as normative strikes me as the core problem. This is in a sentence that starts "Note that...", which doesn't > seem terribly requirement laden. Also "MUST be prepared" is a weird > construct: MUSTs are normally instructions for protocol actions or > implementation coding, and "be prepared" seems like an odd one of those. Well, I thoroughly agree that normative language needs to specify something concrete. Using such language to direct vague awareness or action that has no specific details isn't specifying. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Mon Apr 29 09: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 BAB5721F9DCC for ; Mon, 29 Apr 2013 09:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5TAy0dKK6DS for ; Mon, 29 Apr 2013 09:41:32 -0700 (PDT) Received: from groups.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 986F821F9DC5 for ; Mon, 29 Apr 2013 09:41:31 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2762; t=1367253681; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=ju4qtp0 sr3pB5JjQnT36NuzOi50=; b=X6F93pkHlJQjlrqFUDx1uubZvwcLKI16UrASceO k8tK6W9kNV3eoknMmynX0sWRq0S1T/mriw4fzfE5WtcX4WBmo0OrxOj2PJfpFszT M5iyOdlXKnGVS+BfhslmCQyQVVw9NpCcTOb9QI9388HxyWSvh/Fy9o74Hb0mIhS6 crf8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 29 Apr 2013 12:41:21 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1752398934.5068.5716; Mon, 29 Apr 2013 12:41:20 -0400 Message-ID: <517EA25B.1050607@isdg.net> Date: Mon, 29 Apr 2013 12:39:55 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pete Resnick References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <517E856A.6060205@dcrocker.net> <517E9B64.80605@qti.qualcomm.com> In-Reply-To: <517E9B64.80605@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , Dave Crocker , "Murray S. Kucherawy" , dcrocker@bbiw.net, S Moonesamy Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 16:41:32 -0000 It sure would be nice if we can apply common-sense (software) engineering and not get bogged down on semantics all in the name of enforcing, or not, things! Look at it this way, unless your mail or page reader has a SFI (Speech Friendly Interface) technology where it will YELL the uppercase words, the visually impaired won't know (or not won't care of) the difference between must and MUST. -- HLS On 4/29/2013 12:10 PM, Pete Resnick wrote: > On 4/29/13 9:36 AM, Dave Crocker wrote: >> On 4/29/2013 1:21 AM, Murray S. Kucherawy wrote: >> >>>> 'Note that requirements for the domain presented in the EHLO or HELO >>>> command are not always clear to the sending party, and SPF >>>> verifiers >>>> MUST be prepared for the "HELO" identity to be malformed or an IP >>>> address literal.' >>> >>> This RFC 2119 "MUST" is not in RFC 4408. It is a substantive change >>> in my opinion. >>> >>> This was probably at my suggestion. The issue here is that RFC2119 >>> doesn't say "must" has any different meaning than "MUST" does, so we >>> should either be consistant and uppercase-ize it, or use some other >>> word. >>> >>> In any event, I don't agree that this is actually a substantive change. >> >> +1. 2119 terms are case-insensitive. > > That 2119 terms are case-insensitive is at least a controversial claim. > And if I were doing a review, my concern here would be that 4408 could > have meant "must" colloquially and not as a 2119 requirement. Whether > it's a substantive change or not comes down to how it was originally > intended. > > It seems to me that interpreting the above as 2119 language is a bit > weird: This is in a sentence that starts "Note that...", which doesn't > seem terribly requirement laden. Also "MUST be prepared" is a weird > construct: MUSTs are normally instructions for protocol actions or > implementation coding, and "be prepared" seems like an odd one of those. > And of course, was this intended as a new requirement of SPF, or was it > just reiterating something from SMTP? If the latter, that would sound > like the "must" was meant colloquially and "need to" might be a > reasonable substitute. > > As many of you know, 2119 misuse is a pet peeve of mine, so I presume SM > was going through looking for things that might pique my interest. But I > have already decided that when I do my "Ready to go to Last Call" AD > review, I am going to explicitly ignore 2119 misuse when (a) it was in > 4408 already and (b) won't cause serious problems. So it's only changes > to the text of 4408 when 2119 terms are used that are going to get any > "are they using it right?" scrutiny. If SM has identified any of those, > an explanation would be useful. > > pr > From johnl@iecc.com Mon Apr 29 10:13: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 C7E3321F9E74 for ; Mon, 29 Apr 2013 10:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.466 X-Spam-Level: X-Spam-Status: No, score=-108.466 tagged_above=-999 required=5 tests=[AWL=2.733, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vjGNocII0H6 for ; Mon, 29 Apr 2013 10:13:07 -0700 (PDT) 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 4105721F9E70 for ; Mon, 29 Apr 2013 10:13:07 -0700 (PDT) Received: (qmail 29293 invoked from network); 29 Apr 2013 17:13:06 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Apr 2013 17:13:06 -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; s=517eaa22.xn--hew.k1304; i=johnl@user.iecc.com; bh=UiJi0EJiKMZD77l7YtVq2RCfeMy1QNqpqGM+ZIx6znk=; b=B10QVTnHgU0NP7esTPvVWd/7oQ2tvVtqS1rFcEMk6cEqrxzCyj759rXzyXJZbYBzHXPo3QrcSNGTkE6V7395Ye62Z4B6/payni9vt5HEov9aYwgbOwKfBD4VF7M31WMFl2arIoNlH+mhsvFpHXSfEIx8j897B/s71UtER+G/ZhU= 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; s=517eaa22.xn--hew.k1304; olt=johnl@user.iecc.com; bh=UiJi0EJiKMZD77l7YtVq2RCfeMy1QNqpqGM+ZIx6znk=; b=3U5svitREvqsncxZznOXicxuVch8lA+29wVmmWL5mfvejmwXj4Xyq6NTiQCCoOLezQx5FtMp/GCQXqivEKnTxdAyEsF2fSbUCGowqryl82BuX8A5DYWCzlTtCYuWlyQh1O/ELSq1oA9cgyShhtOJg4CYkcG8mlqfmysnP6iHGss= Date: 29 Apr 2013 17:12:44 -0000 Message-ID: <20130429171244.7471.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <517E9B64.80605@qti.qualcomm.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: presnick@qti.qualcomm.com Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 17:13:12 -0000 >>>> MUST be prepared for the "HELO" identity to be malformed or an IP >>>> address literal.' >>> >>> This RFC 2119 "MUST" is not in RFC 4408. It is a substantive change >>> in my opinion. Seems to me it's simply stating a fact -- clients can legitimately send an IP address and a broken client can send any random garbage in the HELO, so deal with it. It's certainly not a change in the protocol, just advice to avoid software crashes. On the other hand, it is generally the case that competent software libraries do sanity checks on all of their input, so I don't see any compelling reason to call out this case. I don't see any warnings in the MAIL FROM section about how to deal with garbage like this: MAIL FROM: R's, John From sm@elandsys.com Mon Apr 29 10:15: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 EA15821F9E7C; Mon, 29 Apr 2013 10:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UcMMURzvdWD; Mon, 29 Apr 2013 10:15:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6148021F9E82; Mon, 29 Apr 2013 10:15:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3THEj5N027607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Apr 2013 10:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367255697; bh=rsfIQIkYHEBklJVkMy7mHNQrjWIPTgZ1QCX4vkKRnEs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=L1BZrhYub271HjG287Q/Ltl3c2muKI4Tj1zNt0nMN2yEWoyTwlptTt/rr1FNZLljf VhHIHXvW94fSv1P+m+uVdSIXG4C3Cy/6a2P4YYEW4emIVStRkMPXAGwZYw2n1HSg87 XUm/rA07rvXiJ69ZPQisC4PZq67ExdkYOAxkZYS0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367255697; i=@elandsys.com; bh=rsfIQIkYHEBklJVkMy7mHNQrjWIPTgZ1QCX4vkKRnEs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HJ4KbP8FqtDDUYqVcIyfizpstGBHxocRjMVGJLBVmARqQQU1MCAQ+J0fVjG9Lw6DA 9FFrCdocd791Zh/zzigFWkLgrDg8ZMv/Udlg6wd8PWOy0U0IoYs83fdgKoodiKQD4U BZfV3RZS3vCE7/FzE3GxVZ61fcF1jT0h6MQddLnA= Message-Id: <6.2.5.6.2.20130429100907.0d0cab88@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 29 Apr 2013 10:14:28 -0700 To: Meral Shirazipour From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, gen-art@ietf.org Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 17:15:05 -0000 Hi Meral, Thanks for the review. I am forwarding it to the SPFBIS mailing list for discussion. I'll email you in a few days to address your comments. Regards, S. Moonesamy (as document shepherd) At 08:53 29-04-2013, Meral Shirazipour wrote: >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please see the FAQ at >http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >. > >Please resolve these comments along with any other Last Call >comments you may receive. > >Document: draft-ietf-spfbis-4408bis-14 >Reviewer: Meral Shirazipour >Review Date: 2013-04-29 >IETF LC End Date: 2013-04-30 >IESG Telechat date: NA > > > >Summary: >This draft is almost ready to be published as Informational RFC but >I do have some comments. > > >Nits/editorial comments: >-[Page 6] Section "1.1.2. Imported Definitions" >Please consider expanding acronyms and giving the section of the RFC >where each term is defined. >(Also throughout the document it would greatly help the readability >if acronyms are expanded when first used.) > >-[Page 8] Section 2.2. Line 1: >""MAIL FROM" -> extra \" > >-[Page 13], Section 3.3. , first line: "sections 3.3.14 and 3.3". >If both subsection and subsubsection are to be mentioned, please >consider: "sections 3.3 and 3.3.14" > >-[Page 16], Section 4.3, paragraph 1, last sentence: extra text/typo >to be removed: "on 2.3 of [RFC5890]." > >-[Page 16], Section 4.4, paragraph 3,"[RFC2308] suggests on an" >--remove "on"--> "[RFC2308] suggests an" > >-[Page 21], Section 5.1, line 1, >"This section defines two types of mechanisms." --for clarity--> >"This section defines two types of mechanisms: basic and designated sender." > >-[Page 21], second paragraph before last, " both "AAAA" and "A" >secords "--typo--> "records" > >-[Page 22], Section 5.2, point 3, please review "include: >mechanism" and "\"fail ". >Suggestion: instead of "gives a pass" or "gives a fail" is it better >to say "signifies" or "represents" as pass/fail? > >-[Page 22], second paragraph before last, >"Only the evaluated result of the referenced SPF record is used, >rather than acting as if the referenced SPF >record was literally included in the first." >The part after the comma in this sentence is hard to understand. >Please review if possible. > >-[Page 24], Section 5.4, >"the evaluation terminated"--missing is-->"the evaluation is terminated" >"has no MX records"--no s-->"has no MX record" > >-[Page 26], first paragraph, >"and more reliable alternatives used instead"---->"and more reliable >alternatives should be used instead" > >"still in use and part of"---->"still in use as part of" > >-[Page 29], paragraph 3, >"is generally be"---->"will generally be" > >-[Page 30], paragraph 1, >"such as shown in Section 2.6.4",- is this pointing to the correct section? > >-[Page 30], last sentence >"Note: During recursion into an "include" mechanism, an exp= modifier > from the MUST NOT be used. In contrast, when executing > a "redirect" modifier, an exp= modifier from the original domain MUST > NOT be used. >" >Is it possible to add 1-2 sentence to explain why?(what is the >expected consequence if this is not respected) > >-[Page 32], line 3, >"p = the validated domain name of (do not use)" >Is it possible to add a reference to section 5.5 which explains why? >Suggested: "(do not use, see Section 5.5)" > >-[Page 33], third paragraph before last >"was provide more than once"---->"was provided more than once" > >-[Page 34], last "Note": >"....for as long as the shortest Time To Live (TTL) of all the DNS >records involved." >Please review this sentence ending. It is not clear. >Suggestion: "as long as the DNS record involved with the shortest >TTL has not expired" ? > >-[Page 36], sentence 2, "Terse definitions"--typo-->"The definitions" > >-[Page 36], paragraph 2,"be explicity"--typo-->"be explicitly" > >-[Page 36], Section 8.1,"checked idenity"--typo-->"checked identity" > >-[Page 37], Section 8.4, "the 5.7.1 enhanced status code", with >reference to RFC3463. >For better clarity please consider adding reference to Section 3.8 >of the RFC3463. > >-[Page 38], Section 8.6, >For better clarity please consider referring to Section 3.5 of RFC3463 > >-[Page 38], Section 8.8, >For better clarity please consider referring to Section 3.6 of RFC3463 > >-[Page 39], Section 9 Title, "Recording The Result"---->"the" > >-[Page 44], Line 2, "carefully weight"---->"carefully weigh" > >-[Page 44], Section 10.1.2, ""ip4" and "ip6" over "a" or "a" or "mx"." >The last part should suggest "mx' over "a" or the reverse? > >-[Page 46], Section 10.3 "User actor.[RFC5598]."---->"User actor [RFC5598]." > >-[Page 47], before last sentence, missing closing >parenthesis:"(defined in Section 4.6.4." > >-[Page 49], Section 11.5.3, "It is necesary"--typo-->"It is necessary" > >-[Page 62], line 2, "to implmentation"--typo-->"to implementation" > >-[Page 62], second bullet before last, "Section 10 and Appendices D >- H below.", is this part of the sentence refering to anything, below? > >-[Page 65], Section E.3, "Receving ADMDs"--typo-->"Receiving ADMDs" > >-[Page 66], last line, "mitiate"--typo-->"mitigate" > >-[Page 68], one line before last, "reliabilility"--typo-->"reliability" > >-[Page 70], paragraphe 2, >"techincal"--typo-->"technical" >"deplyment"--typo-->"deployment" > >-[Page 72], line 7, "obslete"--typo-->"obsolete" > >-[Page 72], 2 line before last, "text and figures from Alessandro >Vesely", is it only to section 9.1, or 10.1.1. as well? > >-[Page 73], "Added new section 9 discussion on treatment of >bounces", is it section 9 or section 10.1.3? > >-[Page 73], 1 line before last, "potental"--typo-->"potential" > >-Appendix J., please review the 'section references' pointing to >various changes. > > > >-Throughout the draft, DNS "look up"---->"lookup" > >-Throughout the draft, DNS RCODEs are mentioned without any >reference to RFC1035 (or RFC6195) > >-Throughout the draft, many cross references break the follow. I >suggested revisiting some of them and adding a small text after each >reference which introduces that section. >Example :[Page 17], Section 4.6.2 "the result is specified in >Section 4.7", suggested-->"the result is specified in Section 4.7 >where Default results are discussed" > >-"Section 2.6 Results of Evaluation" lists the possible outputs of >check_host(). >Then "Section 8. Result Handling" continues the description with >handling guidance. >To avoid breaking the flow, please consider moving the descriptive >content of Section 2.6 into Section 8. (unless there is another >reason to keep them far apart). > > > > >Best Regards, >Meral > >--- >Meral Shirazipour >Ericsson Research >www.ericsson.com From Ted.Lemon@nominum.com Mon Apr 29 10:32: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 653C721F9E6E for ; Mon, 29 Apr 2013 10:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuiPApTcmtey for ; Mon, 29 Apr 2013 10:31:54 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 102C621F9D80 for ; Mon, 29 Apr 2013 10:31:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUX6uifuBRwXQyxcTmUDUsM86hyvWLzbT@postini.com; Mon, 29 Apr 2013 10:31:54 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 1F6AE1B8152 for ; Mon, 29 Apr 2013 10:31:53 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 13200190061; Mon, 29 Apr 2013 10:31:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 10:31:52 -0700 From: Ted Lemon To: Stuart Gathman Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQ7g8BXubqTI8/ESMN/lsrU52YZjrcqEAgAEPEgCAAA0EgIAAKVGAgAAFVoCAAQvJAIAAGeQA Date: Mon, 29 Apr 2013 17:31:53 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> In-Reply-To: <517E90A6.6090108@gathman.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 17:32:01 -0000 On Apr 29, 2013, at 11:24 AM, Stuart Gathman wrote: > The idea is that you endure the TIMEOUT the first time only. If a TXT > query then succeeds, you know you are dealing with a braindead > server/firewall, and record the domain and timestamp in a database. =20 > You check the database before making any SPF (type 99) query to avoid > trying known braindead servers. I think turning your SPF resolver into a non-compliant caching resolver is = a bit heavyweight, though. That's effectively what you're doing here... From superuser@gmail.com Mon Apr 29 11:34:46 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 D98CF21F9AF7; Mon, 29 Apr 2013 11:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RNIjLqVIwXy; Mon, 29 Apr 2013 11:34:46 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B413621F9AF3; Mon, 29 Apr 2013 11:34:45 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id i48so2591002wef.34 for ; Mon, 29 Apr 2013 11:34:44 -0700 (PDT) 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=/bb7u/i/HWZGya/qLKRTz93JSfR5H/xqpi9YWo+4e7s=; b=p3LvEciQRpwIWmzkRKQSqLyg4odG1YvUsaN18ZeVyrn+HNato0+7YKcPuNGXxDMvXf i6g4b1H9zYsbcdll30am4ZEwo+zTvLwvYBOWTHtBhOZrySJiMxzyPdIghaHWsy3sXbVf 5A1EzEMVoXyIRv6dNg1QiF4xvqnaHB6kCbZRtJ4OzgQQzlksULnKiZmu/GnUTHbZ8YCY 5qCaWIpdKjgXSFvlB9l2K0O6QcWhPcHqncxxkwYXT6jZRl+6BLYRREJsTYdkqvyVcYC2 2P4/tn7UAB6cM/jAssC435zc6xmpyw3G4yjAkBDQ2jS98zhAGoudmgLrEGp7hSf93aSD Qckw== MIME-Version: 1.0 X-Received: by 10.180.188.198 with SMTP id gc6mr7820334wic.14.1367260484902; Mon, 29 Apr 2013 11:34:44 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 29 Apr 2013 11:34:44 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130429100907.0d0cab88@elandnews.com> References: <6.2.5.6.2.20130429100907.0d0cab88@elandnews.com> Date: Mon, 29 Apr 2013 11:34:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=001a11c389a484a4da04db842375 Cc: Meral Shirazipour , "spfbis@ietf.org" , General Area Review Team , draft-ietf-spfbis-4408bis.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 18:34:47 -0000 --001a11c389a484a4da04db842375 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 29, 2013 at 10:14 AM, S Moonesamy wrote: > Hi Meral, > > Thanks for the review. I am forwarding it to the SPFBIS mailing list for > discussion. I'll email you in a few days to address your comments. > > Regards, > S. Moonesamy (as document shepherd) > > At 08:53 29-04-2013, Meral Shirazipour wrote: > >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at > area/gen/trac/wiki/GenArtfaq >> >h**ttp://wiki.tools.ietf.org/**area/gen/trac/wiki/GenArtfaq. >> >> Please resolve these comments along with any other Last Call comments you >> may receive. >> >> Document: draft-ietf-spfbis-4408bis-14 >> Reviewer: Meral Shirazipour >> Review Date: 2013-04-29 >> IETF LC End Date: 2013-04-30 >> IESG Telechat date: NA >> >> >> >> Summary: >> This draft is almost ready to be published as Informational RFC but I do >> have some comments. >> > Was this a mistake in the preparation of the review, or did the reviewer believe the intended status was Informational and thus do a review with less scrutiny in mind? The intended status is Proposed Standard. -MSK --001a11c389a484a4da04db842375 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 29, 2013 at 10:14 AM, S Moonesamy <sm+ietf= @elandsys.com> wrote:
Hi Meral,

Thanks for the review. =A0I am forwarding it to the SPFBIS mailing list for= discussion. =A0I'll email you in a few days to address your comments.<= br>
Regards,
S. Moonesamy (as document shepherd)

At 08:53 29-04-2013, Meral Shirazipour wrote:
I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at <http://wiki.tools.ietf.org/a= rea/gen/trac/wiki/GenArtfaq>http://wiki.tools.ietf= .org/area/gen/trac/wiki/GenArtfaq .

Please resolve these comments along with any other Last Call comments you m= ay receive.

Document: draft-ietf-spfbis-4408bis-14
Reviewer: Meral Shirazipour
Review Date: 2013-04-29
IETF LC End Date: 2013-04-30
IESG Telechat date: NA



Summary:
This draft is almost ready to be published as Informational RFC but I do ha= ve some comments.

Was this= a mistake in the preparation of the review, or did the reviewer believe th= e intended status was Informational and thus do a review with less scrutiny= in mind?=A0 The intended status is Proposed Standard.

-MSK
--001a11c389a484a4da04db842375-- From sm@elandsys.com Mon Apr 29 11:48: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 0E0E121F9A6A; Mon, 29 Apr 2013 11:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTCFmgHw9T9G; Mon, 29 Apr 2013 11:48:34 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE1F21F9AC5; Mon, 29 Apr 2013 11:48:29 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3TIm6ga011371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Apr 2013 11:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367261299; bh=R6iuUKlPGJXFffsU/240+UAmvlzK2Yw3Fetewz9lV/I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2P3rjKLcmg048y/GYQ37AOo+gDhZQSmyY54BMJpc7dbOYjeLgMdwEivyKNju/r/oa wCCquem54uvfWxjynbTr39VIG6ywwpmaIwZex83+YKwI8qwllHhSz0y9B3u93B5AAF b8uDKT9Y4BUmY/UuOXsZ/ecdM9ANF3hht3vRsAgs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367261299; i=@elandsys.com; bh=R6iuUKlPGJXFffsU/240+UAmvlzK2Yw3Fetewz9lV/I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FiDewJ+thJToaWvbREE6CkgzWRFn7REpblftpv2TrClJr7gGmwPuLqIe93YbDY5T3 18HJL5HiwKbWYB/xT+VHbN7q/u2wJGaNHMxRpRl+fHzZuHp5RKelmX+ydog14DxhI+ nmVjWcflYd5ptWvZOmL7D3Cv8M8brDt89a1RB76s= Message-Id: <6.2.5.6.2.20130429113656.0d0cbc30@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 29 Apr 2013 11:47:31 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130429100907.0d0cab88@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Meral Shirazipour , spfbis@ietf.org, General Area Review Team , draft-ietf-spfbis-4408bis.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 18:48:35 -0000 Hi Murray, At 11:34 29-04-2013, Murray S. Kucherawy wrote: >Was this a mistake in the preparation of the review, or did the >reviewer believe the intended status was Informational and thus do a >review with less scrutiny in mind? The intended status is Proposed Standard. In my opinion the reviewer read the draft very carefully. The reviewer might have written the word "Informational" to see whether the SPFBIS working group will read the Gen-ART review carefully. :-) The intended status of the draft is "Proposed Standard". Regards, S. Moonesamy From superuser@gmail.com Mon Apr 29 12:26: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 EFD5B21F9B25; Mon, 29 Apr 2013 12:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUmD85TGFJRn; Mon, 29 Apr 2013 12:26:49 -0700 (PDT) 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 EEDEE21F9B24; Mon, 29 Apr 2013 12:26:48 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id e11so2307648wgh.4 for ; Mon, 29 Apr 2013 12:26:44 -0700 (PDT) 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=cJc9MNZgWhiTCef2rpL9ITE3EzEHnOElwZr6DIeiZTc=; b=BUhDEp24n6Y9p48cvxYktyeU/mFr8BTOx2eX51MXiWNrgyYzAzRJKLL/oli/7BTOx6 LaFd+tp54i8AsF0AjcWdZj+zxKJgSypfghP/P/h9rkdwb6h1Y2X8mAF6TI5kOqWf+Ax4 63s64lA0X3FhPpfiofWHWuPSd84QSsVwhqfmRywcozN94j1vNRc+IG+roBIbWqua5KLf ZNbr9nzE0xO3McoPXfna5hPUYPk/+0j63oLTH59Tey+JgLBGzds9HL0Y3Pfe5qslZusu c/wTXI0VchOOS3gljWWve6Jckiqp5yZdYePWEp0JmLL7zFPSzf81quh8C+UJl87dX/x5 XcIQ== MIME-Version: 1.0 X-Received: by 10.194.59.208 with SMTP id b16mr15892729wjr.15.1367263604031; Mon, 29 Apr 2013 12:26:44 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 29 Apr 2013 12:26:43 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130429113656.0d0cbc30@elandnews.com> References: <6.2.5.6.2.20130429100907.0d0cab88@elandnews.com> <6.2.5.6.2.20130429113656.0d0cbc30@elandnews.com> Date: Mon, 29 Apr 2013 12:26:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7b86de326ec9a604db84dd94 Cc: Meral Shirazipour , "spfbis@ietf.org" , General Area Review Team , draft-ietf-spfbis-4408bis.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 19:26:50 -0000 --047d7b86de326ec9a604db84dd94 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 29, 2013 at 11:47 AM, S Moonesamy wrote: > In my opinion the reviewer read the draft very carefully. The reviewer > might have written the word "Informational" to see whether the SPFBIS > working group will read the Gen-ART review carefully. :-) > Better to ask the question now than have it come up during IETF LC that the review needs to be repeated with a different perspective. > The intended status of the draft is "Proposed Standard". > Right. -MSK --047d7b86de326ec9a604db84dd94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 29, 2013 at 11:47 AM, S Moonesamy <sm+ietf= @elandsys.com> wrote:
In my opinion the reviewer read the draft ve= ry carefully. =A0The reviewer might have written the word "Information= al" to see whether the SPFBIS working group will read the Gen-ART revi= ew carefully. :-)

Better to ask the question now than have i= t come up during IETF LC that the review needs to be repeated with a differ= ent perspective.
=A0
The intended status of the draft is "Proposed Standard".

Right.

-MSK
--047d7b86de326ec9a604db84dd94-- From dotzero@gmail.com Mon Apr 29 12:44: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 552BE21F9B8F; Mon, 29 Apr 2013 12:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86js6SAAlh9m; Mon, 29 Apr 2013 12:44:55 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6931021F9AA8; Mon, 29 Apr 2013 12:44:54 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id eb20so1166236lab.29 for ; Mon, 29 Apr 2013 12:44:49 -0700 (PDT) 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=433KlHb48nbKldyp5+dP3EmZslJhKYFyLNwjuBBEEeM=; b=Fu6UpfteBbUIYbIu3uW5IdLHV4DWoylWKwMoSgf6qgk8YVyMr5MWk0IwpOF0kCW8eP 7xXBmgJZuBOcxYCF16IQxYzMADY7yXsgR7Vv6UVuaoKld5TAcWswkVutEDhWN1sC3BGW L9l0oXvzt8bBpzjF8oUaaDRw6oUnK6j7/MUKoekGhIYfDBxU/5atPW1yIemOQIxMzmWs KXlhuxBJdTqFSkgjfka3zi8TOpFOTJkhhM7d5rUsuxDAq48U7rMXrPgiuC1epagaQFbd BnUnJDlMFchGfH2axNPsFu157Jomr3qWLp5eRJfBLkJ/zGTnzEvndOXkcd/BHp2T5Z74 QSug== MIME-Version: 1.0 X-Received: by 10.152.88.115 with SMTP id bf19mr12227903lab.56.1367264689447; Mon, 29 Apr 2013 12:44:49 -0700 (PDT) Received: by 10.112.72.166 with HTTP; Mon, 29 Apr 2013 12:44:49 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130429113656.0d0cbc30@elandnews.com> References: <6.2.5.6.2.20130429100907.0d0cab88@elandnews.com> <6.2.5.6.2.20130429113656.0d0cbc30@elandnews.com> Date: Mon, 29 Apr 2013 15:44:49 -0400 Message-ID: From: Dotzero To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: Meral Shirazipour , spfbis@ietf.org, General Area Review Team , "Murray S. Kucherawy" , draft-ietf-spfbis-4408bis.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 19:44:55 -0000 On Mon, Apr 29, 2013 at 2:47 PM, S Moonesamy wrote: > Hi Murray, > > At 11:34 29-04-2013, Murray S. Kucherawy wrote: >> >> Was this a mistake in the preparation of the review, or did the reviewer >> believe the intended status was Informational and thus do a review with less >> scrutiny in mind? The intended status is Proposed Standard. > > > In my opinion the reviewer read the draft very carefully. The reviewer > might have written the word "Informational" to see whether the SPFBIS > working group will read the Gen-ART review carefully. :-) > > The intended status of the draft is "Proposed Standard". > > Regards, > S. Moonesamy > I noticed this as well and was just about to respond when I saw Murray respond. Mike From hsantos@isdg.net Mon Apr 29 13:52: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 789D721F9A9D for ; Mon, 29 Apr 2013 13:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NC5RDUs50zGq for ; Mon, 29 Apr 2013 13:52:26 -0700 (PDT) Received: from groups.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3A62821F9B0D for ; Mon, 29 Apr 2013 13:51:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1297; t=1367268677; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=xnQ57Ta gUNRXFfAz+2ShA1mdWyc=; b=Wxthj9uS6UmkhMIjxkEzV+ibyNsMMsUvylniyO3 lcRB7s9QXPeQRH0h0aO8AwuT0a0hphPh7t4T9fURm5c86qQOvsFhN6NkMlWfu4jc XYsAhHTczAdflGJN/MIRCiaboN8fQyJbW8Kg1CpLe5TI7/gsa/6jKwltoS9fMxPX 6T9k= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 29 Apr 2013 16:51:17 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1767395357.5068.4860; Mon, 29 Apr 2013 16:51:16 -0400 Message-ID: <517EDCF0.4080801@isdg.net> Date: Mon, 29 Apr 2013 16:49:52 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130429065657.0d392368@elandnews.com> In-Reply-To: <6.2.5.6.2.20130429065657.0d392368@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cyrus Daboo , spfbis@ietf.org Subject: Re: [spfbis] APPSDIR review of draft-ietf-spfbis-4408bis-14.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, 29 Apr 2013 20:52:31 -0000 On 4/29/2013 10:05 AM, Cyrus Daboo wrote: > Section 2.6 and Section 8 appear to duplicate a lot of similar > information. Please consider trimming down Section 2.6 and have it refer > to Section 8 for full details. I agree with this and suggested this in recent comments myself. I suggest to include as well Section 8 with Appendix H, coupled the security Section 11.7. All these can be merged to Section 8 for "full details." The ambiguous verbosity is not necessary for two basic protocol actions the protocol MUST take for SPF FAIL Domain published policies: FAIL + SMTP REJECT FAIL + SMTP ACCEPT + MDA/MUA Separation by back end. ------------------------------- Section 11.7 In other words, section 11.7 was only written based on the issue report (by me) to highlight the security repercussions and protocol damaging of not doing what is expected in section 2.6 by SMTP for SPF FAIL published policies - rejection. It you don't reject, but accept the mail, then you MUST at least separate the mail. If anything, security Section 11.7 should only need to say: You MUST NOT deliver the SPF failed, unauthorized domain mail to users without a clear separation of security status of the mail! And nothing else more is needed to be said. -- HLS From marka@isc.org Mon Apr 29 13:52: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 A1E5B21F9C04 for ; Mon, 29 Apr 2013 13:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=1.649, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gi03wLjzS9Rt for ; Mon, 29 Apr 2013 13:52:40 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id E1B1E21F9C09 for ; Mon, 29 Apr 2013 13:52:19 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 9A0405F983B; Mon, 29 Apr 2013 20:52:05 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367268736; bh=rlVNDR7bFNMpftv7x+BTW3H532a1xZCp+B8aY8v4snI=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=lKqJYJOkLkLHD1cPf5NGS7/HQveN5oj3y16hZq5GjKt1ZVU9AkJvw6ZM52pCsopZJ 3sCGh1dbSCkLIZSWegmL1xdnRy48UZiCtEbviEHMfvdl/PJ7oVDeqqFMCPtGh6A0M8 AUc5/eifJokfqctXsnKYqe0GAWyY7BG9uhCbEQOI= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C89F6216C40; Mon, 29 Apr 2013 20:52:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6F2B83337D29; Tue, 30 Apr 2013 06:51:55 +1000 (EST) To: Stuart Gathman From: Mark Andrews References: <20130428183338.97350.qmail@joyce.lan> <20130429024917.A69473323956@drugs.dv.isc.org> <517E8E53.6000504@gathman.org> In-reply-to: Your message of "Mon, 29 Apr 2013 11:14:27 -0400." <517E8E53.6000504@gathman.org> Date: Tue, 30 Apr 2013 06:51:55 +1000 Message-Id: <20130429205155.6F2B83337D29@drugs.dv.isc.org> Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 20:52:41 -0000 In message <517E8E53.6000504@gathman.org>, Stuart Gathman writes: > Long ago, Nostradamus foresaw that on 04/28/2013 10:49 PM, Mark Andrews > would write: > > > > ISC released BIND 9.4.0 which included SPF in Feb 2007, the first .0 > > released after RFC 4408 was published. > > > > Libspf2, with type SPF, support didn't come out until October 2008. > > No releases were made between Feb 2005 and October 2008[1]. > > > > The SPF camp complain about lack of type SPF record deployment yet > > they took over 2 years to release a library which supported type > > SPF when it was about a 10 minute fix to add support for it to the > > library. > > > > No effort was made to update documentation to say add both SPF and > > TXT records as far as I can see to bring it into line with RFC 4408. > > > > They then start measuring support before a hardware deprecation > > cycle has even completed. > > > > If I had known that there was going to be a survey about type SPF > > support so early in the transition process which I assumed would > > take 10 to 15 years or more to complete I would have added code to > > complain about missing SPF records. > > > > Now that you want to deprecate SPF I need to add code to tell those > > that have SPF records without TXT records that they need to add TXT > > records. > Mark, the problem wasn't lack of deployment. The problem was TIMEOUTs > from certain DNS servers/firewalls on unexpected RR types. This was a > frustrating problem, and I wish I had put more thought into solving it. Servers that drop requests are not RFC 1035 compliant and they are mostly gone as those that did it also tended to dropped AAAA lookups which a MTA can't avoid. And not there are not and never have been a lot of them. If your firewall drops records. REPLACE IT with one that isn't BROKEN. If you want to use SPF you need to make sure *your* equipement is compliant with it. This what we tell sites that have problems with EDNS packets. Guess what, it works. > Dear WG, please note that publishing SPF *only* (as Mark mentions) > solves the problem also - as client libraries have had a long time to > check both records (and pyspf support both types very early). Most > libraries do check TXT first, to avoid the TIMEOUT problem. But > recording domains that TIMEOUT on SPF queries solves the problem on the > client end and allows checking SPF first. Or you can send both queries in parallel and use whichever returns a record first. Or send a SPF request then send a TXT request 200ms later if you havn't got a response yet and again use whichever returns a RRset first. If a site gets lots if blow back they will fix their servers. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@elandsys.com Mon Apr 29 14:01: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 E4BCF21F9B9D for ; Mon, 29 Apr 2013 14:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rTEqV175A0T for ; Mon, 29 Apr 2013 14:01:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CE321F9B94 for ; Mon, 29 Apr 2013 14:01:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3TL0e1o003024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Apr 2013 14:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367269255; bh=eMeC+FNeKgiEz33BF/S9FrOsLByYOOSKUXAI3yE79dM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=V+IRMaNpj4+NS1Zhp0HjdQBJACXoJrmdLlN2kYtqx/D37LDPLksqYxuqP51NB5as8 c/lr9nlPt3veeg6yaCquYhMsHKwEJJ5OXqtktD3hfgWd2Z1io/VbxkuWPlgH9M/Sj7 5+cf0Bs2DGl2VaDkgFtuZrrBJyWmRp2kOrGb4uLg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367269255; i=@elandsys.com; bh=eMeC+FNeKgiEz33BF/S9FrOsLByYOOSKUXAI3yE79dM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QOWgkE5asmgjO19tbjcp5az1IjlhN67BF6VnpWeXG2zHJZ9a7BdxEeBVRPqVNJIXK fnpOHEXmHGz907NB3+yQxK6sZlT5RgeiBz4beejCJ/PMGAfFLgplVV9SSwhP0odxGH xEZPLCmxaXQ5giOZJ9pNLyaKu2IPUNlavvHceOOg= Message-Id: <6.2.5.6.2.20130429024006.0a9a7e18@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 29 Apr 2013 13:59:21 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Arthur Thisell Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 21:01:08 -0000 Hi Murray, At 01:21 29-04-2013, Murray S. Kucherawy wrote: >Scott and I talked a bit about some of these points, and I thought >it might help if I went through the whole thing and commented on >it. I hope this is helpful. I've chopped out stuff where I have no >specific response or opinion about the points made, so this is only >a nearly-complete reply. Thanks. It's helpful. I'll comment below. My quoting is broken as some of my previous comments might be read as yours. >You made these notes throughout your review. I take it there's no >action for the WG here; you are just auditing "out loud" what >normative things in 4408bis were also present as-is in 4408, and >which have changed. Yes. It may also save other reviewers some work if they are auditing the normative things. > > 'Note that requirements for the domain presented in the EHLO or HELO > command are not always clear to the sending party, and SPF verifiers > MUST be prepared for the "HELO" identity to be malformed or an IP > address literal.' > >This RFC 2119 "MUST" is not in RFC 4408. It is a substantive change >in my opinion. >This was probably at my suggestion. The issue here is that RFC2119 >doesn't say "must" has any different meaning than "MUST" does, so we >should either be consistant and uppercase-ize it, or use some other word. Authur Thisell mentioned that some of the lower-case (RFC 2119) words in RFC 4408 were intentional. Barry Leiba, as Area Director, commented about "[treating] changes with due scepticism, with the idea that the change was made to fix a real problem, and it had better be right" [1]. I prefer not to bring the usual RFC 2119 discussion into this working group. RFC 4408 has been around for several years. If there is a real problem there would be some discussion about it. I would appreciate if someone points me to that discussion. >In any event, I don't agree that this is actually a substantive change. See above. > "This SPF check can only be performed when the "HELO" string is a > valid fully qualified domain." > >What is a valid fully qualified domain? > >I believe it means "a name comprising a sequence of DNS labels, >separated by dot characters, which when queried resolve to an A or >MX record". It may have a proper definition in some other RFC >too. Should we add one in the Introduction or Definitions? I suggest dropping "valid" as the quick fix (see below). I'll defer to RFC 5321 instead of having to add more text. This SPF check can only be performed when the "HELO" string is a fully-qualified domain name. >In Section 2.3: > > "An SPF-compliant domain MUST have valid SPF records as described in > Section 3." > >As a note the RFC 4408 text is: > > "An SPF-compliant domain MUST publish a valid SPF record as described > in Section 3." > >The RFC 2119 MUST is redundant. > > >In a recent conversation, Pete described this as "not really wrong, >but it's shouting." I guess that means changing "MUST publish" to >"publishes" or something like that. I am ok with the "publishes". > 'If domain owners choose to publish SPF records and want to support > receivers making negative authorization determinations, then they MUST > publish records that end in "-all", or redirect to other records that do, > otherwise, no definitive determination of authorization can be made.' > >The document uses ADMD while there is "domain owners" in the >above. I suggest reviewing that. > >I think they're synonymous. Going with ADMD is probably a good idea. Ok. > The RFC 2119 MUST is a substantive change. Why is this a MUST? > >It is the only way within the protocol to cause negative >authorization determinations to occur. It is an interoperability >requirement. I believe this is correct. Andrew Sullivan, as an individual, commented about the text [2]. I suggest going with what was suggested or else the working group will be discussing Issue #33 again. >In Section 2.4: > > 'At least the "MAIL FROM" identity MUST be checked, but it > is RECOMMENDED that the "HELO" identity also be checked beforehand.' > >There is already a RFC 2119 MUST in Section 2.2. There is also a >RFC 2119 RECOMMENDED in Section 2.1. The above text restates >existing RFC 2119 requirements or recommendations. > >I agree; the redundancy should be resolved. The cited sentence in >2.4 can probably go. Ok. > > 'Without explicit approval of the domain owner, checking other > identities against SPF version 1 records is NOT RECOMMENDED because > there are cases that are known to give incorrect results.' > >How should this explicit approval be sought? This recommendation >does not make sense. > >Adding "out-of-band" or "private" after "explicit" would probably >clear this one up. Please use ADMD as we discussed previously (see above). I am ok with either of the words suggested. >In Section 2.4: > > 'When a mail receiver decides to perform an SPF check, it MUST use a > correctly-implemented check_host() function (Section 4) evaluated > with the correct parameters.' > >This RFC 2119 requirement states the obvious. It basically says >that there is a requirement in draft-ietf-spfbis-4408bis-14 to use a >correct implementation of draft-ietf-spfbis-4408bis-14. > >I agree, that sentence can probably go. Ok. > > "Implementations have to take care to correctly extract the > from the data given with the SMTP MAIL FROM command as many MTAs will > still accept such things as source routes ..." > >The definition of is: > > 'the domain portion of the "MAIL FROM" or "HELO" identity.' > >I am not sure whether it is even a definition. From an >implementation perspective the last paragraph of Section 2.4 is unclear. > >I don't agree. I imagine by now you're aware of what this is for; >can you suggest some other text that accomplishes the intent? definitions (not sure whether it is a definition) are mentioned in two places. I suggest fixing that and then getting back to the above. > 'Generating non-delivery notifications to forged identities that have > failed the authorization check is a source of backscatter and SHOULD > be avoided.' > >This RFC 2119 SHOULD is not in RFC 4408. The above does not have >anything to do with Sender Policy Framework. It was mentioned >during WG discussions that "SPF can help the backscatter problem" >[2]. This text may have been introduced in response to a review >[3]. Is this an enhancement or a clarification? > > >I think it documents operational experience acquired since RFC4408 >was published. As for whether RFC2119 language is appropriate, I >agree that it isn't; it has nothing to do with SPF itself, though it >is a side effect of its use. I suggest changing SHOULD to "needs to". My reading of the above is that it is neither an enhancement or a clarification. I suggest removing the text. >In Section 2.6.1: > > 'A result of "none" means either (a) no syntactically valid DNS domain > name was extracted from the SMTP session that could be used as the > one to be authorized, or (b) no TXT records were retrieved from the > DNS that appeared to be intended for use by SPF verifiers.' > >I suggest "DNS TXT records". What is a syntactically valid DNS >domain name? The definition of "none" in RFC 4408 is clear (to me). > > >"DNS TXT records" is fine but probably not necessary at this point >in the document. > >We discussed the "syntactically valid" thing above. I'll leave this one to Andrew. >This definition of "none" is more precise than it was in >RFC4408. The 4408 definition was: > > > A result of "None" means that no records were published by the domain > or that no checkable sender domain could be determined from the given > identity. The checking software cannot ascertain whether or not the > client host is authorized. > >This text did not account for the notion that TXT records were >returned that didn't start "v=spf1". It also wasn't clear about >what "checkable" meant. I believe the bis definition is better. Ok. By the way, if anyone disagrees, please comment. >In Section 2.6.7: > > 'A "permerror" result means the domain's published records could not > be correctly interpreted. This signals an error condition that > definitely requires manual intervention to be resolved.' > >What is "manual intervention" in the above? > > >"Operator intervention" might be more consistent with common IETF usage. Ok. >In Section 3: > > 'An SPF record is a DNS record that declares which hosts are, and are > not, authorized to use a domain name for the "HELO" and "MAIL FROM" > identities.' > >How are hosts which are not authorized to use a domain name listed >in a SPF record? > >It's implicit in that the set that is not authorized is the >complement to the set that is authorized. If we want to make it >clear, we could say "which hosts are, and thus also which are not," >or something like that. Ok. This can be "no action required" if the working group agrees. > "The SPF record is a single string of text." > >What is a single string of text? It may be easier to state this in >terms of record format. > >I don't think that statement is unclear, but I agree with the >improvement suggestion. Maybe: > >"An SPF policy statement is expressed as a single string of text >encoded in a DNS TXT record." That sounded better. I'll leave it to Andrew to catch my mistake if I got this one wrong. > 'ADMDs publishing SPF records SHOULD try to keep the number of > "include" mechanisms and chained "redirect" modifiers to a minimum.' > >What is the minimum? Note that this RFC 2119 SHOULD is in RFC 4408. > > >There isn't a specific minimum. The expression means "don't use >this technique unless you absolutely need it". I didn't understand that as there wasn't any explanation for the RFC 2119 SHOULD. I suggest adding an explanation or rewriting the text so that the expression (see above) is clear. > > 'ADMDs SHOULD also try to minimize the amount of other DNS information > needed to evaluate a record.' > >This RFC 2119 SHOULD is also in RFC 4408. There are two RFC 2119 >SHOULDs in the last paragraph of Section 3. This usage of RFC 2119 >key words does not help the SPF "publisher". In my opinion the >"SHOULD try" in this context uses the RFC 2119 key word in unorthodox ways. > >I agree with "SHOULD try", as that's arguably not >actionable. "SHOULD minimize" is probably fine, however. Ok. >In Section 3.1: > > 'SPF records MUST be published as a DNS TXT (type 16) Resource Record > (RR) [RFC1035] only.' > >I would ask why "MUST be published ... only". By the way, Section 3 >has a reference to Section 4 for record format instead of Section >3.1. Is that correct? > >The text is not incorrect, but it's also not necessary. Dropping >"only" is probably sufficient. > >The reference is indeed incorrect. Ok. >In Section 3.2: > > "A domain name MUST NOT have multiple records that would cause an > authorization check to select more than one record." > >This RFC 2119 MUST NOT was in RFC 4408. Is this to help the SPF >"publisher" and if so, how does it help? > >I believe it is an advisory to publishers of the consequences of >having more than one "v=spf1" record published. Ok. >In Section 3.3: > > "As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS > record can be composed of more than one string." > >See previous comment about " a single string". > > >This use is correct, as it describes the fact that there are many >ways to encode a single high-level string into multiple low-level >"character-strings" as defined in RFC1035. I'll leave this to Andrew. > "If a published record contains multiple character-strings, then the > record MUST be treated as if those strings are concatenated together > without adding spaces." > >This RFC 2119 MUST is also in RFC 4408. I suggest removing the >"MUST" in the example. > >I disagree. It's required for interoperability. Interoperability requirements are not specified through examples. > > "TXT records containing multiple strings are useful in constructing > records that would exceed the 255-byte maximum length of a character- > string within a single TXT record." > >I suggest using "octet" instead of "byte". I'll point the working >group to CVE-2008-2469 in case it might wish to consider that issue. > > >How is an octet different from a byte in this context? This strikes >me as a stylistic issue at best. It's a term of art used in DNS-related specifications. >In Section 4: > > "A compliant SPF implementation MUST do something semantically > equivalent to > this description." > >It's unusual to see a "do something" RFC 2119 requirement in a >specification. Is the SPFBIS WG working on compliance for SPF implementations? > > > RFC6376 is an example of a standards track document that uses > RFC2119 MUST in this way. I'm sure I've seen others but I can't > think of them at this hour. I think it's fine. I suggest fixing the "do something". > "Mail receivers that perform this check MUST correctly evaluate the > check_host() function as described here." > >Where does "mail receivers" fit in the Sender Policy Framework? The >"MUST correctly evaluate" is stating the obvious. > > >I'm not understanding how the answer to the first question isn't obvious. > >I agree with the second point. There was a problem of terminology previously. SPF verifiers is used in other parts of the specification. > > "Implementations MAY use a different algorithm than the canonical > algorithm defined here, so long as the results are the same in all > cases." > >Why is this a RFC 2119 MAY? I am aware that the text is in RFC 4408. > >This seems to me to be another stylistic question, since MAY in >RFC2119 terms doesn't mean much. I'll say ok as the text is already in RFC 4408. >In Section 4.1: > > ' - the domain that provides the sought-after authorization > information; initially, the domain portion of the "MAIL > FROM" or "HELO" identity.' > >The above text is different from the text in Section 2.4. > >I think I agree; I would prefer to have it defined in one place, and >have other points in the document reference it. I mentioned this previously (see above). >In Section 4.3: > > "If the is malformed (e.g. label longer than 63 characters, > zero-length label not at the end, etc.)" > > That should be "octets". > >Since the DNS is all in ASCII, they're synonymous. That said, we >may as well be consistent. DNS is not all in ASCII but let's avoid that side-discussion. > > "Properly formed domains are fully qualified email domains as > described in [RFC5321] Section 2.3.5." > >What are "properly qualified email domains"? > >Is the reference defining that term not appropriate? The reference is correct, the wording could be kept simple: Properly formed domains are described in [RFC5321] Section 2.3.5. The wording is not that good but I could not think of anything better. >In Section 4.4: > > "In accordance with how the records are published (see Section 3 > above), a DNS query needs to be made for the name, querying > for type TXT only." > >I don't understand the sentence. > >Query the HELO domain or the MAIL FROM domain, as described in Section 3. I read the first paragraph of Section 4.4 as meaning that the DNS query is for Type TXT only. I suggest explaining that the record lookup is done by query for the SPF record described in Section 3. By the way, the text you suggested for Section 3 fits in nicely. > 'Alternatively, for a server failure (RCODE 2) result, check_host() > MAY track failures and treat multiple failures within 24 hours for > the same domain as "permerror".' > >This text is not in RFC 4408. I found a note in Issue #1 [5] and in >a message [6]. > >Are there any implementations that do this? If so, that's the >justification; it's practical experience. If not, we should >consider dropping it. I'll wait for feedback on this. >In Section 4.6.2: > > "If there are no more mechanisms, the result is specified in > Section 4.7." > >This sentence does not make sense. > > >How about: "After all mechanisms have been processed and no matches >are found, the result is determined according to Section 4.7." Thanks, that's better. > "If this number is exceeded during a check, a permerror MUST be returned." > >I read this as if an implementation-specific limit is reached a >permerror is returned. There are two RFC 2119 MUST in the >above. That can be reduced to one MUST. > > >I'm not sure I agree. SecDir has pushed the fixed query limit on >other topics in the past, which is the first MUST, and the second >MUST prescribes a specific result that has to occur when the limit >is reached which is important for interoperability. For context we are at Section 4.6.4. I'll quote some text from it: "If this number is exceeded during a check, a permerror MUST be returned." 'If this limit is exceeded, the "mx" mechanism MUST produce a "permerror" result.' 'If this limit is exceeded, all records other than the first 10 MUST be ignored.' I prefer not to discuss about the last one (see quoted text) again. In terms of coding it is easier if I am told to return a "permerror" results when DNS limit X is exceeded. That can be specified with one RFC 2119 MUST. I am taking in consideration the SecDir recommendation and interoperability. Speaking of interoperability the following text: 'SPF implementations MUST limit the total number of mechanisms and modifiers ("terms") that cause any DNS query to at most 10 during SPF evaluation.' does not encourage it because of the "at most". Section 4.6.4 does not make things easier for DNS operations as the reader cannot identify the limits easily due to the exceptions. I am ok with the exceptions. What I am suggesting is not to use two RFC 2119 MUST if it there is a way for it to be done with one RFC 2119 MUST. > 'MTAs or other processors SHOULD impose a limit on the maximum amount > of elapsed time to evaluate check_host(). Such a limit SHOULD allow > at least 20 seconds. If such a limit is exceeded, the result of > authorization SHOULD be "temperror".' > >There are three RFC 2119 SHOULDs in the above. I suggest rewriting >the text to reduce that. > >All three of them seem to be important interoperability points. We >could common factor the SHOULD and then present three bullets in a >list, but the meaning is the same. Throughout the document the words "MTA", "other processors", "mail receivers", "SPF implementations" and "SPF verifiers" are used. That looks inconsistent to me. Here's an example of a rewrite: MTA or other processors SHOULD: (a) impose a limit on the maximum amount of elapsed time to evaluate check_host(). (b) allow for at least 20 seconds. (c) return a result of authorization of "temperror". I don't see what Points (a) or (b) has to do with interoperability. Trying to common factor the RFC 2119 SHOULD reduces occurrences of the word instead of addressing the issue. I suggest understanding the intent first before working on the text to be added. > 'SPF implementations SHOULD limit "void lookups" to two.' > >What are void lookups? > > >Last paragraph of Section 4.6. That would be 'These are sometimes collectively referred to as "void lookups".' in Section 4.6.4. Here's is a rewrite: SPF implementations SHOULD limit what is sometimes collectively referred to as "void lookups" to two. See comment below. > "In this case, a default of two is RECOMMENDED." > >Why is "two" recommended? > >Interoperability; if one is two while another is 10, different SPF >results can be returned. Here is the text: "An implementation MAY choose to make such a limit configurable. In this case, a default of two is RECOMMENDED." There is the RFC 2119 SHOULD and the RFC 2119 RECOMMENDED. Here's how I look at it: Is the working group recommending a limit which is configurable? What's the recommended value? Is the value some arbitrary number? > > 'Note that records SHOULD always use either a "redirect" modifier or > an "all" mechanism to explicitly terminate processing.' > >Why is there a RFC 2119 key word in a note? > > >Since the explanation I've been given is that it's better for human >debugging, I think I agree since the advice is not specific to the >protocol itself. I suggest removing the RFC 2119 SHOULD. >In Section 4.8: > > 'e.g., "foo..example.com") or overlong labels (more than 63 > characters).' > >I suggest octets. > > >Again, synonymous. My guess is that someone might file an erratum about this after publication and the erratum will not be rejected. >in Section 5: > > 'SPF implementations on IPv6 servers need to handle both "AAAA" and "A" > secords, for clients on IPv4 mapped IPv6 addresses [RFC4291].' > > >There is a typo, "records". > >I'll flag the above for review by people with IPv6 expertise. > > >This was covered in a different thread. I believe a proposed text >fix was made that people seemed to like. Yes. >In Section 5.3: > > 'a = "a" [ ":" domain-spec ] [ dual-cidr-length ]' > >"dual-cidr-length" is introduced in this sub-section. I had to >search through the draft to find out what it means. > >That happens sometimes. :-) :-) >In Section 5.4: > > 'Note regarding implicit MXs: If the has no MX records, > check_host() MUST NOT pretend the target is its single MX, and MUST > NOT default to an A or AAAA lookup on the directly.' > >There are two RFC 2119 MUSTs in the above. This is over-usage of >RFC 2119 key words. This text was in RFC 4408. This is not a >divergence from RFC 5321, it is a contrary to Section 5 of RFC 5321. > > >I believe the advice should remain, but it could be simplified: > >"Note regarding implicit MXes: If the has no MX >records, check_host() MUST NOT apply the implicit MX rules of >RFC5321 by querying for an A record for the same name." I would suggest removing the RFC 2119 MUST if the suggested text is a note. The specification mentions "compliance" and yet it does not follow RFC 5321. According to RFC 4408 "This behavior breaks with the legacy "implicit MX" rule". I'll discuss this with the Responsible Area Director before saying more. >In Section 5.5: > > "This mechanism SHOULD NOT be used." > >I suggest providing a reason for this. > > >The very next sentence is "See below for discussion." It would be clearer to have: This mechanism SHOULD NOT be used it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers. > "If used, proper PTR records MUST be in place for the domain's hosts > and the "ptr" mechanism SHOULD be one of the last mechanisms checked." > >Those RFC 2119 key words are not in RFC 4408. I don't see how this >RFC 2119 change qualifies as a clarification or explanation. > >It was "must" vs. MUST in RFC4408. It's otherwise unchanged. It's a change. I suggest reverting it. Telling people who are using the "ptr" mechanism that they must have PTR records is stating the obvious. > "It is, however, still in use and part of the SPF protocol, so compliant > check_host() implementations MUST support it." > >What is a compliant check_host() implementation? > > >One that complies with this specification. Ok. :-) > >In Section 5.6: > > "ip6-network = " > >I suggest that the above reference be verified for correctness. > > >Looks right to me. The CIDR expression is in the optional token >next to it, so this has to be just a plain IPv6 address, so that's >the right reference. I suggest reading RFC 5952. >In Section 5.7: > > 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all' > >I'll flag this for review by DNS folks. > >What's the specific question being asked of DNSDIR here? My question would be: "Is Section 5.7 of the draft correct?". >In Section 6: > > 'The modifiers defined in this document ("redirect" and "exp") MAY > appear anywhere in the record, but SHOULD appear at the end, after > all mechanisms.' > >This text is in RFC 4408. I would label the RFC 2119 usage as defective. > > >Why? The text tells me that it is ok if the modifiers appear anywhere but they should appear at the end after all mechanisms. It would be clearer to say that it should appear after all mechanisms. >In Section 7.1: > > 'The "toplabel" construction is subject to the LDH rule plus > additional top-level domain (TLD) restrictions.' > >Where can I find these restrictions? Please note that I have read >the Informational RFC. > > >I'm pretty sure it's referring to common TLD conventions. The text tells me that there are restrictions. I'll ask Andrew how this is usually handled. > "This macro SHOULD NOT be used. See Section 5.5 for the discussion > about why not." > >This comes out as a flippant explanation for the RFC 2119 SHOULD. > > >I think it's fine, though I suggest changing "the discussion about >why not" to just "discussion". Please turn it into one sentence. > > "This SHOULD be a fully qualified domain name, but if one does not > exist (as when the checking is done by a MUA) or if policy restrictions > dictate otherwise, the word "unknown" SHOULD be substituted." > >The RFC 2119 key words are in RFC 2119. I don't know what to say. > > >I think that looks fine as-is, though we could change the first >SHOULD to "ought to" because it's a transformation of other input >and not an implementation choice. (And I assume you mean they were >in RFC4408.) Yes, I meant that there were in RFC 4408. I suggest that the working group looks for a simple sentence to replace the existing one. > "When the result of macro expansion is used in a domain name query, if > the expanded domain name exceeds 253 characters (the maximum length > of a domain name), the left side is truncated to fit, by removing > successive domain labels (and their following dots) until the total > length does not exceed 253 characters." > >Where is it specified that the maximum length of a domain name is >253 characters? > > >RFC1035 says it's 255. > > "Care has to be taken by the sending ADMD so that macro expansion for > legitimate email does not exceed the 63-character limit on DNS labels." > >Where is that 63-character limit specified? > > >RFC1035, Section 2.3.1. I suggest using Section 2.3.4. >In Section 9.1: > > "The Received-SPF header field is a trace field (see [RFC5322] Section > 3.6.7) and SHOULD be prepended to the existing header, above the > Received: field that is generated by the SMTP receiver." > >"prepended to the existing header" does not sound right. > > >It's correct; "header" is the entire header block, while "header >field" is one field in it. (Section 2.1 of RFC5322.) Thanks for explaining this. > "It MUST appear above all other Received-SPF fields in the message." > >How does this fit into the previous RFC 2119 SHOULD? > > >It SHOULD be prepended to the whole header block, but even if it >isn't, it MUST appear above any other Received-SPF field. Ok. >In Section 10.1.2: > > "Publishing SPF records for domains that send no mail is > a well established best practice." > >I am not aware of that best practice. I did a few DNS queries: > >;; QUESTION SECTION: >;bing.com. IN TXT > >;; ANSWER SECTION: >bing.com. 3600 IN TXT "v=msv1 >t=6097A7EA-53F7-4028-BA76-6869CB284C54" > >;; QUESTION SECTION: >;com.com. IN TXT > >;; ANSWER SECTION: >com.com. 293 IN TXT >"google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k" > > >What are you saying here? This is an existence proof of non-mailing >domains that don't publish SPF records, but it doesn't contradict >the statement made in the draft. The claim is being made without any supporting material. >In Section 10.1.3: > > "SPF functionality is enhanced by administrators ensuring this > identity is set correctly and has an appropriate SPF record." > >How is SPF functionality enhanced? > > >When MAIL FROM is null, it's important that HELO be right in order >to get any useful result from SPF. Ok. >In Section 10.2: > > "As stated elsewhere in this document, there is no normative requirement > for specific handling of a message based on any SPF result." > >The "as stated elsewhere" is vague. > > >Section 8 discusses it, if you're saying you'd like a specific reference. I suggest a reference. > 'The primary considerations are that SPF might return "pass" for mail > that is ultimately harmful (e.g., spammers that arrange for SPF to > pass using nonsense domain names' > >What are "nonsense" domain names? > > >"arbitrary", "discardable", something like that. "discardable" sounds the better one of the two. >In Section 10.3: > > "The mediator can make the newly-posted message be as similar or as > different from the original message as they wish." > >The sentence seems incomplete, i.e. similar to what. > > >The original message. > > "For the operation of SPF, the essential concern is the email > address in the 5321.MailFrom command for the new message." > >What does this mean? > > >In the context of mediators (which is the title of this subsection), >the RFC5321.MailFrom field used by the mediator to inject a new >message is the most important consideration. I suggest writing the sentence clearly instead of relying on the title. > > 'Because SPF evaluation is based on the IP Address of the "last" > sending SMTP server, the address of the mediator will be used, rather > than the address of the SMTP server that sent the message to the > mediator.' > >I'll note that this is a mix of RFC 5321 and RFC 5598. The result >is clear or unclear depending on the background of the reader. > > >I think this is clear. You're familiar with the architecture here; >what do you think would fix it? Dave Crocker commented about this. I suggest leaving it as it if there isn't any disagreement. >In Section 11.5: > > "An SPF compliant receiver gathers information from the SMTP commands > it receives and from the published DNS records of the sending domain > holder" > >I suggest explaining the untrusted part. > > >Agreed. A second sentence indicating most of that input is >unverified is probably in order, with references if possible. Ok. >In Section 13.1: > > "The format of this type is identical to the TXT RR [RFC1035]" > >The format is not identical, i.e. it's a different RR. I suggest >keeping the IANA Considerations Section simple, i.e. clearly explain >to IANA what action is requested. > > >The format is indeed identical, right down to the octet. Andrew explained this to me. I'll say ok. >References: > >Why is RFC 1123 a normative reference? > > >It defines the "%"-hack, of which implementers need to be aware >(i.e., code needs to be able to handle that syntax). Ok. >Why is RFC 3864 a normative reference? > >A BCP (e.g., a registration procedure) followed is always a >normative reference, I believe. I guess it is a matter of style. >ABNF: > >Did anyone verify the ABNF? > > >It's been some time but I did a full pass over it previously. Thanks for doing that. I did not spot any mistakes. >In Appendix C: > >In Section E.1: > > 'This would cause a lookup on an DNS white list (DNSWL) and cause a > result of "fail" only for email not either coming from the > domain's mx host(s) (SPF pass) or white listed sources (SPF > neutral).' > >I didn't find any discussion about this on the SPFBIS mailing >list. is there an explanation for this change between RFC 4408 and this draft? > > >It was in 9.3 in the previous document and has been reworded a >little. It's otherwise unchanged. The text from Section 9.3 is already in the draft. This is additional material instead of a little rewording. There was a concern about "a tendency to include an example of every possible use of SPF to solve some problem". I suggest removing the example. > "This document updates and replaces RFC 4408 that was part of a group > of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, > RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the > community observe the success or failure of the two approaches > documented in these RFCs during the two years following publication, > in order that a community consensus could be reached in the future." > >Why is this needed? The SPFBIS WG produced RFC 6686 to resolve the >experiment. > > "SPF is widely deployed by large and small email providers alike. > There are multiple, interoperable implementations." > >Someone might point out that this is marketing instead of text >relevant to a protocol. I'll mention that one or more significant >issues (e.g. Issue #9) was identified during the WG >discussions. Issue #9 was not listed as the errata. I suggest >removing the section as it will be less text and there is already >two informative references to help the reader find background information. > > >I propose leaving this stuff in there as information to the >IESG. If they think it's unnecessary, they can ask that we remove >it, or they can do so in a note to the RFC Editor. I'll comment about this later. I'll add a credit for you in the write-up. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02240.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02784.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02281.html From dhc@dcrocker.net Mon Apr 29 14:03: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 414A721F9C30 for ; Mon, 29 Apr 2013 14:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2qgumouxx9r for ; Mon, 29 Apr 2013 14:03:17 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 57C9221F9B9D for ; Mon, 29 Apr 2013 14:03:17 -0700 (PDT) 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 r3TL3DZS008168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 29 Apr 2013 14:03:17 -0700 Message-ID: <517EE00D.8050401@dcrocker.net> Date: Mon, 29 Apr 2013 14:03:09 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "" References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> 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.66]); Mon, 29 Apr 2013 14:03:17 -0700 (PDT) Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 21:03:22 -0000 Folks, This is one of those threads that will go on for as long as people seem to think they need to keep posting, but it won't make any "progress" or resolve any issues. For that matter, I have no idea what anyone thinks they are accomplishing by continuing to post on it, which raises the question of why they keep bothering. And 'bothering' is what this thread mostly /is/ doing, in reducing the S/N ratio. Please shut the thread down. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From marka@isc.org Mon Apr 29 14:05: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 2ADFB21F9C39 for ; Mon, 29 Apr 2013 14:05:22 -0700 (PDT) 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_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoPOYI8usAzF for ; Mon, 29 Apr 2013 14:05:21 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB5B21F9C37 for ; Mon, 29 Apr 2013 14:05:21 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5A60CC94B8; Mon, 29 Apr 2013 21:05:14 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367269521; bh=i/BuDtdanJo2oDGT67qBzQCmDrereoOSozMCEZhiai8=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=ZI5XXi8A84IMck3x4QFXfhgWRfaTKN/zHfWawQn9YlIbyjW1U29Laz5+TQbUhfuLA A5NSPTSEK2+7kfpUpGcsXAnSAutHp1LOsxktIVVNvXeVaUO87SLh/Jml+ZvfUIl1TF JxitJaIJNYa/K3Tev8GAD94SjyBtWfPglvv1FuH0= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Mon, 29 Apr 2013 21:05:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:556f:ecd0:5b69:c565]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1EC9C216C40; Mon, 29 Apr 2013 21:05:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 073DA3337E03; Tue, 30 Apr 2013 07:05:12 +1000 (EST) To: Alessandro Vesely From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <20130429034026.GB27654@besserwisser.org> <20130429050236.0B5DA3327423@drugs.dv.isc.org> <517E9910.3050602@tana.it> In-reply-to: Your message of "Mon, 29 Apr 2013 18:00:16 +0200." <517E9910.3050602@tana.it> Date: Tue, 30 Apr 2013 07:05:12 +1000 Message-Id: <20130429210512.073DA3337E03@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "spfbis@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 21:05:22 -0000 In message <517E9910.3050602@tana.it>, Alessandro Vesely writes: > On Mon 29/Apr/2013 07:02:35 +0200 Mark Andrews wrote: > > > > New types have been added very year or so for the life of the DNS: > > > > Base spec 1987, RP 1990, X25 1990, ISDN 1990, RT 1990, AFSDB 1990, > > NSAP 1992, GPOS 1994, AAAA 1995, LOC 1996, SIG 1997, KEY 1997, NXT > > 1997, KX 1997, PX 1998, DNAME 1999, ATMA 2000, OPT 2001, APL 2001, > > DS 2003, DNSKEY 2004, RRSIG 2004, NSEC 2004, PSECKEY 2005, SSHFP > > 2006, CERT 2006, SPF 2006, DLV 2006, NSEC3 2008, NSEC3PARAM 2008, > > HIP 2008, URI 2011, TLSA 2012, NID 2012, L32 2012, L64 2012, EUI48 > > 2013, EUI64 2013. > > > > Some of those record are infrequently used but others are wildly > > deployed and used including behind firewalls inspect DNS record > > contents. > > May I ask how many of those types have a TXT equivalent? > > A good deal of this thread assumes that TXT records are bad. Would > anyone say why? I read RFC 5507, and I'd agree that not using a > prefix such as _spf creates unneeded conflicts. However, I'm unable > to understand the reasons why "TXT is evil". Do we need to create new > types whenever the use changes, as we do file extensions? It is TXT without a prefix that is bad. It overloads the use of the TXT record. It does not seperate SPF use from other uses. It is just bad engineering to use it long term. Experimenting with TXT is fine. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hsantos@isdg.net Mon Apr 29 14:17: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 6649221F9B86 for ; Mon, 29 Apr 2013 14:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L89EqvYWAJF for ; Mon, 29 Apr 2013 14:17:04 -0700 (PDT) Received: from groups.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8A921F9B8C for ; Mon, 29 Apr 2013 14:16:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1106; t=1367270201; h=Received:Received: Message-ID:Date:From:Subject:To:Organization:List-ID; bh=G2qWFFw d0MYW8LsdAUcGtLTHrLU=; b=avawK0EDHpKAeNe1ok0poS7cv34L1OfwCjRiH5b R6Y75Tx8AqiFgO4qsuoz5xn1QbSydY4/Zdby+WaxAWTKnKMmBC1QV7R0WvVJKHiH ZRQiGqmnEurGHmc7inUEmodSY0aIKlbASkRXUWyVV+5zqgeV4mOmyvi4A4ouVxQZ IedQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 29 Apr 2013 17:16:41 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1768918925.5068.3308; Mon, 29 Apr 2013 17:16:40 -0400 Message-ID: <517EE2E3.3010003@isdg.net> Date: Mon, 29 Apr 2013 17:15:15 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> <517EE00D.8050401@dcrocker.net> In-Reply-To: <517EE00D.8050401@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Cc: "" , "ietf@ietf.org" Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 21:17:09 -0000 If anyone wishes to see one aspect of what is wrong with IETF Diversity, then see whats going on in SPF BIS WG where a key IETF cog essentially attempts to shutdown discussions and communications, attacks posters which by my estimate were making progress. Progress is a status quo - DON'T CHANGE THE RFC4408 SPECIFICATION in SPFBIS. Many in DNS community do not agree with the change of removing a long term migration path to a SPF RRTYPE. In fact, not changing the existing specification would end the issue and hopefully satisfy all principles. -- HLS On 4/29/2013 5:03 PM, Dave Crocker wrote: > Folks, > > This is one of those threads that will go on for as long as people seem > to think they need to keep posting, but it won't make any "progress" or > resolve any issues. > > For that matter, I have no idea what anyone thinks they are > accomplishing by continuing to post on it, which raises the question of > why they keep bothering. > > And 'bothering' is what this thread mostly /is/ doing, in reducing the > S/N ratio. > > Please shut the thread down. > > d/ From meral.shirazipour@ericsson.com Mon Apr 29 12:26: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 788C021F9B38; Mon, 29 Apr 2013 12:26:54 -0700 (PDT) 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.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRJOBBTB-kBY; Mon, 29 Apr 2013 12:26:49 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id AD4EF21F9ADE; Mon, 29 Apr 2013 12:26:48 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-09-517ec976b45a Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BE.09.02411.679CE715; Mon, 29 Apr 2013 21:26:47 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Mon, 29 Apr 2013 15:26:46 -0400 From: Meral Shirazipour To: S Moonesamy , "Murray S. Kucherawy" Thread-Topic: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14 Thread-Index: AQHORQohUSx1P65FM0qXGQEpvFzSI5jtk7sQ Date: Mon, 29 Apr 2013 19:26:46 +0000 Message-ID: References: <6.2.5.6.2.20130429100907.0d0cab88@elandnews.com> <6.2.5.6.2.20130429113656.0d0cbc30@elandnews.com> In-Reply-To: <6.2.5.6.2.20130429113656.0d0cbc30@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXRPoG75ybpAg6tvuC12Tn3FanH11WcW i1f9N1ktns7cz24x8XsDmwOrx703H5k8ds66y+6xZMlPJo8vlz+zBbBEcdmkpOZklqUW6dsl cGW8X7+UveAIV8X8k+1MDYwXOLoYOTkkBEwkFu3tZYSwxSQu3FvP1sXIxSEkcJRR4uDkpywg CSGB5YwSN/trQWw2AQuJ7b+fs3YxcnCICIRKvD3hDFLPLLCTUeLqh/tg9cICgRJdh66xgtgi AkES/3YugbKNJM603QSzWQRUJV68mMAEModXwFvi5wYuiL2/GCVebuphB6nhFLCTWNE4E6ye Eei476fWMIHYzALiEreezGeCOFpAYsme88wQtqjEy8f/WCFsZYklT/azQNTrSCzY/YkNwtaW WLbwNVg9r4CgxMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDIsoqRo7Q4tSw33chwEyMwro5JsDnu YFzwyfIQozQHi5I47zSpykAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjHrGH+YF36ueH+u4 5SRfDrtz8CUrzt+mHIsk0w52sdz3ZeV5XrdS9NXkr5M+H3qiaZh8QMP8JCNDi/8Z34e16+ek hQcdviyk+C90wbwJ3z5xcLYIxk1KbjfIT+397Ch7xD3qU2e6lEh1QNaJxdJbhNtuVQnqTZ0k 2S5hYKrps2Br3a+Jjl5RSizFGYmGWsxFxYkAdI/FSHkCAAA= X-Mailman-Approved-At: Mon, 29 Apr 2013 14:40:57 -0700 Cc: "spfbis@ietf.org" , "draft-ietf-spfbis-4408bis.all@tools.ietf.org" , General Area Review Team Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 19:26:54 -0000 Hi, Sorry for the confusion. I read it fully aware that it is not information= al.=20 Original email : http://www.ietf.org/mail-archive/web/gen-art/current/msg08= 509.html should say: OLD: "This draft is almost ready to be published as Informational RFC but = I do have some comments." NEW: "This draft is almost ready to be published as Standard RFC but I do h= ave some comments." Thanks, Meral -----Original Message----- From: S Moonesamy [mailto:sm+ietf@elandsys.com]=20 Sent: Monday, April 29, 2013 11:48 AM To: Murray S. Kucherawy Cc: Meral Shirazipour; spfbis@ietf.org; draft-ietf-spfbis-4408bis.all@tools= .ietf.org; General Area Review Team Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis= -14 Hi Murray, At 11:34 29-04-2013, Murray S. Kucherawy wrote: >Was this a mistake in the preparation of the review, or did the=20 >reviewer believe the intended status was Informational and thus do a=20 >review with less scrutiny in mind? The intended status is Proposed Standa= rd. In my opinion the reviewer read the draft very carefully. The reviewer mig= ht have written the word "Informational" to see whether the SPFBIS working = group will read the Gen-ART review carefully. :-) The intended status of the draft is "Proposed Standard". Regards, S. Moonesamy=20 From marka@isc.org Mon Apr 29 16:08: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 DF4E121F9B57; Mon, 29 Apr 2013 16:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.362 X-Spam-Level: X-Spam-Status: No, score=-1.362 tagged_above=-999 required=5 tests=[AWL=1.237, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfBgoxfluPsp; Mon, 29 Apr 2013 16:08:26 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D7E8621F9B7E; Mon, 29 Apr 2013 16:08:02 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id A4E4B5F9908; Mon, 29 Apr 2013 23:07:50 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367276879; bh=PgwmfzM8Id6Palz0ACxrhZ38ve5sdVEp1uvtHpx20Fk=; h=To:From:References:Subject:In-reply-to:Date; b=PsdBBhR7BHz0Xq8g4xcJSXfQ4EUtg6WihO0SpVB9Ux9LiiMNX0nxZQVODIvSj8gTR 24Z9ORdfn8a5Qt35vbEZATEpjm/DSGEe4+m3aESQGUzNrRDzTpG+Wmrv3DHlH/Qi/Z vXU6OfqxINrijk3vAkr+dlboDpz0H+SBoYRwKSVE= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E8513216C47; Mon, 29 Apr 2013 23:07:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3D2833339511; Tue, 30 Apr 2013 09:07:42 +1000 (EST) To: ietf@ietf.org, "" From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> <517EE00D.8050401@dcrocker.net> <517EE2E3.3010003@isdg.net> In-reply-to: Your message of "Mon, 29 Apr 2013 17:15:15 -0400." <517EE2E3.3010003@isdg.net> Date: Tue, 30 Apr 2013 09:07:42 +1000 Message-Id: <20130429230742.3D2833339511@drugs.dv.isc.org> Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 29 Apr 2013 23:08:30 -0000 The really annoying thing is that SPF is techically superior to TXT is lots of ways. 1. It uniquely identifies the roll of the record. 2. As SPF records are singletons you don't need to identify and remove the old record when updating. You can just remove all SPF record and add the replacement. For TXT you need to lookup the existing RRset, extract the v=spf1 record from it. You then need to create a UPDATE message to delete just that record as well as add the new TXT record. You then have to hope that no one else is performing a simultanious update as you may get two TXT v=spf1 records in the RRset. The complains about using SPF is that there are broken firewalls and some servers drop queries for it, some registars don't support it. For firewalls, fix/replace the firewall if you intend to deploy SPF and it doesn't support it. It is total !@##@# that firewall are incapable of handling new DNS record types. New records we exected to occur from the very beginning and have been coming out regularly ever since the DNS was invented. Firewall vendors that are incapable of handling new DNS types are incompetent and do not deserve repeat business. For servers than drop SPF queries they really are at the noise level. When you identify one you complain to the owners of it. Yes, that does work. We needed to do that for AAAA records. For registrars, change registrar to one that does. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From superuser@gmail.com Mon Apr 29 16:22: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 32C6121F9BA4 for ; Mon, 29 Apr 2013 16:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVDEDcweZfcx for ; Mon, 29 Apr 2013 16:21:59 -0700 (PDT) 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 54B8E21F9B60 for ; Mon, 29 Apr 2013 16:21:58 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id l13so3567602wie.3 for ; Mon, 29 Apr 2013 16:21:57 -0700 (PDT) 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=dnrs/OLbIJhrwO72iHZS86zcoLtk02dQBZTatSG2Aok=; b=FPy753hTxYAOl7qrctcYWjknx+FUbGTmD/WEmiqeUiBwSDNXJMgBIdSCwDfdOMLZj4 bBemE+2MtHcuMOCbWSAAFOyoWrl0BQCAN4riATnfTdISchUo3J2hpGifnJG4V2PT4Aqy JUNVd4rJxvX+Ymel2ItbvlU9TkGFPJROS1QIvB1Th+n3BQCSpTV1p+0zX/wByqiG8k1C oTxtHV9LFHVziZtYf+yAs3GkCI4jCGVRDBFbqq13GOx3vSUX92QfKdsEsvX7LexR0jRV 2mlJQXrvj5I2cqu6dmMvpx6Wq1YzB+90LPXVkOqkCpip62aDBS4ZYXf8GUb76glvC+mR IKTA== MIME-Version: 1.0 X-Received: by 10.194.222.100 with SMTP id ql4mr55722899wjc.59.1367277717422; Mon, 29 Apr 2013 16:21:57 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 29 Apr 2013 16:21:57 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130429024006.0a9a7e18@elandnews.com> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <6.2.5.6.2.20130429024006.0a9a7e18@elandnews.com> Date: Mon, 29 Apr 2013 16:21:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=001a11c1b942a8084b04db88268a Cc: "spfbis@ietf.org" , Arthur Thisell Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 29 Apr 2013 23:22:03 -0000 --001a11c1b942a8084b04db88268a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 29, 2013 at 1:59 PM, S Moonesamy wrote: > Hi Murray, Hello! Replying only to the parts that need further discussion: > > 'Note that requirements for the domain presented in the EHLO or HELO >> command are not always clear to the sending party, and SPF verifiers >> MUST be prepared for the "HELO" identity to be malformed or an IP >> address literal.' >> >> This RFC 2119 "MUST" is not in RFC 4408. It is a substantive change in >> my opinion. >> > > This was probably at my suggestion. The issue here is that RFC2119 >> doesn't say "must" has any different meaning than "MUST" does, so we should >> either be consistant and uppercase-ize it, or use some other word. >> > > Authur Thisell mentioned that some of the lower-case (RFC 2119) words in > RFC 4408 were intentional. Barry Leiba, as Area Director, commented about > "[treating] changes with due scepticism, with the idea that the change was > made to fix a real problem, and it had better be right" [1]. I prefer not > to bring the usual RFC 2119 discussion into this working group. RFC 4408 > has been around for several years. If there is a real problem there would > be some discussion about it. I would appreciate if someone points me to > that discussion. I suggest asking the ADs for guidance about the "must" vs. "MUST" issue. I believe Pete may have already commented on it. However, I also believe the "fix" is pretty easy, which avoids the issue altogether, for cases where we used "must" in RFC4408 without meaning "MUST" in the RFC2119 sense. My original review of RFC4408bis focused on changing "must" (where it was meant normatively) to "MUST", and to some other word otherwise. > > In any event, I don't agree that this is actually a substantive change. >> > > See above. Ditto. :-) > > "This SPF check can only be performed when the "HELO" string is a >> valid fully qualified domain." >> >> What is a valid fully qualified domain? >> >> I believe it means "a name comprising a sequence of DNS labels, separated >> by dot characters, which when queried resolve to an A or MX record". It >> may have a proper definition in some other RFC too. Should we add one in >> the Introduction or Definitions? >> > > I suggest dropping "valid" as the quick fix (see below). I'll defer to > RFC 5321 instead of having to add more text. Well, it has to resolve. SPF doesn't give you a definitive answer where the FQDN can't be resolved. One could argue that the check can't be performed when that happens. I think that's why "valid" is used there. Is there a better way to say it? > >> "Implementations have to take care to correctly extract the >> from the data given with the SMTP MAIL FROM command as many MTAs will >> still accept such things as source routes ..." >> >> The definition of is: >> >> 'the domain portion of the "MAIL FROM" or "HELO" identity.' >> >> I am not sure whether it is even a definition. From an implementation >> perspective the last paragraph of Section 2.4 is unclear. >> >> I don't agree. I imagine by now you're aware of what this is for; can >> you suggest some other text that accomplishes the intent? >> > > definitions (not sure whether it is a definition) are mentioned > in two places. I suggest fixing that and then getting back to the above. How is it not a definition? I do agree with having it in one place, however. > 'Generating non-delivery notifications to forged identities that have >> failed the authorization check is a source of backscatter and SHOULD >> be avoided.' >> >> This RFC 2119 SHOULD is not in RFC 4408. The above does not have >> anything to do with Sender Policy Framework. It was mentioned during WG >> discussions that "SPF can help the backscatter problem" [2]. This text may >> have been introduced in response to a review [3]. Is this an enhancement >> or a clarification? >> >> >> I think it documents operational experience acquired since RFC4408 was >> published. As for whether RFC2119 language is appropriate, I agree that it >> isn't; it has nothing to do with SPF itself, though it is a side effect of >> its use. I suggest changing SHOULD to "needs to". >> > > My reading of the above is that it is neither an enhancement or a > clarification. I suggest removing the text. I think RFC4408 paints an incomplete picture of the decision-making process when handling rejections other than at SMTP time, and thus this qualifies as clarifying language. I understand your concern here, but I suggest we push it up the chain under that argument. > "If a published record contains multiple character-strings, then the >> record MUST be treated as if those strings are concatenated together >> without adding spaces." >> >> This RFC 2119 MUST is also in RFC 4408. I suggest removing the "MUST" in >> the example. >> >> I disagree. It's required for interoperability. >> > > Interoperability requirements are not specified through examples. It isn't, it's in the prose. The example is illustrative, not normative. > > In Section 4: >> >> "A compliant SPF implementation MUST do something semantically >> equivalent to >> this description." >> >> It's unusual to see a "do something" RFC 2119 requirement in a >> specification. Is the SPFBIS WG working on compliance for SPF >> implementations? >> >> >> RFC6376 is an example of a standards track document that uses RFC2119 >> MUST in this way. I'm sure I've seen others but I can't think of them at >> this hour. I think it's fine. >> > > I suggest fixing the "do something". Sure. > > In Section 4.3: >> >> "If the is malformed (e.g. label longer than 63 characters, >> zero-length label not at the end, etc.)" >> >> That should be "octets". >> >> Since the DNS is all in ASCII, they're synonymous. That said, we may as >> well be consistent. >> > > DNS is not all in ASCII but let's avoid that side-discussion. Labels are, and that's what is. > 'Alternatively, for a server failure (RCODE 2) result, check_host() >> MAY track failures and treat multiple failures within 24 hours for >> the same domain as "permerror".' >> >> This text is not in RFC 4408. I found a note in Issue #1 [5] and in a >> message [6]. >> >> Are there any implementations that do this? If so, that's the >> justification; it's practical experience. If not, we should consider >> dropping it. >> > > I'll wait for feedback on this. I think in retrospect that this runs into the clarifications restriction, which this isn't. Though useful advice, the charter may not allow it. 'MTAs or other processors SHOULD impose a limit on the maximum amount >> of elapsed time to evaluate check_host(). Such a limit SHOULD allow >> at least 20 seconds. If such a limit is exceeded, the result of >> authorization SHOULD be "temperror".' >> >> There are three RFC 2119 SHOULDs in the above. I suggest rewriting the >> text to reduce that. >> >> All three of them seem to be important interoperability points. We could >> common factor the SHOULD and then present three bullets in a list, but the >> meaning is the same. >> > > Throughout the document the words "MTA", "other processors", "mail > receivers", "SPF implementations" and "SPF verifiers" are used. That looks > inconsistent to me. > > Here's an example of a rewrite: > > MTA or other processors SHOULD: > > (a) impose a limit on the maximum amount of elapsed time to evaluate > check_host(). > > (b) allow for at least 20 seconds. > > (c) return a result of authorization of "temperror". > > I don't see what Points (a) or (b) has to do with interoperability. > Trying to common factor the RFC 2119 SHOULD reduces occurrences of the > word instead of addressing the issue. I suggest understanding the intent > first before working on the text to be added. Now that you say it that way, I have to agree. However, that text appeared in RFC4408, so it's a matter of removing or reworking text that was there before. Weren't we favouring no changes? > "In this case, a default of two is RECOMMENDED." >> >> Why is "two" recommended? >> >> Interoperability; if one is two while another is 10, different SPF >> results can be returned. >> > > Here is the text: > > "An implementation MAY choose to make such a limit configurable. In > > this case, a default of two is RECOMMENDED." > > There is the RFC 2119 SHOULD and the RFC 2119 RECOMMENDED. > > Here's how I look at it: Is the working group recommending a limit which > is configurable? What's the recommended value? Is the value some > arbitrary number? I believe all of those questions have been answered; it's just a matter of adding some prose to cover it. > > In Section 5.5: >> >> "This mechanism SHOULD NOT be used." >> >> I suggest providing a reason for this. >> >> >> The very next sentence is "See below for discussion." >> > > It would be clearer to have: > > This mechanism SHOULD NOT be used it is not as reliable as other > mechanisms in > cases of DNS errors, and it places a large burden on the .arpa name > servers. As long as that's not redundant to the referenced discussion, sure. > > >> In Section 5.6: >> >> "ip6-network = " >> >> I suggest that the above reference be verified for correctness. >> >> >> Looks right to me. The CIDR expression is in the optional token next to >> it, so this has to be just a plain IPv6 address, so that's the right >> reference. >> > > I suggest reading RFC 5952. Yes, that one's better. > In Section 5.7: >> >> 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{**d} -all' >> >> I'll flag this for review by DNS folks. >> >> What's the specific question being asked of DNSDIR here? >> > > My question would be: "Is Section 5.7 of the draft correct?". I'm not sure that's a good question for them as they'll have to try to figure out our intent. I'm worried that they'll come back with a "You shouldn't do it this way" and some encouragement to replace the mechanism with something else. That would be a protocol change, and that's out of scope. I suggest a more restricted question, like "Is this harmful?" In Section 6: > > 'The modifiers defined in this document ("redirect" and "exp") MAY > appear anywhere in the record, but SHOULD appear at the end, after > all mechanisms.' > > This text is in RFC 4408. I would label the RFC 2119 usage as defective. > > > Why? > The text tells me that it is ok if the modifiers appear anywhere but they > should appear at the end after all mechanisms. It would be clearer to say > that it should appear after all mechanisms. If you mean "get rid of the MAY" clause, I'm fine with that because it doesn't add anything. An explanation of why would be helpful here too. > > >> "This SHOULD be a fully qualified domain name, but if one does not >> exist (as when the checking is done by a MUA) or if policy restrictions >> dictate otherwise, the word "unknown" SHOULD be substituted." >> >> The RFC 2119 key words are in RFC 2119. I don't know what to say. >> >> >> I think that looks fine as-is, though we could change the first SHOULD to >> "ought to" because it's a transformation of other input and not an >> implementation choice. (And I assume you mean they were in RFC4408.) >> > > Yes, I meant that there were in RFC 4408. I suggest that the working > group looks for a simple sentence to replace the existing one. > > I think any reduction beyond what I suggested above loses information. > "When the result of macro expansion is used in a domain name query, if >> the expanded domain name exceeds 253 characters (the maximum length >> of a domain name), the left side is truncated to fit, by removing >> successive domain labels (and their following dots) until the total >> length does not exceed 253 characters." >> >> Where is it specified that the maximum length of a domain name is 253 >> characters? >> >> >> RFC1035 says it's 255. >> > ...which is to say I agree that I don't understand why it says 253 there. > >> "Care has to be taken by the sending ADMD so that macro expansion for >> legitimate email does not exceed the 63-character limit on DNS labels." >> >> Where is that 63-character limit specified? >> >> >> RFC1035, Section 2.3.1. >> > > I suggest using Section 2.3.4. Either's fine. > > In Section 10.1.2: >> >> "Publishing SPF records for domains that send no mail is >> a well established best practice." >> >> I am not aware of that best practice. I did a few DNS queries: >> >> ;; QUESTION SECTION: >> ;bing.com. IN TXT >> >> ;; ANSWER SECTION: >> bing.com. 3600 IN TXT "v=msv1 >> t=6097A7EA-53F7-4028-BA76-**6869CB284C54" >> >> ;; QUESTION SECTION: >> ;com.com. IN TXT >> >> ;; ANSWER SECTION: >> com.com. 293 IN TXT "google-site-verification:** >> esSnoZdChIkkfCfS9MMgqNhE0yaXfn**nZWdZPuBf7e8k" >> >> >> What are you saying here? This is an existence proof of non-mailing >> domains that don't publish SPF records, but it doesn't contradict the >> statement made in the draft. >> > > The claim is being made without any supporting material. But it's a true claim, and applicability statements and technical specifications describe best practices all the time. What evidence could we include to support it? > > Why is RFC 3864 a normative reference? >> >> A BCP (e.g., a registration procedure) followed is always a normative >> reference, I believe. >> > > I guess it is a matter of style. ...or precedent. :-) > > In Appendix C: >> >> In Section E.1: >> >> 'This would cause a lookup on an DNS white list (DNSWL) and cause a >> result of "fail" only for email not either coming from the >> domain's mx host(s) (SPF pass) or white listed sources (SPF >> neutral).' >> >> I didn't find any discussion about this on the SPFBIS mailing list. is >> there an explanation for this change between RFC 4408 and this draft? >> >> >> It was in 9.3 in the previous document and has been reworded a little. >> It's otherwise unchanged. >> > > The text from Section 9.3 is already in the draft. This is additional > material instead of a little rewording. There was a concern about "a > tendency to include an example of every possible use of SPF to solve some > problem". I suggest removing the example. But this just a relocation of text already in 4408. I don't think removing it is justified even if it's part of the (original) clutter. -MSK --001a11c1b942a8084b04db88268a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 29, 2013 at 1:59 PM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
Hi Murray,

H= ello!

Replying only to the parts that need further discus= sion:
=A0
=A0=A0 'Note that requirements for the domain presented in the EHLO or = HELO
=A0 =A0 command are not always clear to the sending party, and SPF verifier= s
=A0 =A0 MUST be prepared for the "HELO" identity to be malformed = or an IP
=A0 =A0 address literal.'

This RFC 2119 "MUST" is not in RFC 4408. =A0It is a substantive c= hange in my opinion.

This was probably at my suggestion. =A0The issue here is that RFC2119 doesn= 't say "must" has any different meaning than "MUST"= does, so we should either be consistant and uppercase-ize it, or use some = other word.

Authur Thisell mentioned that some of the lower-case (RFC 2119) words in RF= C 4408 were intentional. =A0Barry Leiba, as Area Director, commented about = "[treating] changes with due scepticism, with the idea that the change= was made to fix a real problem, and it had better be right" [1]. =A0I= prefer not to bring the usual RFC 2119 discussion into this working group.= =A0RFC 4408 has been around for several years. =A0If there is a real probl= em there would be some discussion about it. =A0I would appreciate if someon= e points me to that discussion.

I suggest asking the ADs for guidance about the "m= ust" vs. "MUST" issue.=A0 I believe Pete may have already co= mmented on it.=A0 However, I also believe the "fix" is pretty eas= y, which avoids the issue altogether, for cases where we used "must&qu= ot; in RFC4408 without meaning "MUST" in the RFC2119 sense.=A0 My= original review of RFC4408bis focused on changing "must" (where = it was meant normatively) to "MUST", and to some other word other= wise.
=A0

In any event, I don't agree that this is actually a substantive change.=

See above.

Ditto.=A0 :-)
=A0

=A0 =A0"This SPF check can only be performed when the "HELO"= string is a
=A0 =A0valid fully qualified domain."

What is a valid fully qualified domain?

I believe it means "a name comprising a sequence of DNS labels, separa= ted by dot characters, which when queried resolve to an A or MX record"= ;. =A0It may have a proper definition in some other RFC too. =A0Should we a= dd one in the Introduction or Definitions?

I suggest dropping "valid" as the quick fix (see below). =A0I'= ;ll defer to RFC 5321 instead of having to add more text.
=
Well, it has to resolve.=A0 SPF doesn't give you a defin= itive answer where the FQDN can't be resolved.=A0 One could argue that = the check can't be performed when that happens.=A0 I think that's w= hy "valid" is used there.=A0 Is there a better way to say it?



=A0 "Implementations have to take care to correctly extract the <do= main>
=A0 =A0from the data given with the SMTP MAIL FROM command as many MTAs wil= l
=A0 =A0still accept such things as source routes ..."

The definition of <domain> is:

=A0 'the domain portion of the "MAIL FROM" or "HELO"= ; identity.'

I am not sure whether it is even a definition. =A0From an implementation pe= rspective the last paragraph of Section 2.4 is unclear.

I don't agree. =A0I imagine by now you're aware of what this is for= ; can you suggest some other text that accomplishes the intent?

<domain> definitions (not sure whether it is a definition) are mentio= ned in two places. =A0I suggest fixing that and then getting back to the ab= ove.

How is it not a definition?

I do agree with having it in one place, however.=

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=A0 'Generating non-delivery notifications to forged identities that ha= ve
=A0 =A0failed the authorization check is a source of backscatter and SHOULD=
=A0 =A0be avoided.'

This RFC 2119 SHOULD is not in RFC 4408. =A0The above does not have anythin= g to do with Sender Policy Framework. =A0It was mentioned during WG discuss= ions that "SPF can help the backscatter problem" [2]. =A0This tex= t may have been introduced in response to a review [3]. =A0Is this an enhan= cement or a clarification?


I think it documents operational experience acquired since RFC4408 was publ= ished. =A0As for whether RFC2119 language is appropriate, I agree that it i= sn't; it has nothing to do with SPF itself, though it is a side effect = of its use. =A0I suggest changing SHOULD to "needs to".

My reading of the above is that it is neither an enhancement or a clarifica= tion. =A0I suggest removing the text.

I think RF= C4408 paints an incomplete picture of the decision-making process when hand= ling rejections other than at SMTP time, and thus this qualifies as clarify= ing language.=A0 I understand your concern here, but I suggest we push it u= p the chain under that argument.


=A0 "If a published record contains multiple character-strings, then t= he
=A0 =A0record MUST be treated as if those strings are concatenated together=
=A0 =A0without adding spaces."

This RFC 2119 MUST is also in RFC 4408. =A0I suggest removing the "MUS= T" in the example.

I disagree. =A0It's required for interoperability.

Interoperability requirements are not specified through examples.

It isn't, it's in the prose.=A0 The example = is illustrative, not normative.
=A0

In Section 4:

=A0 "A compliant SPF implementation MUST do something semantically equ= ivalent to
=A0 this description."

It's unusual to see a "do something" RFC 2119 requirement in = a specification. =A0Is the SPFBIS WG working on compliance for SPF implemen= tations?


=A0RFC6376 is an example of a standards track document that uses RFC2119 MU= ST in this way. =A0I'm sure I've seen others but I can't think = of them at this hour. =A0I think it's fine.

I suggest fixing the "do something".

<= div>Sure.
=A0
=
In Section 4.3:

=A0 "If the <domain> is malformed (e.g. label longer than 63 cha= racters,
=A0 =A0zero-length label not at the end, etc.)"

=A0That should be "octets".

Since the DNS is all in ASCII, they're synonymous. =A0That said, we may= as well be consistent.

DNS is not all in ASCII but let's avoid that side-discussion.

Labels are, and that's what <domain> is.

=A0 'Alternatively, for a server failure (RCODE 2) result, check_host()=
=A0 =A0MAY track failures and treat multiple failures within 24 hours for =A0 =A0the same domain as "permerror".'

This text is not in RFC 4408. =A0I found a note in Issue #1 [5] and in a me= ssage [6].

Are there any implementations that do this? =A0If so, that's the justif= ication; it's practical experience. =A0If not, we should consider dropp= ing it.

I'll wait for feedback on this.

I think= in retrospect that this runs into the clarifications restriction, which th= is isn't.=A0 Though useful advice, the charter may not allow it.
=A0

=A0 =A0'MTAs or other processors SHOULD impose a limit on the maximum a= mount
=A0 =A0of elapsed time to evaluate check_host(). =A0Such a limit SHOULD all= ow
=A0 =A0at least 20 seconds. =A0If such a limit is exceeded, the result of =A0 =A0authorization SHOULD be "temperror".'

There are three RFC 2119 SHOULDs in the above. =A0I suggest rewriting the t= ext to reduce that.

All three of them seem to be important interoperability points. =A0We could= common factor the SHOULD and then present three bullets in a list, but the= meaning is the same.

Throughout the document the words "MTA", "other processors&q= uot;, "mail receivers", "SPF implementations" and "= ;SPF verifiers" are used. =A0That looks inconsistent to me.

Here's an example of a rewrite:

=A0 MTA or other processors SHOULD:

=A0 (a) impose a limit on the maximum amount of elapsed time to evaluate ch= eck_host().

=A0 (b) allow for at least 20 seconds.

=A0 (c) return a result of authorization of "temperror".

I don't see what Points (a) or (b) has to do with interoperability. =A0= Trying to common factor the RFC 2119 SHOULD reduces occurrences of the word= instead of addressing the issue. =A0I suggest understanding the intent fir= st before working on the text to be added.

Now that you say it that way, I have to agree.=A0 Howev= er, that text appeared in RFC4408, so it's a matter of removing or rewo= rking text that was there before.=A0 Weren't we favouring no changes?

=A0 "In this case, a default of two is RECOMMENDED."

Why is "two" recommended?

Interoperability; if one is two while another is 10, different SPF results = can be returned.

Here is the text:

=A0 "An implementation MAY choose to make such a limit configurable. = =A0In

=A0 =A0this case, a default of two is RECOMMENDED."

There is the RFC 2119 SHOULD and the RFC 2119 RECOMMENDED.

Here's how I look at it: Is the working group recommending a limit whic= h is configurable? =A0What's the recommended value? =A0Is the value som= e arbitrary number?

I believe all of those = questions have been answered; it's just a matter of adding some prose t= o cover it.
=A0

In Section 5.5:

=A0"This mechanism SHOULD NOT be used."

I suggest providing a reason for this.


The very next sentence is "See below for discussion."

It would be clearer to have:

=A0 =A0This mechanism SHOULD NOT be used it is not as reliable as other mec= hanisms in
=A0 =A0cases of DNS errors, and it places a large burden on the .arpa name = servers.

As long as that's not redundan= t to the referenced discussion, sure.
=A0


In Section 5.6:

=A0 "ip6-network =A0 =A0 =A0=3D <as per [RFC 4291], section 2.2>= "

I suggest that the above reference be verified for correctness.


Looks right to me. =A0The CIDR expression is in the optional token next to = it, so this has to be just a plain IPv6 address, so that's the right re= ference.

I suggest reading RFC 5952.

=A0Yes, that on= e's better.


In Section 5.7:

=A0 'v=3Dspf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all'

I'll flag this for review by DNS folks.

What's the specific question being asked of DNSDIR here?

My question would be: "Is Section 5.7 of the draft correct?".

I'm not sure that's a goo= d question for them as they'll have to try to figure out our intent.=A0= I'm worried that they'll come back with a "You shouldn't = do it this way" and some encouragement to replace the mechanism with s= omething else.=A0 That would be a protocol change, and that's out of sc= ope.

I suggest a more restricted question, like "Is this harmful?"=

In Section 6:

=A0 'The modifiers defined in this document ("redirect" and &= quot;exp") MAY
=A0 =A0appear anywhere in the record, but SHOULD appear at the end, after =A0 =A0all mechanisms.'

This text is in RFC 4408. =A0I would label the RFC 2119 usage as defective.=


Why?

The text tells me that it is ok if the modifiers appear anywhere but they s= hould appear at the end after all mechanisms. =A0It would be clearer to say= that it should appear after all mechanisms.

If you mean "get rid of the MAY" clause, I'm fine with t= hat because it doesn't add anything.=A0 An explanation of why would be = helpful here too.
=A0


=A0 "This SHOULD be a fully qualified domain name, but if one does not=
=A0 =A0exist (as when the checking is done by a MUA) or if policy restricti= ons
=A0 =A0dictate otherwise, the word "unknown" SHOULD be substitute= d."

The RFC 2119 key words are in RFC 2119. =A0I don't know what to say.

I think that looks fine as-is, though we could change the first SHOULD to &= quot;ought to" because it's a transformation of other input and no= t an implementation choice. =A0(And I assume you mean they were in RFC4408.= )

Yes, I meant that there were in RFC 4408. =A0I suggest that the working gro= up looks for a simple sentence to replace the existing one.


I think any reduction beyond w= hat I suggested above loses information.


=A0 "When the result of macro expansion is used in a domain name query= , if
=A0 =A0the expanded domain name exceeds 253 characters (the maximum length<= br> =A0 =A0of a domain name), the left side is truncated to fit, by removing =A0 =A0successive domain labels (and their following dots) until the total<= br> =A0 =A0length does not exceed 253 characters."

Where is it specified that the maximum length of a domain name is 253 chara= cters?


RFC1035 says it's 255.

...which is to say I agree that I don't understand why it says 2= 53 there.
=A0

=A0 "Care has to be taken by the sending ADMD so that macro expansion = for
=A0 =A0legitimate email does not exceed the 63-character limit on DNS label= s."

Where is that 63-character limit specified?


RFC1035, Section 2.3.1.

I suggest using Section 2.3.4.

Either's= fine.
=A0
In Section 10.1.2:

=A0 "Publishing SPF records for domains that send no mail is
=A0 =A0a well established best practice."

I am not aware of that best practice. =A0I did a few DNS queries:

;; QUESTION SECTION:
;bing.com. =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IN =A0 =A0 =A0TXT

;; ANSWER SECTION:
bing.com. =A0 =A0 =A0 =A0= =A0 =A0 =A0 3600 =A0 =A0IN =A0 =A0 =A0TXT =A0 =A0 "v=3Dmsv1 t=3D6097A= 7EA-53F7-4028-BA76-6869CB284C54"

;; QUESTION SECTION:
;com.com. =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 IN =A0 =A0 =A0TXT

;; ANSWER SECTION:
com.com. =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0293 =A0 =A0 IN =A0 =A0 =A0TXT "google-site-verification= :esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k"


What are you saying here? =A0This is an existence proof of non-mailing doma= ins that don't publish SPF records, but it doesn't contradict the s= tatement made in the draft.

The claim is being made without any supporting material.
<= br>
But it's a true claim, and applicability statements and t= echnical specifications describe best practices all the time.=A0 What evide= nce could we include to support it?
=A0

Why is RFC 3864 a normative reference?

A BCP (e.g., a registration procedure) followed is always a normative refer= ence, I believe.

I guess it is a matter of style.

...or prec= edent.=A0 :-)
=A0

In Appendix C:

In Section E.1:

=A0 'This would cause a lookup on an DNS white list (DNSWL) and cause a=
=A0 =A0result of "fail" only for email not either coming from the=
=A0 =A0domain's mx host(s) (SPF pass) or white listed sources (SPF
=A0 =A0neutral).'

I didn't find any discussion about this on the SPFBIS mailing list. =A0= is there an explanation for this change between RFC 4408 and this draft?

It was in 9.3 in the previous document and has been reworded a little. =A0I= t's otherwise unchanged.

The text from Section 9.3 is already in the draft. =A0This is additional ma= terial instead of a little rewording. =A0There was a concern about "a = tendency to include an example of every possible use of SPF to solve some p= roblem". =A0I suggest removing the example.

But this just a relocation of text already in 4408.=A0 = I don't think removing it is justified even if it's part of the (or= iginal) clutter.

-MSK
--001a11c1b942a8084b04db88268a-- From johnl@iecc.com Mon Apr 29 17:11: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 69B9421F99CB for ; Mon, 29 Apr 2013 17:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.15 X-Spam-Level: X-Spam-Status: No, score=-109.15 tagged_above=-999 required=5 tests=[AWL=2.050, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGvNUY8ckXqt for ; Mon, 29 Apr 2013 17:11:25 -0700 (PDT) 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 A67B621F98E4 for ; Mon, 29 Apr 2013 17:11:24 -0700 (PDT) Received: (qmail 12890 invoked from network); 30 Apr 2013 00:11:23 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Apr 2013 00:11:23 -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; s=517f0c2b.xn--30v786c.k1304; i=johnl@user.iecc.com; bh=q03gioCkvamo+OCpg9YQzVZk/f5Wt4lBQBHGfnYcFK0=; b=VPN7MWNYIjuzp8LuCjGuqgQEFc2WD35nGBl3/vrxEvzENKsHvjp4mWW6umgZYDAoovLysXQUs6sYTUvHXpXx5Jl/gTATO9n04/WvGieZCts8Fzop57u6aWwkjiUST1DiTmgi3Sl0IyLl/pvrE38dLQ8sXgLEoPHXzflBvpv3dVY= 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; s=517f0c2b.xn--30v786c.k1304; olt=johnl@user.iecc.com; bh=q03gioCkvamo+OCpg9YQzVZk/f5Wt4lBQBHGfnYcFK0=; b=GdR/zy1sYJXjbY145dKUj58ocvZYZl50XKnUFClHyfKG/LSQVTLPK3eTa/SqimiNlOD3efl3WiIjY0wV3FHTIf7XwaZsEofhNyHU++Q/+tyfVUAr/ht/c5KWs6dRzR6KE3OO1DJZL7k8gehws7rvQDU6zhVgC4uTvxQ/fFFZwDw= Date: 30 Apr 2013 00:11:01 -0000 Message-ID: <20130430001101.8968.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] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 30 Apr 2013 00:11:29 -0000 >>> I believe it means "a name comprising a sequence of DNS labels, separated >>> by dot characters, which when queried resolve to an A or MX record". It >>> may have a proper definition in some other RFC too. Should we add one in >>> the Introduction or Definitions? >> >> I suggest dropping "valid" as the quick fix (see below). I'll defer to >> RFC 5321 instead of having to add more text. > >Well, it has to resolve. SPF doesn't give you a definitive answer where >the FQDN can't be resolved. It could just have a TXT record (presumably v=spf1 -all) and no A or MX. I agree that taking "valid" out is the easiest approach. >> 'Alternatively, for a server failure (RCODE 2) result, check_host() >>> MAY track failures and treat multiple failures within 24 hours for >>> the same domain as "permerror".' >>> >>> This text is not in RFC 4408. I found a note in Issue #1 [5] and in a >>> message [6]. >>> >>> Are there any implementations that do this? If so, that's the >>> justification; it's practical experience. If not, we should consider >>> dropping it. >> >> I'll wait for feedback on this. Not that I'm aware of. That looks to me like an optimization to do in the DNS cache, not in the client. >>> "Publishing SPF records for domains that send no mail is >>> a well established best practice." >>> >>> I am not aware of that best practice. I did a few DNS queries: >>> >>> ;; QUESTION SECTION: >>> ;bing.com. IN TXT Now, now, what Microsoft does isn't by definition a best practice (or worst, for that matter.) I certainly publish SPF -all for hosts with A records that have shown up in spam lists, typically old scraped message-IDs that look like addresses. R's, John From sm@elandsys.com Mon Apr 29 17:39: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 B328821F9B60 for ; Mon, 29 Apr 2013 17:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS7gIWtviGVw for ; Mon, 29 Apr 2013 17:39:44 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E77821F9B54 for ; Mon, 29 Apr 2013 17:39:44 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3U0dS76023288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Apr 2013 17:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367282379; bh=BllbyWm39HAQXwmrfYeFAIwjIaw1L5yfnYmvYxiJX+I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jhulutEAW9+Y/ckc2GSJTIR0QiutPbcqnBwO3ZWZQNMA2d/s740j/NWHhCg/ZNXnu zbnPXNHvK7DA1jhGGJmxN/17CNXJrFoT3Z5GgE6t3KowwjcOz1Tcv/oIVRk7YS4PZv iHioEOdscidCLoCiLQXWF75LggV4dsMheviTQm7g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367282379; i=@elandsys.com; bh=BllbyWm39HAQXwmrfYeFAIwjIaw1L5yfnYmvYxiJX+I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ezAeqQPrwbjngKpVT1HD8Ruw3bAisZ/o0I2OYUP+X6QV9LFDa/MGHio6E62sRSIXe WQB+Sf5AGNKEDrFSTFRYYXpHqU9DY+AcdQ3uT6wvScZAd544/bejY+AWylmS+XXG8H m+5WcVDZDx6E7LStgonoF/ltYcSDdFerY/f2pm/w= Message-Id: <6.2.5.6.2.20130429173637.0d95fd88@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 29 Apr 2013 17:38:55 -0700 To: dcrocker@bbiw.net From: S Moonesamy In-Reply-To: <517EE00D.8050401@dcrocker.net> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> <517EE00D.8050401@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 00:39:44 -0000 Hi Dave, At 14:03 29-04-2013, Dave Crocker wrote: >Folks, > >This is one of those threads that will go on for as long as people >seem to think they need to keep posting, but it won't make any >"progress" or resolve any issues. > >For that matter, I have no idea what anyone thinks they are >accomplishing by continuing to post on it, which raises the question >of why they keep bothering. > >And 'bothering' is what this thread mostly /is/ doing, in reducing >the S/N ratio. > >Please shut the thread down. May I humbly suggest leaving this matter to the SPFBIS WG Chairs? Thanks, S. Moonesamy From spf2@kitterman.com Mon Apr 29 17:42: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 1745421F9B14 for ; Mon, 29 Apr 2013 17:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[AWL=1.900, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ug-RSQBV5D5r for ; Mon, 29 Apr 2013 17:42:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A467021F9B63 for ; Mon, 29 Apr 2013 17:42:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B452820E411A; Mon, 29 Apr 2013 20:42:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367282530; bh=y5e99SJNAWTKGlO3NCyuxNOX1ljEh/M2nPafSJfnl9A=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RXxyXNbPP6T0EB7B8gSuRtFZXM/h/DJFECRYSynKKSPYHip/rvLOvxHcrcqXaJfPe EtaT7B0uu35U0neH9Iaoa3l/iKC6YvliIPx2Lwjqy3xKiMith1/oR7ka4zqm6VaN+f 2rzHV1w77NF/SNroB5QdUUtZWsF9RXlr1htL+NhI= 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 90E5820E409E; Mon, 29 Apr 2013 20:42:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 29 Apr 2013 20:42:09 -0400 Message-ID: <5030770.G8l1OVMDOL@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130430001101.8968.qmail@joyce.lan> References: <20130430001101.8968.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] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 30 Apr 2013 00:42:16 -0000 On Tuesday, April 30, 2013 12:11:01 AM John Levine wrote: > >> 'Alternatively, for a server failure (RCODE 2) result, check_host() > >> > >>> MAY track failures and treat multiple failures within 24 hours for > >>> the same domain as "permerror".' > >>> > >>> This text is not in RFC 4408. I found a note in Issue #1 [5] and in a > >>> message [6]. > >>> > >>> Are there any implementations that do this? If so, that's the > >>> justification; it's practical experience. If not, we should consider > >>> dropping it. > >> > >> I'll wait for feedback on this. > > Not that I'm aware of. That looks to me like an optimization to do in > the DNS cache, not in the client. This was issue #1 in the tracker: http://trac.tools.ietf.org/wg/spfbis/trac/ticket/1 It was discussed as a resolution to an operational issue discovered during SPF deployment. Scott K From dhc@dcrocker.net Mon Apr 29 17:42: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 7161021F9B79 for ; Mon, 29 Apr 2013 17:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yLoyvkvbjNM for ; Mon, 29 Apr 2013 17:42:34 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 84F4221F9B14 for ; Mon, 29 Apr 2013 17:42:34 -0700 (PDT) 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 r3U0gJXD012931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Apr 2013 17:42:22 -0700 Message-ID: <517F1366.8040707@dcrocker.net> Date: Mon, 29 Apr 2013 17:42:14 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: S Moonesamy References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> <517EE00D.8050401@dcrocker.net> <6.2.5.6.2.20130429173637.0d95fd88@resistor.net> In-Reply-To: <6.2.5.6.2.20130429173637.0d95fd88@resistor.net> 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.66]); Mon, 29 Apr 2013 17:42:22 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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: Tue, 30 Apr 2013 00:42:39 -0000 On 4/29/2013 5:38 PM, S Moonesamy wrote: >> Please shut the thread down. > > May I humbly suggest leaving this matter to the SPFBIS WG Chairs? How long should we wait? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Mon Apr 29 17:43: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 4BCC821F9B65; Mon, 29 Apr 2013 17:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ubopfs4LF9XS; Mon, 29 Apr 2013 17:43:48 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7547221F9B63; Mon, 29 Apr 2013 17:43:48 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3U0hYqO016663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Apr 2013 17:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367282626; bh=SlqggNBlhP8Zg8uSuIq/win+XpI83FvkNkls5U//OAA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IjkVxojJxZDa/wGmycdU4MXeCSgq/bxU7q+1gHqAT/0BmbCZyj/iL5s018ah77+fG SLtkilJ1vWRYDq2cyLGJzZjR1UvNB0KYpEBOHZrMZshLJTtS+c4Pfxp9e6YMHl3YiG OlV/RuybPyk9XbSytC3UkLNDis5iTO1HS9sOlG5Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367282626; i=@elandsys.com; bh=SlqggNBlhP8Zg8uSuIq/win+XpI83FvkNkls5U//OAA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hn/FFST3VRDoJaXsjdcARqc0dR6WTH1WjHrzIMkem+Xa0KS8QcVlwXRnCK6cHVeTw YNKikbHhRlLlTVF9tIjwM2Z3goaHICTJO2I0QAAiK0uNU5fFUGgYRngDeLZCWzvNaD PCU5sYoWI54ybB0f/Jyt+9VXA5cgtaoantPxzGW0= Message-Id: <6.2.5.6.2.20130429173928.0e94f6a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 29 Apr 2013 17:43:17 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <517EE2E3.3010003@isdg.net> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> <517EE00D.8050401@dcrocker.net> <517EE2E3.3010003@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, ietf@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 00:43:49 -0000 Hi Hector, At 14:15 29-04-2013, Hector Santos wrote: >If anyone wishes to see one aspect of what is wrong with IETF >Diversity, then see whats going on in SPF BIS WG where a key IETF >cog essentially attempts to shutdown discussions and communications, >attacks posters which by my estimate were making progress. > >Progress is a status quo - DON'T CHANGE THE RFC4408 SPECIFICATION in SPFBIS. > >Many in DNS community do not agree with the change of removing a >long term migration path to a SPF RRTYPE. In fact, not changing the >existing specification would end the issue and hopefully satisfy all >principles. The following messages were posted to the SPFBIS mailing list: http://www.ietf.org/mail-archive/web/spfbis/current/msg03593.html http://www.ietf.org/mail-archive/web/spfbis/current/msg03598.html It has also been mentioned that there are two long threads at: http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html http://www.ietf.org/mail-archive/web/dnsext/current/msg13025.html Regards, S. Moonesamy From sm@elandsys.com Mon Apr 29 17:58: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 E19D921F9B7B for ; Mon, 29 Apr 2013 17:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL5pKAPGVQvn for ; Mon, 29 Apr 2013 17:58:28 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 730AC21F9B5E for ; Mon, 29 Apr 2013 17:58:28 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3U0wCkI007310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Apr 2013 17:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367283504; bh=b4BRGs95Rq8ixZTRQ9ZKypwIoEiM2JDEXGPRuIrFpt0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=x+xJwKCbexqtGBzF4phdR7Oaao1KmTmlVg2JCZYg1L2PP6YAKbknUs4i6OVjjM2mV AT+ni9/HQUfPxayzbQ3T2s1JqHlYZLwEsATgBvYCSpTR+6BFm+TgqhwPAHejWgu19/ eJYeNnFkMI8WqxF18es8kXXEMFgEI6BZ0f9QQQ/8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367283504; i=@elandsys.com; bh=b4BRGs95Rq8ixZTRQ9ZKypwIoEiM2JDEXGPRuIrFpt0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=e8yM573pJeHMOrH5FzFm8MvASCKY+NnKWfu5pgfveCU3ledEv63sQN54g4FALESaZ bSUb/ZqULCeQn9I263QjJSPv5E45V5ljNTYIbPBbZH7HREwqrvz0LiIXq2g670C7BN qZ2zm2q6xLWJuKO2t6fiZlFxlhGU9rJY2w3ddsO0= Message-Id: <6.2.5.6.2.20130429174805.0ca902f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 29 Apr 2013 17:57:54 -0700 To: dcrocker@bbiw.net From: S Moonesamy In-Reply-To: <517F1366.8040707@dcrocker.net> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> <517EE00D.8050401@dcrocker.net> <6.2.5.6.2.20130429173637.0d95fd88@resistor.net> <517F1366.8040707@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 00:58:29 -0000 Hi Dave, At 17:42 29-04-2013, Dave Crocker wrote: >How long should we wait? I'll have to review all the messages posted on the thread and then discuss the matter with Andrew Sullivan. My current focus is the reviews and the follow-up. I am copying this message to the Responsible Area Director in case I am doing anything inappropriate. Regards, S. Moonesamy (SPFBIS WG co-chair) From dhc@dcrocker.net Mon Apr 29 17:59: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 3A76C21F9B8C for ; Mon, 29 Apr 2013 17:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRKB5dWU4XIT for ; Mon, 29 Apr 2013 17:59:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E73321F9B8F for ; Mon, 29 Apr 2013 17:59:43 -0700 (PDT) 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 r3U0xRUC013199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Apr 2013 17:59:30 -0700 Message-ID: <517F176A.7000000@dcrocker.net> Date: Mon, 29 Apr 2013 17:59:22 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: S Moonesamy References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> <517EE00D.8050401@dcrocker.net> <6.2.5.6.2.20130429173637.0d95fd88@resistor.net> <517F1366.8040707@dcrocker.net> <6.2.5.6.2.20130429174805.0ca902f0@elandnews.com> In-Reply-To: <6.2.5.6.2.20130429174805.0ca902f0@elandnews.com> 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.66]); Mon, 29 Apr 2013 17:59:30 -0700 (PDT) Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick , dcrocker@bbiw.net Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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: Tue, 30 Apr 2013 00:59:48 -0000 On 4/29/2013 5:57 PM, S Moonesamy wrote: > I'll have to review all the messages posted on the thread and then ack. tnx. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mansaxel@besserwisser.org Tue Apr 30 03: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 99BE821F9BA3 for ; Tue, 30 Apr 2013 03:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[AWL=1.899, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcWBkyBl0-D0 for ; Tue, 30 Apr 2013 03:29:57 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id E526E21F9B10 for ; Tue, 30 Apr 2013 03:29:56 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 209C49E57; Tue, 30 Apr 2013 12:29:51 +0200 (CEST) Date: Tue, 30 Apr 2013 12:29:51 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Ted Lemon Message-ID: <20130430102950.GA32695@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "" , Stuart Gathman Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 10:29:57 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Mon, Apr 29, 201= 3 at 05:31:53PM +0000 Quoting Ted Lemon (Ted.Lemon@nominum.com): > On Apr 29, 2013, at 11:24 AM, Stuart Gathman wrote: > > The idea is that you endure the TIMEOUT the first time only. If a TXT > > query then succeeds, you know you are dealing with a braindead > > server/firewall, and record the domain and timestamp in a database. =20 > > You check the database before making any SPF (type 99) query to avoid > > trying known braindead servers. >=20 > I think turning your SPF resolver into a non-compliant caching resolver i= s a bit heavyweight, though. That's effectively what you're doing here... Or not. It is the application that is told what to ask for. The resolver is (in all its brokenness) unaffected. Lithmus test: Can another applicatio= n=20 ask the same full-service resolver about SPF/99 and get responses?=20 If the resolver fails on all SPF/99; why is it so?=20 - is it because it is broken?=20 - is it because it is behind something broken?=20 Both cases need workaround if it is impossible to do the proper thing and fix the bad resolver/path. If the resolver returns proper data (ie. SPF/99 from where it is set up and NODATA from where it is not), the application should cache this and ask the right questions henceforth. In this case the resolver is not broken and the application adapts to the effects of 4408 semantics. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Somewhere in Tenafly, New Jersey, a chiropractor is viewing "Leave it to Beaver"! --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF/nR4ACgkQ02/pMZDM1cXn0QCeOER4SDAK/C0IxD8LZtdlUdXs yuwAoI8te7pzYqrL+rMm4Xj2+ZfAAvVF =uA6u -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From mansaxel@besserwisser.org Tue Apr 30 03:39: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 7180921F9A7F for ; Tue, 30 Apr 2013 03:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zYdY34Smswa for ; Tue, 30 Apr 2013 03:39:42 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id 3D34821F9A4D for ; Tue, 30 Apr 2013 03:39:41 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id DB2329E57; Tue, 30 Apr 2013 12:39:40 +0200 (CEST) Date: Tue, 30 Apr 2013 12:39:40 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Alessandro Vesely Message-ID: <20130430103940.GB32695@besserwisser.org> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <20130429034026.GB27654@besserwisser.org> <20130429050236.0B5DA3327423@drugs.dv.isc.org> <517E9910.3050602@tana.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PmA2V3Z32TCmWXqI" Content-Disposition: inline In-Reply-To: <517E9910.3050602@tana.it> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "spfbis@ietf.org" , Mark Andrews Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 10:39:43 -0000 --PmA2V3Z32TCmWXqI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Mon, Apr 29, 201= 3 at 06:00:16PM +0200 Quoting Alessandro Vesely (vesely@tana.it): =20 > A good deal of this thread assumes that TXT records are bad. Would > anyone say why? I read RFC 5507, and I'd agree that not using a > prefix such as _spf creates unneeded conflicts. However, I'm unable > to understand the reasons why "TXT is evil". =20 First, it's a parsing problem, since it requires additional processing in determining whether the TXT record at hand is SPF or not. Having Type 99 records limits the problem space. It does not, however eliminate it. Second, the risk of fallback to TCP (I'm not sure there even IS a software product that does not support SPF/99 while doing EDNS0, bar a few BIND versions.) is limited when TXT megablobs like=20 ut.edu. IN TXT=20 aren't to be encountered and sieved off enroute to the SPF data.=20 Third, a DNS update operation aimed at altering the SPF contents for a given node in DNS does not have to discern between cookie recipes and SPF data if the SPF data has a dedicated RRtype. If TXT is used all sorts of Heath Robinson machinery need to be employed, often in recursive fashion, to determine what to keep and what to remove. The risk of manual intervention is quite high. (Mark Andrews noted this in another thread) Finally (and I'm afraid the SPFbis crowd could hardly care less, but=20 that is just this junior protocol nerd being jaded) using TXT, expecially in the face of an existing special type, sets a bad precedent. The DNS is designed to evolve. We as DNS people _need_ it to evolve. We've just pulled a big change through, DNSSEC, which took all of 15 years and a number of RFCen. And a sizable bunch of the new record types Mark Andrews outlined upthread. DNSSEC makes the DNS not only secure to tampering, it also enables a big spectrum of new uses; DANE (RFC 6698) being one of special importance to the continued evolution of the Internet. This new level of trust in DNS published data could not have happened without a lot of work in getting name servers upgraded and new features rolled out. As a result, a lot of software supports DNSSEC. (some of the software available a few years back is investigated in this excellent report: https://www.iis.se/docs/DNSSEC-Admin-tools-review-Final.pdf) With SPFbis going out to a lot of implementers who are email people first and perhaps DNS operators a distant fourth, and in effect telling them "Well, this DNS stuff that is absolutely impossible to change is something you have to kludge around using this comment datatype and hope that the parser won't barf on someones cookie recipe" a seriously bad attitude is cemented, where other more pressing changes to DNS might be impossible to roll out because nobody thinks the DNS can be changed. Well, guess what, it can.=20 To be able to evolve further in the future, one of the observations from the earlier research in this wg (6686) is indeed important to keep in mind: There is a very long tail of old software out there. This, however, is not news to the DNS community. DNSSEC, EDNS0, TSIG, and a lot of new RRtypes were pulled in the system and continue to work in spite of very old and sometimes very broken software still in operation. This takes work, and work best performed in -bis wg contexts where there=20 is operational experience. The data in 6686 looks compelling and I can we= ll understand why the wg felt that the pain associated with DTRT would be=20 unbearable, and in the light of that, modifying 4408 3.1.1 to just discard SPF/99 is the easy way out. We can do better than that, though. As I hopefully have described above,=20 there are valid reasons to continue prescribing SPF/99. The text in 4408 3.1.1 does a bad job of that, and there probably is the reason why TXT deployment is so overwhelming. Nobody needed to even think of migrating out of the lab.=20 My suggestion stands roughly as before;=20 * SPF/99 is a MUST, * TXT containing SPF data MAY be used IF operations reveal problems with local or remote intermediate infrastructure, but this does not remove the requirement that SPF/99 be present to be compliant. We can't dictate what people run, but we should point out a good model.=20 * Querying should reflect above so that SPF/99 MUST be sought first.=20 * If SPF/99 query fails in obvious or suspicious ways, not exhausting the posibility of a TXT being present, a query for TXT SHOULD be made. * State for this (ie. the failure/success for given node names wrt SPF or TXT) SHOULD be kept but not too long. Probably less than 24h.=20 The validating application is responsible for this.=20 SPFBIS set out to codify and improve 4408, and this is a backwards-compatible and sustainable evolution of 4408 that won't harm the DNS or the email vetting community. > Do we need to create new > types whenever the use changes, as we do file extensions? As long as we get traction on using SPF/99, no. The rest can be done in-band.=20 --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Maybe we could paint GOLDIE HAWN a rich PRUSSIAN BLUE -- --PmA2V3Z32TCmWXqI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF/n2wACgkQ02/pMZDM1cVdlgCghvaiwkguBy3xlM1q0ULOWufP CHoAn1MkTQz7ucIfxcDuqnlJ9RnqE4Js =dOXC -----END PGP SIGNATURE----- --PmA2V3Z32TCmWXqI-- From vesely@tana.it Tue Apr 30 05:40: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 8FE2A21F9B44 for ; Tue, 30 Apr 2013 05:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.669 X-Spam-Level: X-Spam-Status: No, score=-4.669 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d-OAweavzNo for ; Tue, 30 Apr 2013 05:40:48 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4AC21F9B0B for ; Tue, 30 Apr 2013 05:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367325645; bh=Q+xpd3FcNzwlWyxYZYHJhQHTDr5vC2jf7PPIgJrJ3K8=; l=7861; h=Date:From:To:CC:References:In-Reply-To; b=vdhFxxHHtbsZeNak0vToMtaY1tfqcO8jIBtUSQAbqNEOHoFQwi+k5EQC9sSchqdkh H/sAJHwmYDei9/5+2iZKT5C/9l7Rk9Vk96MmDjuqaHYwyQoWtGQLq5VO8kf9DfbqO0 SK7D46NWsbqIupX4Nhky97bLkd7Vb4zyTYPHsNeM= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Tue, 30 Apr 2013 14:40:45 +0200 id 00000000005DC045.00000000517FBBCD.00002096 Message-ID: <517FBBCD.3010001@tana.it> Date: Tue, 30 Apr 2013 14:40:45 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?TcOlbnMgTmlsc3Nvbg==?= References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <20130429034026.GB27654@besserwisser.org> <20130429050236.0B5DA3327423@drugs.dv.isc.org> <517E9910.3050602@tana.it> <20130430103940.GB32695@besserwisser.org> In-Reply-To: <20130430103940.GB32695@besserwisser.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "spfbis@ietf.org" , Mark Andrews Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 12:40:52 -0000 On Tue 30/Apr/2013 12:39:40 +0200 MÃ¥ns Nilsson wrote: > Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Mon, Apr 29, 2013 at 06:00:16PM +0200 Quoting Alessandro Vesely (vesely@tana.it): > >> A good deal of this thread assumes that TXT records are bad. Would >> anyone say why? I read RFC 5507, and I'd agree that not using a >> prefix such as _spf creates unneeded conflicts. However, I'm unable >> to understand the reasons why "TXT is evil". > > First, it's a parsing problem, since it requires additional processing in > determining whether the TXT record at hand is SPF or not. Having Type > 99 records limits the problem space. It does not, however eliminate it. Yeah, sanitizing input is always needed. > Second, the risk of fallback to TCP (I'm not sure there even IS a > software product that does not support SPF/99 while doing EDNS0, bar a > few BIND versions.) is limited when TXT megablobs like > > ut.edu. IN TXT > > aren't to be encountered and sieved off enroute to the SPF data. There are some good points: EDNS0 would allow to relax the size a bit, which would be a good relief given the annoyance of breaking down lists of addresses into "include" records. This was discussed and the conclusion was that EDNS0 is not yet ready. Of course, having the syntax and size checks before publishing would be a great advantage, but this is so clearly not yet ready that it wasn't even discussed. I guess it's the same using SPF/99. > Third, a DNS update operation aimed at altering the SPF contents for > a given node in DNS does not have to discern between cookie recipes > and SPF data if the SPF data has a dedicated RRtype. If TXT is used all > sorts of Heath Robinson machinery need to be employed, often in recursive > fashion, to determine what to keep and what to remove. The risk of manual > intervention is quite high. (Mark Andrews noted this in another thread) You mean the zone file editor? Among the stuff of ut.edu there are snippets with CNAME that seem to be intended to belong to different records. Yeah, TXT is not syntax checked. But then so is SPF/99. > Finally (and I'm afraid the SPFbis crowd could hardly care less, but > that is just this junior protocol nerd being jaded) using TXT, expecially > in the face of an existing special type, sets a bad precedent. The DNS > is designed to evolve. We as DNS people _need_ it to evolve. We've just > pulled a big change through, DNSSEC, which took all of 15 years and > a number of RFCen. And a sizable bunch of the new record types Mark > Andrews outlined upthread. That's the point I made: Successful new types have a binary format which is syntax checked before going to the wire. I wish SPF was like that, but it's not. A /real/ SPF type would be very different from the fig leaf we've been using til now. > DNSSEC makes the DNS not only secure to tampering, it also enables a big > spectrum of new uses; DANE (RFC 6698) being one of special importance > to the continued evolution of the Internet. > > This new level of trust in DNS published data could not have happened > without a lot of work in getting name servers upgraded and new features > rolled out. As a result, a lot of software supports DNSSEC. (some of the > software available a few years back is investigated in this excellent > report: https://www.iis.se/docs/DNSSEC-Admin-tools-review-Final.pdf) TXT can be signed like any other record. > With SPFbis going out to a lot of implementers who are email people first > and perhaps DNS operators a distant fourth, and in effect telling them > "Well, this DNS stuff that is absolutely impossible to change is something > you have to kludge around using this comment datatype and hope that the > parser won't barf on someones cookie recipe" a seriously bad attitude is > cemented, where other more pressing changes to DNS might be impossible > to roll out because nobody thinks the DNS can be changed. > > Well, guess what, it can. Good news. However, it is not by asking mail admins to do something that is not yet supported that the DNS will change. DKIM may be a better example, because although it is computationally more complex, it is administratively simpler than SPF. When you set up DKIM you create keys, and the utility program terminates displaying "Hey, I prepared a TXT record for you to insert in the zone file." It is a public key, it wouldn't hurt to publish it anyway. The application is just unable to do it. Why? With SPF, in addition, the operator is required to manually keep track of all the data and compose the domain's policy. Aren't computers able to do that? No, there is the DNS that cannot be changed. Oh, well... > To be able to evolve further in the future, one of the observations from > the earlier research in this wg (6686) is indeed important to keep in > mind: There is a very long tail of old software out there. This, however, > is not news to the DNS community. DNSSEC, EDNS0, TSIG, and a lot of new > RRtypes were pulled in the system and continue to work in spite of very > old and sometimes very broken software still in operation. > > This takes work, and work best performed in -bis wg contexts where there > is operational experience. The data in 6686 looks compelling and I can well > understand why the wg felt that the pain associated with DTRT would be > unbearable, and in the light of that, modifying 4408 3.1.1 to just > discard SPF/99 is the easy way out. Yes. > We can do better than that, though. As I hopefully have described above, > there are valid reasons to continue prescribing SPF/99. The text in 4408 > 3.1.1 does a bad job of that, and there probably is the reason why TXT > deployment is so overwhelming. Nobody needed to even think of migrating > out of the lab. Yes. > My suggestion stands roughly as before; > > * SPF/99 is a MUST, For who? > * TXT containing SPF data MAY be used IF operations reveal problems with > local or remote intermediate infrastructure, but this does not remove > the requirement that SPF/99 be present to be compliant. We can't > dictate what people run, but we should point out a good model. That's error-prone. It roughly doubles the difficulties of maintaining a domain policy, and you cannot ask users to do that without offering some advantages in exchange. > * Querying should reflect above so that SPF/99 MUST be sought first. Querying a type first doesn't guarantee that the replies arrive in the same order. > * If SPF/99 query fails in obvious or suspicious ways, not exhausting > the posibility of a TXT being present, a query for TXT SHOULD be made. Ah, you mean _after the timeout_? No thanks. > * State for this (ie. the failure/success for given node names wrt SPF > or TXT) SHOULD be kept but not too long. Probably less than 24h. > The validating application is responsible for this. 24h seems to be a lot. Negative caching of servfail is recommended to be around five minutes, if at all. SPF would never have used DNS if the validating application had been required to maintain its own cache. > SPFBIS set out to codify and improve 4408, and this is a > backwards-compatible and sustainable evolution of 4408 that won't harm > the DNS or the email vetting community. Planning it that way would not harm, indeed, because of the silent convention that nobody will actually do it. Fig leaf. A realistic plan to introduce a new type must not provide for using TXT instead. >> Do we need to create new >> types whenever the use changes, as we do file extensions? > > As long as we get traction on using SPF/99, no. The rest can be done > in-band. Wouldn't it be savvier to start with easier types first? How about a RIPE type for the maintainer ID? From Ted.Lemon@nominum.com Tue Apr 30 05: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 A247621F9B44 for ; Tue, 30 Apr 2013 05:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MurqL4oRm-73 for ; Tue, 30 Apr 2013 05:44:56 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1544821F9B83 for ; Tue, 30 Apr 2013 05:44:56 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUX+8xBkWUF3ZTFRRtnkmvTkR/cWs+jSv@postini.com; Tue, 30 Apr 2013 05:44:56 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8163A1B8169 for ; Tue, 30 Apr 2013 05:44:52 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 750B9190061; Tue, 30 Apr 2013 05:44:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 30 Apr 2013 05:44:46 -0700 From: Ted Lemon To: =?iso-8859-1?Q?M=E5ns_Nilsson?= Thread-Topic: [spfbis] [dnsext] Obsoleting SPF RRTYPE Thread-Index: AQHOQ7g8BXubqTI8/ESMN/lsrU52YZjrcqEAgAEPEgCAAA0EgIAAKVGAgAAFVoCAAQvJAIAAGeQAgAEmKICAACWxgA== Date: Tue, 30 Apr 2013 12:44:46 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775168BFD@mbx-01.win.nominum.com> References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> <20130430102950.GA32695@besserwisser.org> In-Reply-To: <20130430102950.GA32695@besserwisser.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Stuart Gathman Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 12:45:07 -0000 On Apr 30, 2013, at 6:29 AM, M=E5ns Nilsson wro= te: > Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Mon, Apr 29, 2= 013 at 05:31:53PM +0000 Quoting Ted Lemon (Ted.Lemon@nominum.com): >> On Apr 29, 2013, at 11:24 AM, Stuart Gathman wrote: >>> The idea is that you endure the TIMEOUT the first time only. If a TXT >>> query then succeeds, you know you are dealing with a braindead >>> server/firewall, and record the domain and timestamp in a database. =20 >>> You check the database before making any SPF (type 99) query to avoid >>> trying known braindead servers. >>=20 >> I think turning your SPF resolver into a non-compliant caching resolver = is a bit heavyweight, though. That's effectively what you're doing here..= . >=20 > Or not. It is the application that is told what to ask for.=20 No, you misunderstand me. What I mean is that your "application" has *bec= ome* a non-compliant caching resolver. It is doing name resolution; it is= caching the results; but it is not following the protocol specification. = So this is not, IMHO, a reasonable alternative. From mansaxel@besserwisser.org Tue Apr 30 07:22: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 CA63221F9AB5 for ; Tue, 30 Apr 2013 07:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTsg8iHU4GRa for ; Tue, 30 Apr 2013 07:22:35 -0700 (PDT) Received: from jaja.besserwisser.org (primary.se [IPv6:2a01:298:4::53]) by ietfa.amsl.com (Postfix) with ESMTP id 64CB721F9AA3 for ; Tue, 30 Apr 2013 07:22:33 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 5810D9E57; Tue, 30 Apr 2013 16:22:31 +0200 (CEST) Date: Tue, 30 Apr 2013 16:22:31 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Ted Lemon Message-ID: <20130430142231.GC32695@besserwisser.org> References: <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> <20130430102950.GA32695@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775168BFD@mbx-01.win.nominum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nmemrqcdn5VTmUEE" Content-Disposition: inline In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775168BFD@mbx-01.win.nominum.com> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "" , Stuart Gathman Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 14:22:36 -0000 --nmemrqcdn5VTmUEE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Tue, Apr 30, 201= 3 at 12:44:46PM +0000 Quoting Ted Lemon (Ted.Lemon@nominum.com): > On Apr 30, 2013, at 6:29 AM, M=C3=A5ns Nilsson wrote: > > Or not. It is the application that is told what to ask for.=20 >=20 > No, you misunderstand me. What I mean is that your "application" has *b= ecome* a non-compliant caching resolver. It is doing name resolution; it = is caching the results; but it is not following the protocol specification.= So this is not, IMHO, a reasonable alternative. =20 I see what you mean. I might agree, and it is not necessarily something needed, so I'm prepared to drop it. --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Look DEEP into the OPENINGS!! Do you see any ELVES or EDSELS ... or a HIGHBALL?? ... --nmemrqcdn5VTmUEE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlF/06cACgkQ02/pMZDM1cUOoQCdHZdMiJzX4UHicNNIOpcB4ey4 GVQAnjFRDgFvf7gK3ZErn7tLm5gz2Ib9 =OpQK -----END PGP SIGNATURE----- --nmemrqcdn5VTmUEE-- From vesely@tana.it Tue Apr 30 08:57: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 4DDF221F9A7F for ; Tue, 30 Apr 2013 08:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.769 X-Spam-Level: X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoIIbUEnYo-C for ; Tue, 30 Apr 2013 08:57:36 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id AD2F721F9A6D for ; Tue, 30 Apr 2013 08:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367337454; bh=NxQvYYf9UArOzpWw4MK8FnFfvQ0G5nhLuSH+fU02YiI=; l=1642; h=Date:From:To:References:In-Reply-To; b=XaJ3K3PvURCzFQg0RqKWCghYwI1GzPypjMaCQIs2CpBbPy4HqrLW70lZ1hZ0/t/Bs H0ffs9ZpOgOsU9yOf+WLgeFD4tfMQQt+HbkdB96mMRovnw8HJNqJuzo0mYBrC+A1Jl 3IzWcJhxf20Yyc5BJSu3B4CVYaDAAFly5noFgDgA= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Tue, 30 Apr 2013 17:57:34 +0200 id 00000000005DC02B.00000000517FE9EE.00003004 Message-ID: <517FE9E5.10408@tana.it> Date: Tue, 30 Apr 2013 17:57:25 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <80ADB3EE-17FD-4628-B818-801CB71BCBFE@virtualized.org> <14A728AE-83DC-4C1F-A88A-6F988D37F2C7@frobbit.se> <20130425154235.GP23770@besserwisser.org> <5179691B.50602@qti.qualcomm.com> <5179980F.9090606@dougbarton.us> <5179B10E.705@qti.qualcomm.com> <5179C72F.1070703@dougbarton.us> <517E8895.1020609@tana.it> <517E958F.50709@gathman.org> In-Reply-To: <517E958F.50709@gathman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 15:57:47 -0000 On Mon 29/Apr/2013 17:45:19 +0200 Stuart Gathman wrote: > Long ago, Nostradamus foresaw that on 04/29/2013 10:49 AM, Alessandro > Vesely would write: >> >> Asking to duplicate the records on top of that is not a trivial >> request. There are no automated tools that duplicate records to >> different type, and if RR types make any sense at all, I'd guess there >> will never be. There are domains with SPF and TXT records different >> from one another, hence the possibility to introduce errors or >> inaccuracies is non-zero. On the other hand, the domain maintainer >> gets zero advantages. They just wont' do it, people would rather >> stop using spf than mess it up with double records. Is that a >> technical argument? > > RFC 4408 has said SHOULD publish both SPF and TXT for many years now. > As Mark Andrews pointed out, an equally simple way to avoid the > duplication is to say SHOULD publish *only* SPF. That still leaves > leeway for checkers to check TXT. As long as there is a practical > workaround for the braindead DNS server/firewall problem, there is no > reason *not* to do this. Neither there is a reason to do it. We could as well involve Leprechauns, but a principle of parsimony, economy, or succinctness suggests not to. > Very *un*technical observation: > I was so pleased when upgrading mail servers to RHEL6 - the supported > BIND *finally* has the SPF keyword! I had been running scripts to > generate hex coded TYPE99 records for older BIND versions. How > disappointed I was to shortly afterwards read that SPFBIS was dropping > SPF entirely! :-( I agree it's disappointing. From vesely@tana.it Tue Apr 30 09:28: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 30B8021F9BF8; Tue, 30 Apr 2013 09:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.761 X-Spam-Level: X-Spam-Status: No, score=-4.761 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRdUFi8P40TT; Tue, 30 Apr 2013 09:28:53 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A3DDA21F9AD4; Tue, 30 Apr 2013 09:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367339332; bh=wXfRTlSijDSqw++4AYOALJ9Sy8VQMl66XbXN+puR5y0=; l=1863; h=Date:From:To:CC:References:In-Reply-To; b=ZTR9HjKLfnU15nYG/F9Ut3WO3BBuGL6thyZk/qPfgSzOkc6PzLOG/Jfx+j4grA3bu NfmeIQyHkawhh62tEEX6hdQG7OKSL7nXBgSo8FIw/j+Ucwj7p7TMCR6hv1bUsxzut3 cC1PMLqpo7IwDoAtl+MoSE6fsxCZSaWXAJ58hIrw= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Tue, 30 Apr 2013 18:28:52 +0200 id 00000000005DC02B.00000000517FF144.00003FC4 Message-ID: <517FF144.5040600@tana.it> Date: Tue, 30 Apr 2013 18:28:52 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> <517EE00D.8050401@dcrocker.net> <517EE2E3.3010003@isdg.net> <20130429230742.3D2833339511@drugs.dv.isc.org> In-Reply-To: <20130429230742.3D2833339511@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "" , ietf@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 16:28:58 -0000 On Tue 30/Apr/2013 01:07:42 +0200 Mark Andrews wrote: > > The really annoying thing is that SPF is techically superior > to TXT is lots of ways. > > 1. It uniquely identifies the roll of the record. > > 2. As SPF records are singletons you don't need to identify > and remove the old record when updating. You can just > remove all SPF record and add the replacement. > > For TXT you need to lookup the existing RRset, extract > the v=spf1 record from it. You then need to create a > UPDATE message to delete just that record as well as add > the new TXT record. You then have to hope that no one > else is performing a simultanious update as you may get > two TXT v=spf1 records in the RRset. That's true, except that one has TXT records anyway. > The complains about using SPF is that there are broken > firewalls and some servers drop queries for it, some registars > don't support it. Nits, as explained below. The basic fact that killed the SPF type is the ability to use TXT as a replacement. There must be an analogous of Gresham's law: "Bad types drive out good ones." > For firewalls, fix/replace the firewall if you intend to > deploy SPF and it doesn't support it. It is total !@##@# > that firewall are incapable of handling new DNS record > types. New records we exected to occur from the very > beginning and have been coming out regularly ever since the > DNS was invented. Firewall vendors that are incapable of > handling new DNS types are incompetent and do not deserve > repeat business. > > For servers than drop SPF queries they really are at the > noise level. When you identify one you complain to the > owners of it. Yes, that does work. We needed to do that > for AAAA records. > > For registrars, change registrar to one that does. While it's too late for SPF, we can learn this lesson. From sm@elandsys.com Tue Apr 30 09:43: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 BBD0921F9C32 for ; Tue, 30 Apr 2013 09:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y418vdfHW2Hj for ; Tue, 30 Apr 2013 09:43:16 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3818621F9BFD for ; Tue, 30 Apr 2013 09:43:15 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3UGgpiR002477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Apr 2013 09:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367340185; bh=JQf+h4FVKCgvIXyDY4aZ9ZCBv8R+EnpjvY0Ug7OJs4A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ibBFmG1a1u9bPajWOtrUlb3c8iRC7Si8MeOYurri9/YhLdjN+HPOhTRND26cyybJF QkJE6i6EFPfbJSP8IPXIP3XsYFArGC8rXWLpyPD9vx67aD+Z5jLJitCRF17LVQfz/a 3OK7gwm7Afie6BZ5mCUU6Nn3FFHkCIzpJn0np7c8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367340185; i=@elandsys.com; bh=JQf+h4FVKCgvIXyDY4aZ9ZCBv8R+EnpjvY0Ug7OJs4A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=se8CpigRMaLET6+kjfmz7pxrQJeR/m1yM2nFDM1DOtLtOlrx5YR2rMiv+sESqRFJ+ zqICQcHhCO+iRxHjecBiWmkp8ePbi40uVqXnfjgM76Kq854TlagIzh25bL8r/Z6Zy8 CbfJbLBTA4+DCEKMj8atfq3QSJW3Zgmdvx/lIT8I= Message-Id: <6.2.5.6.2.20130430070019.0d6c3158@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 30 Apr 2013 09:14:03 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <6.2.5.6.2.20130429024006.0a9a7e18@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 30 Apr 2013 16:43:17 -0000 Hi Murray, At 16:21 29-04-2013, Murray S. Kucherawy wrote: >I suggest asking the ADs for guidance about the "must" vs. "MUST" >issue. I believe Pete may have already commented on it. However, I >also believe the "fix" is pretty easy, which avoids the issue >altogether, for cases where we used "must" in RFC4408 without >meaning "MUST" in the RFC2119 sense. My original review of >RFC4408bis focused on changing "must" (where it was meant >normatively) to "MUST", and to some other word otherwise. Pete Resnick commented about RFC 2119 [1]. I was looking for things which might pique his interest. :-) I am ok with not cleaning the "must". I think that the fix is easy. >Ditto. :-) I'll keep this one (RFC 2119 second paragraph of Section 2.1) listed as an issue :-) >Well, it has to resolve. SPF doesn't give you a definitive answer >where the FQDN can't be resolved. One could argue that the check >can't be performed when that happens. I think that's why "valid" is >used there. Is there a better way to say it? I'll pick up one of John Levine's messages [2]. "On the other hand, it is generally the case that competent software libraries do sanity checks on all of their input, so I don't see any compelling reason to call out this case. I don't see any warnings in the MAIL FROM section about how to deal with garbage like this: MAIL FROM:" I hope that it illustrates what is not called out in some specifications. Here's the text from the draft: 'This SPF check can only be performed when the "HELO" string is a valid fully qualified domain.' I get the "HELO" string. I have to perform sanity checks on it, or I am using a library it may do it for me. If I say "can only be performed on valid FQDN" I have to explain the details. If I say "look out, there can nasty stuff here as I encountered problems when I implemented this", it is useful guidance. I might have to say that for several other input if I take that approach and I end up with an EULA. :-) The other approach is to call out only issues which have been causing deployment problems. The second paragraph of Section 2.1 already says "be prepared for malformed or an IP address literal". That's usual guidance in my opinion. I would start the first paragraph with: The "HELO" identity is a fully-qualified domain name. >How is it not a definition? After spending much more than a day for this review I don't want to know. :-) >I do agree with having it in one place, however. Ok, I suggest doing that. > 'Generating non-delivery notifications to forged identities that have > failed the authorization check is a source of backscatter and SHOULD > be avoided.' > >This RFC 2119 SHOULD is not in RFC 4408. The above does not have >anything to do with Sender Policy Framework. It was mentioned >during WG discussions that "SPF can help the backscatter problem" >[2]. This text may have been introduced in response to a review >[3]. Is this an enhancement or a clarification? > > >I think it documents operational experience acquired since RFC4408 >was published. As for whether RFC2119 language is appropriate, I >agree that it isn't; it has nothing to do with SPF itself, though it >is a side effect of its use. I suggest changing SHOULD to "needs to". > > >My reading of the above is that it is neither an enhancement or a >clarification. I suggest removing the text. > >I think RFC4408 paints an incomplete picture of the decision-making >process when handling rejections other than at SMTP time, and thus >this qualifies as clarifying language. I understand your concern >here, but I suggest we push it up the chain under that argument. After reading of RFC 5321, I believe that that a rejection can only occur during the SMTP session. It was previously explained to me that the text documents operational experience. It was then explained to me that it qualifies as clarifying language. I can push it up the chain if I am provided with references to discussion about that text. > "If a published record contains multiple character-strings, then the > record MUST be treated as if those strings are concatenated together > without adding spaces." > >This RFC 2119 MUST is also in RFC 4408. I suggest removing the >"MUST" in the example. > >I disagree. It's required for interoperability. > > >Interoperability requirements are not specified through examples. > >It isn't, it's in the prose. The example is illustrative, not normative. Pete Resnick commented about RFC 2119. I suggest following his guidance. > 'Alternatively, for a server failure (RCODE 2) result, check_host() > MAY track failures and treat multiple failures within 24 hours for > the same domain as "permerror".' > >This text is not in RFC 4408. I found a note in Issue #1 [5] and in >a message [6]. > >Are there any implementations that do this? If so, that's the >justification; it's practical experience. If not, we should >consider dropping it. > > >I'll wait for feedback on this. > > >I think in retrospect that this runs into the clarifications >restriction, which this isn't. Though useful advice, the charter >may not allow it. I missed the DNS angle. Ted Lemon, as an individual, commented about it if I recall correctly. I suggest dropping the text. > 'MTAs or other processors SHOULD impose a limit on the maximum amount > of elapsed time to evaluate check_host(). Such a limit SHOULD allow > at least 20 seconds. If such a limit is exceeded, the result of > authorization SHOULD be "temperror".' > >There are three RFC 2119 SHOULDs in the above. I suggest rewriting >the text to reduce that. > >All three of them seem to be important interoperability points. We >could common factor the SHOULD and then present three bullets in a >list, but the meaning is the same. > > >Throughout the document the words "MTA", "other processors", "mail >receivers", "SPF implementations" and "SPF verifiers" are >used. That looks inconsistent to me. > >Here's an example of a rewrite: > > MTA or other processors SHOULD: > > (a) impose a limit on the maximum amount of elapsed time to > evaluate check_host(). > > (b) allow for at least 20 seconds. > > (c) return a result of authorization of "temperror". > >I don't see what Points (a) or (b) has to do with >interoperability. Trying to common factor the RFC 2119 SHOULD >reduces occurrences of the word instead of addressing the issue. I >suggest understanding the intent first before working on the text to be added. > > >Now that you say it that way, I have to agree. However, that text >appeared in RFC4408, so it's a matter of removing or reworking text >that was there before. Weren't we favouring no changes? I'll go with "no change". If I am asked, the explanation will be "the SPFBIS WG does not want to fix the text". > "In this case, a default of two is RECOMMENDED." > >Why is "two" recommended? > >Interoperability; if one is two while another is 10, different SPF >results can be returned. > > >Here is the text: > > "An implementation MAY choose to make such a limit configurable. In > > this case, a default of two is RECOMMENDED." > >There is the RFC 2119 SHOULD and the RFC 2119 RECOMMENDED. > >Here's how I look at it: Is the working group recommending a limit >which is configurable? What's the recommended value? Is the value >some arbitrary number? > > >I believe all of those questions have been answered; it's just a >matter of adding some prose to cover it. I'll wait for the working group to suggest text. >In Section 5.6: > > "ip6-network = " > >I suggest that the above reference be verified for correctness. > > >Looks right to me. The CIDR expression is in the optional token >next to it, so this has to be just a plain IPv6 address, so that's >the right reference. > > >I suggest reading RFC 5952. > > > Yes, that one's better. Alessandro Vesely commented about this [3]. I suggest that the working group reviews this issue as it's in the ABNF. >In Section 5.7: > > 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all' > >I'll flag this for review by DNS folks. > >What's the specific question being asked of DNSDIR here? > > >My question would be: "Is Section 5.7 of the draft correct?". > > >I'm not sure that's a good question for them as they'll have to try >to figure out our intent. I'm worried that they'll come back with a >"You shouldn't do it this way" and some encouragement to replace the >mechanism with something else. That would be a protocol change, and >that's out of scope. > >I suggest a more restricted question, like "Is this harmful?" That text is part of an example. In my opinion a protocol is not specified through an example. I prefer to avoid asking about what is harmful as it is difficult to make assess the views. As there is a thread that made it to ietf@ it may be too late to worry. >In Section 6: > > 'The modifiers defined in this document ("redirect" and "exp") MAY > appear anywhere in the record, but SHOULD appear at the end, after > all mechanisms.' > >This text is in RFC 4408. I would label the RFC 2119 usage as defective. > > >Why? > > >The text tells me that it is ok if the modifiers appear anywhere but >they should appear at the end after all mechanisms. It would be >clearer to say that it should appear after all mechanisms. > > >If you mean "get rid of the MAY" clause, I'm fine with that because >it doesn't add anything. An explanation of why would be helpful here too. Ok. > "This SHOULD be a fully qualified domain name, but if one does not > exist (as when the checking is done by a MUA) or if policy restrictions > dictate otherwise, the word "unknown" SHOULD be substituted." > >The RFC 2119 key words are in RFC 2119. I don't know what to say. > > >I think that looks fine as-is, though we could change the first >SHOULD to "ought to" because it's a transformation of other input >and not an implementation choice. (And I assume you mean they were >in RFC4408.) > > >Yes, I meant that there were in RFC 4408. I suggest that the >working group looks for a simple sentence to replace the existing one. > > >I think any reduction beyond what I suggested above loses information. Ok. > "When the result of macro expansion is used in a domain name query, if > the expanded domain name exceeds 253 characters (the maximum length > of a domain name), the left side is truncated to fit, by removing > successive domain labels (and their following dots) until the total > length does not exceed 253 characters." > >Where is it specified that the maximum length of a domain name is >253 characters? > > >RFC1035 says it's 255. > > >...which is to say I agree that I don't understand why it says 253 there. Hmm, there's is another angle to this. I'll skip that discussion. > In Section 10.1.2: > > "Publishing SPF records for domains that send no mail is > a well established best practice." > >I am not aware of that best practice. I did a few DNS queries: > >;; QUESTION SECTION: >;bing.com. IN TXT > >;; ANSWER SECTION: >bing.com. 3600 IN TXT "v=msv1 >t=6097A7EA-53F7-4028-BA76-6869CB284C54" > >;; QUESTION SECTION: >;com.com. IN TXT > >;; ANSWER SECTION: >com.com. 293 IN TXT >"google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k" > > >What are you saying here? This is an existence proof of non-mailing >domains that don't publish SPF records, but it doesn't contradict >the statement made in the draft. > > >The claim is being made without any supporting material. > > >But it's a true claim, and applicability statements and technical >specifications describe best practices all the time. What evidence >could we include to support it? It's not that I do not believe you. A few references might be helpful to support a claim. >...or precedent. :-) :-) >In Appendix C: > >In Section E.1: > > 'This would cause a lookup on an DNS white list (DNSWL) and cause a > result of "fail" only for email not either coming from the > domain's mx host(s) (SPF pass) or white listed sources (SPF > neutral).' > >I didn't find any discussion about this on the SPFBIS mailing >list. is there an explanation for this change between RFC 4408 and this draft? > > >It was in 9.3 in the previous document and has been reworded a >little. It's otherwise unchanged. > > >The text from Section 9.3 is already in the draft. This is >additional material instead of a little rewording. There was a >concern about "a tendency to include an example of every possible >use of SPF to solve some problem". I suggest removing the example. > > >But this just a relocation of text already in 4408. I don't think >removing it is justified even if it's part of the (original) clutter. I read Section 9.3 of RFC 4408 again before writing this message. I did not find the text. I suggest removing the text from the draft. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg03646.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg03639.html From vesely@tana.it Tue Apr 30 10:16: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 6432D21F9C41 for ; Tue, 30 Apr 2013 10:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.755 X-Spam-Level: X-Spam-Status: No, score=-4.755 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6t9OzTHwMUL for ; Tue, 30 Apr 2013 10:16:13 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C8BB121F9C02 for ; Tue, 30 Apr 2013 10:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367342167; bh=pL9NlgPfVCoRKAhzabJhmbHM1F8/p4s8TaCojPQYyv0=; l=1410; h=Date:From:To:References:In-Reply-To; b=H5YIyyAWRMkbbN97bM83PvHcHfkZmxBN5UMXjGaH1+IrWtKYa0Z8GgThOr3sKutep icap5KoFEBQZEfNu4Plht1q4UymcEqm/XsXe+KXlxJuYzZgjMRqIFM94dYwZD0r+fk S3+/YMCT8ctFLrvNRtDKaGeIu9WaE8gQE1S0D7/w= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Tue, 30 Apr 2013 19:16:07 +0200 id 00000000005DC039.00000000517FFC57.00001BE8 Message-ID: <517FFC57.40307@tana.it> Date: Tue, 30 Apr 2013 19:16:07 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130425013317.36729.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B630775160B14@mbx-01.win.nominum.com> <3278520.In0W6NM3sD@scott-latitude-e6320> <20130426191306.GB809@mx1.yitter.info> In-Reply-To: <20130426191306.GB809@mx1.yitter.info> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 17:16:17 -0000 On Fri 26/Apr/2013 21:13:07 +0200 Andrew Sullivan wrote: > No hat. > > On Fri, Apr 26, 2013 at 02:59:50PM -0400, Scott Kitterman wrote: >> but use of TXT in the name namespace of the domain. To the extent this may >> actually be a problem, it's trivially mitigated: >> >> example.com. 3600 IN TXT "v=spf1 redirect=_spf.example.com" >> _spf.example.com. 3600 IN TXT "v=spf1 [record content] -all" > > That only partly mitigates it. You _still_ need the TXT record at > example.com. By mandating a fixed prefix we'd have invaded a namespace. > That's one of the things those of us who find this an incredibly > ugly wart object to: it uses one datatype for other data. More > precisely, it uses a by-definition-unstructured datatype for > structured data. It's unquestionably datatype abuse. I can still write "v=spf1 ip6=foo". I'll get permerror but it is possible, while I cannot write foo in an AAAA record. There's a difference between "possibly structured" but still (potentially) unstructured and actually structured. On the other hand, I don't think TXT was devised to publish Shakesperean sonnets or other poetic epigrams. If it's supposed to be machine readable text, it has to obey some lower level kind of syntax, which can be called structured. > I think the only question is whether the ship has left the barn; > the answer is yes. And that's the real point. From superuser@gmail.com Tue Apr 30 10:58: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 0034321F9C09 for ; Tue, 30 Apr 2013 10:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep928wJt0PHf for ; Tue, 30 Apr 2013 10:58:00 -0700 (PDT) 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 7F88821F9961 for ; Tue, 30 Apr 2013 10:57:06 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id e11so3263827wgh.2 for ; Tue, 30 Apr 2013 10:57:05 -0700 (PDT) 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=pKjt5snzO9MZDtX6mh5KwVkLTYnWNfrFLKLrNwv1ywY=; b=aMUnuR8IR5u58KYE/w4Lau5rwyqfrNYs/iWMHJCZRfyw5aQLMQbZ2iM41ZnwHl6V6R GbcdnVRTjWBdMKUmNU5M8xb1WlBMi/dgj70v9fOy8lYExI4ywmpQly5F45PaDPoUC1Sc VODV7e05LuPVlGAL973/Ojux12l7bLpDgMEAzd24/kH0XyM3RV8ruLXK4oO95FDq66tw abXdu4vCNStT+GjlPRMcYhjCW615+PylbT0kUClJpPnnmV8gcFxXaR8HvtIb9udVS5cW 1Eu0/bWDFUfY2apOhTt7u9sgg9EY2WcJTUZVlExJhA+YtjI5xPkggwA20SIIteyV0E5e cTdw== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr19516230wjb.17.1367344625452; Tue, 30 Apr 2013 10:57:05 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 30 Apr 2013 10:57:05 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130430070019.0d6c3158@elandnews.com> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <6.2.5.6.2.20130429024006.0a9a7e18@elandnews.com> <6.2.5.6.2.20130430070019.0d6c3158@elandnews.com> Date: Tue, 30 Apr 2013 10:57:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7b5d8cffaf8a6204db97ba64 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 30 Apr 2013 17:58:02 -0000 --047d7b5d8cffaf8a6204db97ba64 Content-Type: text/plain; charset=ISO-8859-1 How are we tracking the issues that have resolved in the direction of adjustments to the document before requesting publication? It seems like there's a large number of small changes that need to be either adopted or discussed further. I'm sure I've lost track of some (maybe most) of them; we should do what we can to help Scott here. -MSK On Tue, Apr 30, 2013 at 9:14 AM, S Moonesamy wrote: > Hi Murray, > > At 16:21 29-04-2013, Murray S. Kucherawy wrote: > >> I suggest asking the ADs for guidance about the "must" vs. "MUST" issue. >> I believe Pete may have already commented on it. However, I also believe >> the "fix" is pretty easy, which avoids the issue altogether, for cases >> where we used "must" in RFC4408 without meaning "MUST" in the RFC2119 >> sense. My original review of RFC4408bis focused on changing "must" (where >> it was meant normatively) to "MUST", and to some other word otherwise. >> > > Pete Resnick commented about RFC 2119 [1]. I was looking for things which > might pique his interest. :-) > > I am ok with not cleaning the "must". I think that the fix is easy. > > Ditto. :-) >> > > I'll keep this one (RFC 2119 second paragraph of Section 2.1) listed as an > issue :-) > > > Well, it has to resolve. SPF doesn't give you a definitive answer where >> the FQDN can't be resolved. One could argue that the check can't be >> performed when that happens. I think that's why "valid" is used there. Is >> there a better way to say it? >> > > I'll pick up one of John Levine's messages [2]. > > > "On the other hand, it is generally the case that competent software > libraries do sanity checks on all of their input, so I don't see any > compelling reason to call out this case. I don't see any warnings in > the MAIL FROM section about how to deal with garbage like this: > > MAIL FROM:" > > I hope that it illustrates what is not called out in some specifications. > > Here's the text from the draft: > > 'This SPF check can only be performed when the "HELO" string is > a valid fully qualified domain.' > > I get the "HELO" string. I have to perform sanity checks on it, or I am > using a library it may do it for me. If I say "can only be performed on > valid FQDN" I have to explain the details. If I say "look out, there can > nasty stuff here as I encountered problems when I implemented this", it is > useful guidance. I might have to say that for several other input if I > take that approach and I end up with an EULA. :-) The other approach is to > call out only issues which have been causing deployment problems. > > The second paragraph of Section 2.1 already says "be prepared for > malformed or an IP address literal". That's usual guidance in my opinion. > > I would start the first paragraph with: > > The "HELO" identity is a fully-qualified domain name. > > > How is it not a definition? >> > > After spending much more than a day for this review I don't want to know. > :-) > > > I do agree with having it in one place, however. >> > > Ok, I suggest doing that. > > > 'Generating non-delivery notifications to forged identities that have >> failed the authorization check is a source of backscatter and SHOULD >> be avoided.' >> >> This RFC 2119 SHOULD is not in RFC 4408. The above does not have >> anything to do with Sender Policy Framework. It was mentioned during WG >> discussions that "SPF can help the backscatter problem" [2]. This text may >> have been introduced in response to a review [3]. Is this an enhancement >> or a clarification? >> >> >> I think it documents operational experience acquired since RFC4408 was >> published. As for whether RFC2119 language is appropriate, I agree that it >> isn't; it has nothing to do with SPF itself, though it is a side effect of >> its use. I suggest changing SHOULD to "needs to". >> >> >> My reading of the above is that it is neither an enhancement or a >> clarification. I suggest removing the text. >> >> I think RFC4408 paints an incomplete picture of the decision-making >> process when handling rejections other than at SMTP time, and thus this >> qualifies as clarifying language. I understand your concern here, but I >> suggest we push it up the chain under that argument. >> > > After reading of RFC 5321, I believe that that a rejection can only occur > during the SMTP session. It was previously explained to me that the text > documents operational experience. It was then explained to me that it > qualifies as clarifying language. I can push it up the chain if I am > provided with references to discussion about that text. > > > > "If a published record contains multiple character-strings, then the >> record MUST be treated as if those strings are concatenated together >> without adding spaces." >> >> This RFC 2119 MUST is also in RFC 4408. I suggest removing the "MUST" in >> the example. >> >> I disagree. It's required for interoperability. >> >> >> Interoperability requirements are not specified through examples. >> >> It isn't, it's in the prose. The example is illustrative, not normative. >> > > Pete Resnick commented about RFC 2119. I suggest following his guidance. > > > 'Alternatively, for a server failure (RCODE 2) result, check_host() >> MAY track failures and treat multiple failures within 24 hours for >> the same domain as "permerror".' >> >> This text is not in RFC 4408. I found a note in Issue #1 [5] and in a >> message [6]. >> >> Are there any implementations that do this? If so, that's the >> justification; it's practical experience. If not, we should consider >> dropping it. >> >> >> I'll wait for feedback on this. >> >> >> I think in retrospect that this runs into the clarifications restriction, >> which this isn't. Though useful advice, the charter may not allow it. >> > > I missed the DNS angle. Ted Lemon, as an individual, commented about it > if I recall correctly. I suggest dropping the text. > > > 'MTAs or other processors SHOULD impose a limit on the maximum amount >> of elapsed time to evaluate check_host(). Such a limit SHOULD allow >> at least 20 seconds. If such a limit is exceeded, the result of >> authorization SHOULD be "temperror".' >> >> There are three RFC 2119 SHOULDs in the above. I suggest rewriting the >> text to reduce that. >> >> All three of them seem to be important interoperability points. We could >> common factor the SHOULD and then present three bullets in a list, but the >> meaning is the same. >> >> >> Throughout the document the words "MTA", "other processors", "mail >> receivers", "SPF implementations" and "SPF verifiers" are used. That looks >> inconsistent to me. >> >> Here's an example of a rewrite: >> >> MTA or other processors SHOULD: >> >> (a) impose a limit on the maximum amount of elapsed time to evaluate >> check_host(). >> >> (b) allow for at least 20 seconds. >> >> (c) return a result of authorization of "temperror". >> >> I don't see what Points (a) or (b) has to do with interoperability. >> Trying to common factor the RFC 2119 SHOULD reduces occurrences of the >> word instead of addressing the issue. I suggest understanding the intent >> first before working on the text to be added. >> >> >> Now that you say it that way, I have to agree. However, that text >> appeared in RFC4408, so it's a matter of removing or reworking text that >> was there before. Weren't we favouring no changes? >> > > I'll go with "no change". If I am asked, the explanation will be "the > SPFBIS WG does not want to fix the text". > > > "In this case, a default of two is RECOMMENDED." >> >> Why is "two" recommended? >> >> Interoperability; if one is two while another is 10, different SPF >> results can be returned. >> >> >> Here is the text: >> >> "An implementation MAY choose to make such a limit configurable. In >> >> this case, a default of two is RECOMMENDED." >> >> There is the RFC 2119 SHOULD and the RFC 2119 RECOMMENDED. >> >> Here's how I look at it: Is the working group recommending a limit which >> is configurable? What's the recommended value? Is the value some >> arbitrary number? >> >> >> I believe all of those questions have been answered; it's just a matter >> of adding some prose to cover it. >> > > I'll wait for the working group to suggest text. > > > > In Section 5.6: >> >> "ip6-network = " >> >> I suggest that the above reference be verified for correctness. >> >> >> Looks right to me. The CIDR expression is in the optional token next to >> it, so this has to be just a plain IPv6 address, so that's the right >> reference. >> >> >> I suggest reading RFC 5952. >> >> >> Yes, that one's better. >> > > Alessandro Vesely commented about this [3]. I suggest that the working > group reviews this issue as it's in the ABNF. > > > In Section 5.7: >> >> 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{**d} -all' >> >> I'll flag this for review by DNS folks. >> >> What's the specific question being asked of DNSDIR here? >> >> >> My question would be: "Is Section 5.7 of the draft correct?". >> >> >> I'm not sure that's a good question for them as they'll have to try to >> figure out our intent. I'm worried that they'll come back with a "You >> shouldn't do it this way" and some encouragement to replace the mechanism >> with something else. That would be a protocol change, and that's out of >> scope. >> >> I suggest a more restricted question, like "Is this harmful?" >> > > That text is part of an example. In my opinion a protocol is not > specified through an example. I prefer to avoid asking about what is > harmful as it is difficult to make assess the views. As there is a thread > that made it to ietf@ it may be too late to worry. > > > In Section 6: >> >> 'The modifiers defined in this document ("redirect" and "exp") MAY >> appear anywhere in the record, but SHOULD appear at the end, after >> all mechanisms.' >> >> This text is in RFC 4408. I would label the RFC 2119 usage as defective. >> >> >> Why? >> >> >> The text tells me that it is ok if the modifiers appear anywhere but they >> should appear at the end after all mechanisms. It would be clearer to say >> that it should appear after all mechanisms. >> >> >> If you mean "get rid of the MAY" clause, I'm fine with that because it >> doesn't add anything. An explanation of why would be helpful here too. >> > > Ok. > > > "This SHOULD be a fully qualified domain name, but if one does not >> exist (as when the checking is done by a MUA) or if policy restrictions >> dictate otherwise, the word "unknown" SHOULD be substituted." >> >> The RFC 2119 key words are in RFC 2119. I don't know what to say. >> >> >> I think that looks fine as-is, though we could change the first SHOULD to >> "ought to" because it's a transformation of other input and not an >> implementation choice. (And I assume you mean they were in RFC4408.) >> >> >> Yes, I meant that there were in RFC 4408. I suggest that the working >> group looks for a simple sentence to replace the existing one. >> >> >> I think any reduction beyond what I suggested above loses information. >> > > Ok. > > > "When the result of macro expansion is used in a domain name query, if >> the expanded domain name exceeds 253 characters (the maximum length >> of a domain name), the left side is truncated to fit, by removing >> successive domain labels (and their following dots) until the total >> length does not exceed 253 characters." >> >> Where is it specified that the maximum length of a domain name is 253 >> characters? >> >> >> RFC1035 says it's 255. >> >> >> ...which is to say I agree that I don't understand why it says 253 there. >> > > Hmm, there's is another angle to this. I'll skip that discussion. > > > In Section 10.1.2: >> >> "Publishing SPF records for domains that send no mail is >> a well established best practice." >> >> I am not aware of that best practice. I did a few DNS queries: >> >> ;; QUESTION SECTION: >> ;bing.com. IN TXT >> >> ;; ANSWER SECTION: >> bing.com. 3600 IN TXT "v=msv1 >> t=6097A7EA-53F7-4028-BA76-**6869CB284C54" >> >> ;; QUESTION SECTION: >> ;com.com. IN TXT >> >> ;; ANSWER SECTION: >> com.com. 293 IN TXT "google-site-verification:** >> esSnoZdChIkkfCfS9MMgqNhE0yaXfn**nZWdZPuBf7e8k" >> >> >> What are you saying here? This is an existence proof of non-mailing >> domains that don't publish SPF records, but it doesn't contradict the >> statement made in the draft. >> >> >> The claim is being made without any supporting material. >> >> >> But it's a true claim, and applicability statements and technical >> specifications describe best practices all the time. What evidence could >> we include to support it? >> > > It's not that I do not believe you. A few references might be helpful to > support a claim. > > ...or precedent. :-) >> > > :-) > > In Appendix C: >> >> In Section E.1: >> >> 'This would cause a lookup on an DNS white list (DNSWL) and cause a >> result of "fail" only for email not either coming from the >> domain's mx host(s) (SPF pass) or white listed sources (SPF >> neutral).' >> >> I didn't find any discussion about this on the SPFBIS mailing list. is >> there an explanation for this change between RFC 4408 and this draft? >> >> >> It was in 9.3 in the previous document and has been reworded a little. >> It's otherwise unchanged. >> >> >> The text from Section 9.3 is already in the draft. This is additional >> material instead of a little rewording. There was a concern about "a >> tendency to include an example of every possible use of SPF to solve some >> problem". I suggest removing the example. >> >> >> But this just a relocation of text already in 4408. I don't think >> removing it is justified even if it's part of the (original) clutter. >> > > I read Section 9.3 of RFC 4408 again before writing this message. I did > not find the text. I suggest removing the text from the draft. > > > Regards, > S. Moonesamy (as document shepherd) > > 1. http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03642.html > 2. http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03646.html > 3. http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03639.html > --047d7b5d8cffaf8a6204db97ba64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
How are we tracking the issues that have resolved in the d= irection of adjustments to the document before requesting publication?=A0 I= t seems like there's a large number of small changes that need to be ei= ther adopted or discussed further.=A0 I'm sure I've lost track of s= ome (maybe most) of them; we should do what we can to help Scott here.

-MSK


On Tue, Apr 30, 2013 at 9:14 AM, S Moonesamy <sm+ietf@elandsys.com= > wrote:
Hi Murray,

At 16:21 29-04-2013, Murray S. Kucherawy wrote:
I suggest asking the ADs for guidance about the "must" vs. "= MUST" issue. =A0I believe Pete may have already commented on it. =A0Ho= wever, I also believe the "fix" is pretty easy, which avoids the = issue altogether, for cases where we used "must" in RFC4408 witho= ut meaning "MUST" in the RFC2119 sense. =A0My original review of = RFC4408bis focused on changing "must" (where it was meant normati= vely) to "MUST", and to some other word otherwise.

Pete Resnick commented about RFC 2119 [1]. =A0I was looking for things whic= h might pique his interest. :-)

I am ok with not cleaning the "must". =A0I think that the fix is = easy.

Ditto. =A0:-)

I'll keep this one (RFC 2119 second paragraph of Section 2.1) listed as= an issue :-)


Well, it has to resolve. =A0SPF doesn't give you a definitive answer wh= ere the FQDN can't be resolved. =A0One could argue that the check can&#= 39;t be performed when that happens. =A0I think that's why "valid&= quot; is used there. =A0Is there a better way to say it?

I'll pick up one of John Levine's messages [2].

=A0"On the other hand, it is generally the case that competent softwar= e
=A0 libraries do sanity checks on all of their input, so I don't see an= y
=A0 compelling reason to call out this case. =A0I don't see any warning= s in
=A0 the MAIL FROM section about how to deal with garbage like this:

=A0 =A0 MAIL FROM:<foo at !#MCU&$..!?x?x>"

I hope that it illustrates what is not called out in some specifications.
Here's the text from the draft:

=A0 'This SPF check can only be performed when the "HELO" str= ing is
=A0 =A0a valid fully qualified domain.'

I get the "HELO" string. =A0I have to perform sanity checks on it= , or I am using a library it may do it for me. =A0If I say "can only b= e performed on valid FQDN" =A0I have to explain the details. =A0If I s= ay "look out, there can nasty stuff here as I encountered problems whe= n I implemented this", it is useful guidance. =A0I might have to say t= hat for several other input if I take that approach and I end up with an EU= LA. :-) =A0The other approach is to call out only issues which have been ca= using deployment problems.

The second paragraph of Section 2.1 already says "be prepared for malf= ormed or an IP address literal". =A0That's usual guidance in my op= inion.

I would start the first paragraph with:

=A0 The "HELO" identity is a fully-qualified domain name.


How is it not a definition?

After spending much more than a day for this review I don't want to kno= w. :-)


I do agree with having it in one place, however.

Ok, I suggest doing that.


=A0 'Generating non-delivery notifications to forged identities that ha= ve
=A0 =A0failed the authorization check is a source of backscatter and SHOULD=
=A0 =A0be avoided.'

This RFC 2119 SHOULD is not in RFC 4408. =A0The above does not have anythin= g to do with Sender Policy Framework. =A0It was mentioned during WG discuss= ions that "SPF can help the backscatter problem" [2]. =A0This tex= t may have been introduced in response to a review [3]. =A0Is this an enhan= cement or a clarification?


I think it documents operational experience acquired since RFC4408 was publ= ished. =A0As for whether RFC2119 language is appropriate, I agree that it i= sn't; it has nothing to do with SPF itself, though it is a side effect = of its use. =A0I suggest changing SHOULD to "needs to".


My reading of the above is that it is neither an enhancement or a clarifica= tion. =A0I suggest removing the text.

I think RFC4408 paints an incomplete picture of the decision-making process= when handling rejections other than at SMTP time, and thus this qualifies = as clarifying language. =A0I understand your concern here, but I suggest we= push it up the chain under that argument.

After reading of RFC 5321, I believe that that a rejection can only occur d= uring the SMTP session. =A0It was previously explained to me that the text = documents operational experience. =A0It was then explained to me that it qu= alifies as clarifying language. =A0I can push it up the chain if I am provi= ded with references to discussion about that text.



=A0 "If a published record contains multiple character-strings, then t= he
=A0 =A0record MUST be treated as if those strings are concatenated together=
=A0 =A0without adding spaces."

This RFC 2119 MUST is also in RFC 4408. =A0I suggest removing the "MUS= T" in the example.

I disagree. =A0It's required for interoperability.


Interoperability requirements are not specified through examples.

It isn't, it's in the prose. =A0The example is illustrative, not no= rmative.

Pete Resnick commented about RFC 2119. =A0I suggest following his guidance.=


=A0 'Alternatively, for a server failure (RCODE 2) result, check_host()=
=A0 =A0MAY track failures and treat multiple failures within 24 hours for =A0 =A0the same domain as "permerror".'

This text is not in RFC 4408. =A0I found a note in Issue #1 [5] and in a me= ssage [6].

Are there any implementations that do this? =A0If so, that's the justif= ication; it's practical experience. =A0If not, we should consider dropp= ing it.


I'll wait for feedback on this.


I think in retrospect that this runs into the clarifications restriction, w= hich this isn't. =A0Though useful advice, the charter may not allow it.=

I missed the DNS angle. =A0Ted Lemon, as an individual, commented about it = if I recall correctly. =A0I suggest dropping the text.

=A0 =A0'MTAs or other processors SHOULD impose a limit on the maximum a= mount
=A0 =A0of elapsed time to evaluate check_host(). =A0Such a limit SHOULD all= ow
=A0 =A0at least 20 seconds. =A0If such a limit is exceeded, the result of =A0 =A0authorization SHOULD be "temperror".'

There are three RFC 2119 SHOULDs in the above. =A0I suggest rewriting the t= ext to reduce that.

All three of them seem to be important interoperability points. =A0We could= common factor the SHOULD and then present three bullets in a list, but the= meaning is the same.


Throughout the document the words "MTA", "other processors&q= uot;, "mail receivers", "SPF implementations" and "= ;SPF verifiers" are used. =A0That looks inconsistent to me.

Here's an example of a rewrite:

=A0 MTA or other processors SHOULD:

=A0 (a) impose a limit on the maximum amount of elapsed time to evaluate ch= eck_host().

=A0 (b) allow for at least 20 seconds.

=A0 (c) return a result of authorization of "temperror".

I don't see what Points (a) or (b) has to do with interoperability. =A0= Trying to common factor the RFC 2119 SHOULD reduces occurrences of the word= instead of addressing the issue. =A0I suggest understanding the intent fir= st before working on the text to be added.


Now that you say it that way, I have to agree. =A0However, that text appear= ed in RFC4408, so it's a matter of removing or reworking text that was = there before. =A0Weren't we favouring no changes?

I'll go with "no change". =A0If I am asked, the explanation w= ill be "the SPFBIS WG does not want to fix the text".


=A0 "In this case, a default of two is RECOMMENDED."

Why is "two" recommended?

Interoperability; if one is two while another is 10, different SPF results = can be returned.


Here is the text:

=A0 "An implementation MAY choose to make such a limit configurable. = =A0In

=A0 =A0this case, a default of two is RECOMMENDED."

There is the RFC 2119 SHOULD and the RFC 2119 RECOMMENDED.

Here's how I look at it: Is the working group recommending a limit whic= h is configurable? =A0What's the recommended value? =A0Is the value som= e arbitrary number?


I believe all of those questions have been answered; it's just a matter= of adding some prose to cover it.

I'll wait for the working group to suggest text.



In Section 5.6:

=A0 "ip6-network =A0 =A0 =A0=3D <as per [RFC 4291], section 2.2>= "

I suggest that the above reference be verified for correctness.


Looks right to me. =A0The CIDR expression is in the optional token next to = it, so this has to be just a plain IPv6 address, so that's the right re= ference.


I suggest reading RFC 5952.


=A0Yes, that one's better.

Alessandro Vesely commented about this [3]. =A0I suggest that the working g= roup reviews this issue as it's in the ABNF.


In Section 5.7:

=A0 'v=3Dspf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all'

I'll flag this for review by DNS folks.

What's the specific question being asked of DNSDIR here?


My question would be: "Is Section 5.7 of the draft correct?".


I'm not sure that's a good question for them as they'll have to= try to figure out our intent. =A0I'm worried that they'll come bac= k with a "You shouldn't do it this way" and some encouragemen= t to replace the mechanism with something else. =A0That would be a protocol= change, and that's out of scope.

I suggest a more restricted question, like "Is this harmful?"

That text is part of an example. =A0In my opinion a protocol is not specifi= ed through an example. =A0I prefer to avoid asking about what is harmful as= it is difficult to make assess the views. =A0As there is a thread that mad= e it to ietf@ it may be too late to worry.


In Section 6:

=A0 'The modifiers defined in this document ("redirect" and &= quot;exp") MAY
=A0 =A0appear anywhere in the record, but SHOULD appear at the end, after =A0 =A0all mechanisms.'

This text is in RFC 4408. =A0I would label the RFC 2119 usage as defective.=


Why?


The text tells me that it is ok if the modifiers appear anywhere but they s= hould appear at the end after all mechanisms. =A0It would be clearer to say= that it should appear after all mechanisms.


If you mean "get rid of the MAY" clause, I'm fine with that b= ecause it doesn't add anything. =A0An explanation of why would be helpf= ul here too.

Ok.


=A0 =A0"This SHOULD be a fully qualified domain name, but if one does = not
=A0 =A0exist (as when the checking is done by a MUA) or if policy restricti= ons
=A0 =A0dictate otherwise, the word "unknown" SHOULD be substitute= d."

The RFC 2119 key words are in RFC 2119. =A0I don't know what to say.

I think that looks fine as-is, though we could change the first SHOULD to &= quot;ought to" because it's a transformation of other input and no= t an implementation choice. =A0(And I assume you mean they were in RFC4408.= )


Yes, I meant that there were in RFC 4408. =A0I suggest that the working gro= up looks for a simple sentence to replace the existing one.


I think any reduction beyond what I suggested above loses information.

Ok.


=A0 "When the result of macro expansion is used in a domain name query= , if
=A0 =A0the expanded domain name exceeds 253 characters (the maximum length<= br> =A0 =A0of a domain name), the left side is truncated to fit, by removing =A0 =A0successive domain labels (and their following dots) until the total<= br> =A0 =A0length does not exceed 253 characters."

Where is it specified that the maximum length of a domain name is 253 chara= cters?


RFC1035 says it's 255.


...which is to say I agree that I don't understand why it says 253 ther= e.

Hmm, there's is another angle to this. =A0I'll skip that discussion= .


=A0In Section 10.1.2:

=A0 "Publishing SPF records for domains that send no mail is
=A0 =A0a well established best practice."

I am not aware of that best practice. =A0I did a few DNS queries:

;; QUESTION SECTION:
;bing.com. =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IN =A0 =A0 =A0TXT

;; ANSWER SECTION:
bing.com. =A0 =A0 =A0 =A0= =A0 =A0 =A0 3600 =A0 =A0IN =A0 =A0 =A0TXT =A0 =A0 "v=3Dmsv1 t=3D6097A= 7EA-53F7-4028-BA76-6869CB284C54"

;; QUESTION SECTION:
;com.com. =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 IN =A0 =A0 =A0TXT

;; ANSWER SECTION:
com.com. =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0293 =A0 =A0 IN =A0 =A0 =A0TXT "google-site-verification= :esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k"


What are you saying here? =A0This is an existence proof of non-mailing doma= ins that don't publish SPF records, but it doesn't contradict the s= tatement made in the draft.


The claim is being made without any supporting material.


But it's a true claim, and applicability statements and technical speci= fications describe best practices all the time. =A0What evidence could we i= nclude to support it?

It's not that I do not believe you. =A0A few references might be helpfu= l to support a claim.

...or precedent. =A0:-)

:-)

In Appendix C:

In Section E.1:

=A0 'This would cause a lookup on an DNS white list (DNSWL) and cause a=
=A0 =A0result of "fail" only for email not either coming from the=
=A0 =A0domain's mx host(s) (SPF pass) or white listed sources (SPF
=A0 =A0neutral).'

I didn't find any discussion about this on the SPFBIS mailing list. =A0= is there an explanation for this change between RFC 4408 and this draft?

It was in 9.3 in the previous document and has been reworded a little. =A0I= t's otherwise unchanged.


The text from Section 9.3 is already in the draft. =A0This is additional ma= terial instead of a little rewording. =A0There was a concern about "a = tendency to include an example of every possible use of SPF to solve some p= roblem". =A0I suggest removing the example.


But this just a relocation of text already in 4408. =A0I don't think re= moving it is justified even if it's part of the (original) clutter.

I read Section 9.3 of RFC 4408 again before writing this message. =A0I did = not find the text. =A0I suggest removing the text from the draft.


Regards,
S. Moonesamy (as document shepherd)

1. http://www.ietf.org/mail-archive/web/spfbis/= current/msg03642.html
2. http://www.ietf.org/mail-archive/web/spfbis/= current/msg03646.html
3. http://www.ietf.org/mail-archive/web/spfbis/= current/msg03639.html

--047d7b5d8cffaf8a6204db97ba64-- From sm@elandsys.com Tue Apr 30 11:25: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 3D13A21F9C70 for ; Tue, 30 Apr 2013 11:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwv5x4eAgujw for ; Tue, 30 Apr 2013 11:24:59 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF11E21F9C2F for ; Tue, 30 Apr 2013 11:24:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3UIOUNV017698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Apr 2013 11:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367346289; bh=0mToh4eA9Y7n7MenezxDhPDji5kf6Aeo1CSnwn6iuIA=; h=Date:To:From:Subject; b=BcLg70ZeiX1aidBP3hz5h6qfOnqLL0OkekEMHfF5m1fN5jDxNS4cwzSB8tGvH/s17 mVZ2knqmxYLibIrWMWUI6eTCMvmnwKvdUXjv++lgAWlWehwQPNpLft/ik9sgf1R658 QyzBhOXvq0cIIC+TKO3J+X0P8njRDCAah2jDmr28= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367346289; i=@elandsys.com; bh=0mToh4eA9Y7n7MenezxDhPDji5kf6Aeo1CSnwn6iuIA=; h=Date:To:From:Subject; b=sP1vdRP9gCedImGLCc0epWTOhkBZaznmhM0Cf1k5BYxk1qfYne+KmSLCWE2f9xu6V NXOa0F3itFHeLaTJqhMpJu4tkL0qbNUqTdeFqA1rloddOY8sfRPrsvmzlAWAASaJbE Rgdob4IGtcZEh1lW5YvgzAFV7W66nwUl787KpWcc= Message-Id: <6.2.5.6.2.20130430112315.0a7ee3e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 30 Apr 2013 11:24:00 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Fwd: draft-ietf-spfbis-4408bis-14 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, 30 Apr 2013 18:25:00 -0000 >Date: Fri, 26 Apr 2013 12:58:48 -0400 >From: Phillip Hallam-Baker >To: "iesg@ietf.org" , > draft-ietf-spfbis-4408bis.all@tools.ietf.org, > "secdir@ietf.org" >Subject: draft-ietf-spfbis-4408bis-14 > > >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > > >The document is clear and describes the SPF mechanism effectively. >The only quibble that I could find is that repeated mentions are >made of limiting the number of 'DNS queries' without specifying >whether these are individual queries or recursive. The count will >come out rather differently if looking up >TXT/x.example.com counts as one lookup or >three. I think it is reasonably clear that this is one but could not >find an explicit statement to that effect. > >On the security side, the document addresses all the mail issues >that I can remember at this point and rather more besides. > >I think we have reached the point of diminishing returns. > >The document provides a clear enough warning to people configuring >SPF records as to the consequences of getting it wrong which is the >main concern. The filtering services will know their business well >enough to minimize false positives. > >Hopefully the email infrastructure will evolve over time towards >concentrating on the more policy friendly approaches and it will be >possible to simplify the mechanism at a future date. > > >-- >Website: http://hallambaker.com/ From dhc@dcrocker.net Tue Apr 30 11:52: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 19C8D21F9B5E for ; Tue, 30 Apr 2013 11:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUdhcQky0kk3 for ; Tue, 30 Apr 2013 11:52:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 689D821F9A86 for ; Tue, 30 Apr 2013 11:52:41 -0700 (PDT) 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 r3UIqaqk001361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Apr 2013 11:52:40 -0700 Message-ID: <518012EE.8060904@dcrocker.net> Date: Tue, 30 Apr 2013 11:52:30 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "spfbis@ietf.org" Content-Type: multipart/mixed; boundary="------------030103020509010104020000" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 30 Apr 2013 11:52:41 -0700 (PDT) Subject: [spfbis] SPF in concert 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: Tue, 30 Apr 2013 18:52:50 -0000 This is a multi-part message in MIME format. --------------030103020509010104020000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Just came across this, from my trip archives... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------030103020509010104020000 Content-Type: image/jpeg; name="SPF.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="SPF.jpg" /9j/4R+URXhpZgAASUkqAAgAAAAKAA8BAgAIAAAAhgAAABABAgAJAAAAjgAAABIBAwABAAAA AQAAABoBBQABAAAAlwAAABsBBQABAAAAnwAAACgBAwABAAAAAgAAADEBAgAKAAAApwAAADIB AgAUAAAAsQAAABMCAwABAAAAAQAAAGmHBAABAAAAxQAAAKMCAABTQU1TVU5HAFNHSC1UNzY5 AEgAAAABAAAASAAAAAEAAABBQ0RTZWUgMTUAMjAxMzowNDozMCAxMTo0OTo1MwAYAJqCBQAB AAAA6wEAAJ2CBQABAAAA8wEAACKIAwABAAAAAwAAACeIAwABAAAAyAAAAACQBwAEAAAAMDIy MAOQAgAUAAAA+wEAAASQAgAUAAAADwIAAAGRBwAEAAAAAQIDAAKSBQABAAAAIwIAAASSCgAB AAAAKwIAAAWSBQABAAAAMwIAAAeSAwABAAAAAgAAAAmSAwABAAAAAAAAAAqSBQABAAAAOwIA AHySBwBCAAAAQwIAAJCSAgAEAAAAMjI3AACgBwAEAAAAMDEwMAGgAwABAAAAAQAAAAKgBAAB AAAAuAEAAAOgBAABAAAAewIAAAWgBAABAAAAhQIAAAKkAwABAAAAAAAAAAOkAwABAAAAAAAA AAakAwABAAAAAAAAAAAAAAABAAAACAAAAAQBAABkAAAAMjAxMjowODowMiAyMjo0NDo0MwAy MDEyOjA4OjAyIDIyOjQ0OjQzACwBAABkAAAAAAAAAGQAAAAUAQAAZAAAANoNAADoAwAABQAB AAcABAAAADAxMDACAAQAAQAAAAAgAQBAAAQAAQAAAAAAAABQAAQAAQAAAAEAAAAAAQMAAQAA AAAAAAAAAAAAAgABAAIABAAAAFI5OAACAAcABAAAADAxMDAAAAAAAwADAQMAAQAAAAYAAAAB AgQAAQAAAM0CAAACAgQAAQAAAL8cAAAAAAAA/9j/4QDSRXhpZgAASUkqAAgAAAAIABIBAwAB AAAAAQAAABoBBQABAAAAbgAAABsBBQABAAAAdgAAACgBAwABAAAAAgAAADEBAgAKAAAAfgAA ADIBAgAUAAAAiAAAABMCAwABAAAAAQAAAGmHBAABAAAAnAAAAAAAAABIAAAAAQAAAEgAAAAB AAAAQUNEU2VlIDE1ADIwMTM6MDQ6MzAgMTE6NDk6NTMAAwCQkgIABAAAADIyNwACoAQAAQAA AFMAAAADoAQAAQAAAHgAAAAAAAAANj1ONP/AABEIAHgAUwMBIQACEQEDEQH/2wCEAAMCAgIC AQMCAgIDAwMDBAcEBAQEBAkGBgUHCgkLCwoJCgoMDREODAwQDAoKDxQPEBESExMTCw4VFhUS FhESExIBBAUFBgUGDQcHDRsSDxIbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsb GxsbGxsbGxsbGxsbGxsbG//EAaIAAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKCxAAAgED AwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcY GRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJ ipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo 6erx8vP09fb3+Pn6AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgsRAAIBAgQEAwQHBQQE AAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJico KSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWW l5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX2 9/j5+v/aAAwDAQACEQMRAD8AZ+xh4E8M+L/2C/CzajpVo1zEuo+bcmwtppZdt/IqhzNE+cKQ B6AAV9Cx/AzwO8QxplocEFg2iaUf/bOuqhgadampyvd36+ZnOvOMrIePgH4APP8AYunsOvOg 6T/8iCqk/wCzr8ObiZ2Oi2YLx7No0ixQDnr8kC881byykur+/wD4BH1moUH/AGZfh75wb+yr IqH3bTp8YyPQlcHFDfs3eAFTavh3QwMD5n0xz/KYVl/Z0L/Ex/Wpojf9mf4e4O7wz4fO4AA/ 2fc5478XQprfsu/Dq5jLN4X8OLg4AOnXnOD7X1a/2XH+dh9bmUrr9lD4alcjw9oar3VbG9P/ ALf1i3H7LfwztlkmPhrSj5IbjyNQTdj6X+ecVEss5dpv7ilipPc8B+Nvgb4b+C/2jr7w9onh uG2tIbOwnEQnlcK81nDLJgu7NjfI3VjXC/YPBn/QGi/77b/GvMirxTOrnZ75+wxc3cX7D2gG 0mZHE+rRKEJBYi8RgD/31XuM3xZ02xeCEeN47y5nt45UgtdKmaR2k2eXGik4fdu+9uCjIGfl Jr6PCTUcOvV/mzz6qvM1l8beKZNKiuNLW2v1Z3QyNJ5fmKkkyF1AR8A+SpAzxvwTkcyReNfH E14fL0O3eIM2yQXHJGQASpgGOvPoPWuySb6CVJuN7r7xq+PvGomRJPDEZBOHKzsSo4yQDEN3 B45GcdqtQeNfE82pfZZPDaohkdUcyDJQE4Y9APu9M9+M1hH4tipYecVd2+9HZ+E59Q1bw0L3 UrWKC43BXhQ7tjbVJXPQ4LEZHWrfiTVfDfhLRf7S8Va7pmi2z/clv7pIA3soYgsfZcmtXLlZ zWPKb79o7wrqWpPpXwy8HeKPH16jYJ0vT3itV9d0rrkfXZj3rvdSlll+Gj6rcaTcWU0mnmd7 OdkMtu7R7ijFSVLKcg4JBxSjNSvYpxsfnL+13qZsf+Cg/iexW4Yi3i0+Lr/dsLcf0rx7+3n/ AOezfma+WhF8iPSbPsX9gW2u9Q/Y2023s4WkkttT1c7Qe3mWZz/4/wDrXuFj8BrqLOfDGi3K uUDi4tyRJEioFjb5umY0bjGG6EABR9BgoxlQV3s3+Zx1W1M6QfCW/m0Kzs7nQLOVbdX3I8as oZpHf5dwY8Fzgkk9ySearXHwbvLpDDceGrGZHJZ/MijO4kDPBXH4+9ehL2bNqdWgopSjdk6f CH7RZTQar4fjUTGM4t4on3lBtUsCFHC/KByMVp6V8L49O8VPqdvp94skhYu32WHPzY6HfnsP y+tY+4ncynUpu6jHT5/5nS3nhjXbz4S3WgaZq95od3eSjzLyz2/a44fMXzBCeQszRo6qf4Sw btXnXhL4H/DRtRuvEem/DvVvF+sXOpw2tyvjHdPdWOYVaTcJMq4BOdxB5Y4YgCoqU3KEqis7 W0ucbq8klBJ3f3feaPxH/wCEX8L/AAp0LTvDfxysfhj4bEt9thsrWKaW/wAS5ZLYn5kCSNJk xg/fUcADN3w7Jf337CXh/VNWvLm4vLjwZbXV1PPMZJJZZLJWZ3Y8sxJJJPNZN2vY3PzI/bM1 FpP+CnnxAVH+WHUUtxg/884Y0/8AZa8X+2yf3j+deDT+BHez9F/+CZkUU37Lk0jECSLWtTgA 9Q0dk/8A7Ka+5IrdFC/MqlhwD3+levhHaj83+ZyVfjLcdqTF2bnjHX6fypn2WR5PkgYg9tuR W/MjLQY+nySRFTCzHGcbTzTotPuPPA8t93ptNTzIfKzjPH2rafP4K1KAeGPEXiAWMsKzWmhI ft6t5pXzYVJXe0bYbAPRSeeh+evHvxC+I37QfwGTw78IPh347fTbDWEibWGu1je9gjtNjRXL K4BkMku8jcVwEzk9HOTXumnM3BReyZg+Kvgh+0N8QvhH4D8GS/Ci18P2vgywl02O9u9dtmE/ mtGWldFYsgHl/dUMeT1r6d1Xw/H4a/ZdPhmObzhpPh6PSxLtI8zyrdYg2O2ducVHSTI7I/H/ APaquTef8FIPiROgGP8AhI7tB/wGQr/SvKsP6CvHglyo7na5+hP/AATkv7uw/ZovZLaaOIQ+ KbhWZ4t+Q9pb/LjjOSB3HANfbmv+E9M8aa1ZTareyaXc6dHNCo8lHVjIuB8zgEdM4OM449a9 fBScKfMt7szVZ0K3OlfT81YydW+Buiad4avtaOu3rtbWzXWEhRcsiq25D2JMSc8/dHpXKQeC tKtfEUWmSI1vdx3tnCiMsYmVjEoUN0baAMcAYLHPodZ5g4yV4/j/AMA6a2c1ZQdNwVmrb9xZ vD2l2fg+DRIZry209pYtRSHZHNI0scLA5fcAFIZnwE+UrweBWD4y1vwz4N+Fduh1i5FprMri W2iaFr1DarNOHXzJwHAWUKFxk+Um0hiit2U88VWooSp63vv137fh+J8ZHARl7sZtaW+X37+f 4D/hD4u0m7/ao8O2EGoalLNLd3khaa5t3QbLJZGIKznfAWfAYKdxCkfLlh9B+APAGjfDr4G6 L4H8PL/oOk2iwrKw+e4c/NJM2ONzuWc47txxWGPxKxFVSUbafq/8z0MHhnhKbg5c2t7v5Gw1 qrRbWTOefpXM+M9ORvAt1EIxmVoo+Rwd0qD+tefKdqcvRnfHdH4j/tCTi9/b2+JF1/f8W6nj HtdSD+lef+WtedH4UdzP0R/4Je29ve/C/W7K5t45lTxE8qq/OGFihBx+FfeHiC0fV9JiNtoa 6lHbSYYZwwBHJU5+nr6+hrvwcrbu1mzmqrU1fDEd3aaDBpGo2UVpKsReBI+F29dvH8Q71pzR yfK5Un5vXv0qptc7tsZpaFd4D9oOGVhu6HB8vgcf1/GqN34V0nUbnzZIDDOpyJ4DtkBznjgj 9KSqOLugscjrS+FPA3gS/wDGutvNDbaLACzqFWRmZtiomANpOVUc9D6CvPND/aztk8r7X8M7 2LT2cM1xaaql3IkeTkurKhLYCnGe9djg699bEXsfQOlavpWv+GrbWdEuxd2N7AlzBMikK8bj IPI6+o6jocVg+NxL/wAIkqwSeW7X9kFO0H/l6i//AFV50/dhK/Zmkd0fhL8Vbk3/AO1R42vs k/aPEupS5z63Uhrl9v1/OuVWsdlz78/4JiPczWms6XBMYxLrRLv6D+z3Pp/s1+g3iv4heD/h l8MJvEPiG++zadalISYomlZ5HJCoiqMszHPt1JIAJHTQi5xcV3Oer8SPGNK/a0+FvxC8VRaT rWi6rorecy202qOi25zjbuKOQhbuGG0dN54r6TsIm/sSBJYEh3RrmJT8qcdB9K6cRF04RTZE VqV7S80rUxdLpl7DcNaztb3PlHmOVTtKtx1BX9KsQ20kNkN5ZiFxvkGNxHc4AFcjunZlWPmD 9rjVLf8A4Vz4d8BWNxs1DWtbjLK53BYiXAZvQeaVx7A59+I+K3wA0j4b/s/T+KvDPj+O7vdB mEesB2KJO7yBQkajOMcDBJ6djXrwk4pabmDPcf2R9dg1P9k0aWbhGudGvpYJIA2RFHITKnHT B8xhn/ZOeRXc+P7mG18LwTMFCrqliTn0FzGT/KvLxXuud/P8jaC2PwP8VXf2v4r67dEn99qt 3J+czn+tZnmD1NctjrPur/gmNewR+N9UspFaRpNVDKg5J/4l9z0/75r7k/aF8L6b4o+A2lRa 0Fs9K0vXIdQupiokXPlTRRoy5BO+WWNM8kFwecGu3CfF8zlq/ocp4x+GHh3U/wBlbTLC28Ke DJ7LUnsLe0uZ1aK+kuZ5oodrMF3MB5hyAwJVMc7uPbZvGug6Jpd7q2veKLO3sIWX5zEUVPMl 2IAeSxZmUAYzkiumsvaLRO9/6/yM4uw7VvEvgzwxog8bX2v6Naafq6wg3k97HDFdgqTE0cjE KSVY4ycEEHI61geAdEgvvjf4w+J2i+O013Q/ENvaxW9taX5uFtZYk2yx7QxjU8IRg5BkfPqe PVK7W5pofKf7XeoR+KviTZeIND1e01DRo7ddOgns7oSw20ysrSQ5U8SYkDknkhgemMQ+D7Tx j+0R4MsZfHvjeCGy0qVLeS3upo7E3hUMRMzhcPIVAAZxwcHndXr048seuiNcNQWJk03ayvor 9UtrrufQPwons/hf4cvPBehafo9zFNdS6jFI2uQo/lsyqqNJ5eJCOxznaO2KqePPitb6tqCe EZtAeCdNSj8ydbxZo/3WZDj5RkHb1rz8XRTjOd+nY9eOVcsJSjP4VfWLV/xPxGvJxNrNzMRz JPI/5sTUW9fT9a4DzT6w/Yk8X6r4H0zxD4q0SG2nu9MvoGiiud/lMZbW4iy2xlYgBicAjOMd 6+y/h/4z8Y/H347ad4X8b+LLaytrOCXU7LTtPt/Ktrq7gZCiMGYu/wAu9/mZgNnAB5rvwijG Eqj6P9EctXWSR0HxRt9U+Bvxk8Ja/Lbw6z4fW+nvLHRGmaKWF44toxKdw8tWlVghX76jkACu Z8RftAeOte8M3E/guPwxp0VnPb3ctvDDJHexx7i4keSceSkSEBGYMMFvQg13WVa1S+nb0Mfh 90ba+Efit8fP2fPAGv65r/hoX1rqd5Pp/h/UENjHdadHLbwiX5AdyxsMbghBWaPk55Z4N1Dx 58ANW1pNQh8Ny23ji9urzSYtOnd7aO+t75IpYgWSL7kRnKj7rbUHeua8ZPkS6lWa1NPwT4F1 P4s/De/8D2dloUVtYm3uprt0a0lRzE8URR1VzJhUMYzgKsIGMj5mL8NPjL+zl4Dk8U+HLmO5 0JJI21pYbRZ76BFYCeRXYEmD5fMVgucYLqu3NdPtqal7OXU1w9SVC8kk7q1nfyfRrsXpvjh4 B8a6nf8Aw9vvG+uX95ZXM5mjFpGIZILQbiwm+zjLBVk53ENsB5yK2fip8LvC/gTwVa+ItI1L VLh1uyiC4ljaMqYJju+WNT245rixb5aLjFaanr0s2rKi8OoxUZevX1kz8UI5g0CsW5YZ/Ol8 0f36804dD6P/AGV7zyPhX46YYytxpuOehZpVB/Wv0a/Y18MW9z4o1rxbKqldOiW0sgV6GYl2 Y+4REUeztXfSdsNUfn+iOaf8RehL+2RpBHxC8M64Xby5NNvYWzkqnk4fp2J8zt12c9BXz14D g+FnizTtbsfib4i0/wAPzLceZZ3k14lvIIZIgVKhiBJteLgEEIX3Y5rpc5wwsZU1d/f18jlq txbsewWOm/CT4dy6bBonx7awsjpaSWtpeapC0b5AQTRtJudPM27z5TBCeNuBgXb3wB8JNS8B aXoD/FpxpemanBrr4v5XhETIkcOUkdlSORLoYZApYunzHcBXCsRWvrH/AMlZjzy/pMu+EvDH hfwTeWHibwd8f7hP3CWU9ujILfWJ4hIV8xWyplwyodoGcbsZZifedP8AE0qQwy37/wBlW+pR TRyyghBaSrkq43gqMoGb5hjKcg5NaS56smpR/BmlKpLnt0Pln4RfDDwHpnxvstas9UsZLm1a QJskMpvJGV/NAmjZQwEW52UKUdN+QFrS+P3xAm0XwDp/wzmsk/0ezv7y1vA7Yltbaz/dOBtx 925jU88FTit8bZQZ0UtZI/G62Yf2fF8/8A7+1Sbx/eryrnbY+if2VYkvPCvjbTXk2JO9gSfT DTH+Yr9Ev2c/iW/gP4B62vkaBPH9vmvwl7r6Wc77YEykcXlOW5XjJGS2B3NfU5dln1zATqcz +O1lHme0fNdz4/Nc8+oY+OG5E/c5rynyrdq3wu700NP406tN8aPAOlWces+B9CnsnZ5FfxZH cSRiaMK0bqIgAwBycEjjvXyK+nWFj8XvBt5r93mNJokJa0LI8auuZCoJLAZLbRyduAQea7o4 CNHCSkpS93T3o8t7vpq9jOnm1StjIYeUI+8m241Oblsr6rlW/TU6PR9FHjrT9f8AF0nhQahZ a3oh0mKS30tnTR5/M2eeJQwVTuYuA33tygsN2a2v7Rit/wBnW58H+EZdJubrQtGEWuy7XQTW dtcW8xuLViVLSRPGxZCpVo03Bt2c+U1eR9AZNz8TtD8Q/F7TfD+qW6/Y/C9zDdLNp8eyS48u OOJ4UVEwdhUsr4ziNhyCMeueMviS/wAQfD3hQ6uVH2ZFnnt38xC05nOJDCcE/Jb5Hcb8AHzB Wsls+xVOnUqtqEW/RX/I88vdW1Pw/wCHb2107xC1hcWqvZh7OZlAja3lkxHIqs3EscXzo20k YBKsKxfiv408ReJdCstX8Q6hPetpfhTxNp8NxLIS8qr5DBmBAbdh9m9hlxEOpBJ8rGv3Wjsp 0KsNZRa9Uz837QE6bGc/w+tS7T6/rXmGx7j+zUI73RfGGnyKSlzNpcb7YvNOGuHUkJkbuvTP NfQf7Q/w18JeDvHPh/wj4LvJ9X1m9tpDqFtDAZLi1dTjbtxkNjdlCBtMJPQ5r28u+CWnX9Ec WIvdGx+0v4A8E6P4t0KP4XaTfDT9Sikj33Cz+V5sOI22tcOxUHb93JUbCAcqVFvx1bfDNv2Z PAWu+GLCS71yC2hsdRsbRWijkuUWLetw0kkgMo8i4A2Bci4Q4AA39zUml+Jz33Ot0HQ/CMP7 PHge50XRYJfHN1rNvcanFdJLHPLAZNwUhnMYUZiKbUwxjUEqd9Uj8A/Hekvr406KWfUL3R7i 1sITEYS8Uskcc0kh3YC+TIQB3aQdlyd6eGlKKnKSV72u/wDgHFUxkIScFCTta9lffpuefv8A s5/HfQvF9t4g0vw40d4t3IioZQBgjGN3fcrOD0wO/p738PvHN/pvwrjtPH82rXfiKS5efVJb eCznR7i6upskb4yVG5kGQcD5hhQqmrqYV8nNGSfo/XyXY7svzKgqkqdRSg/7ykr6pfZ9UU/G GofD/VNRF/rI8am4MAOy1gsCMMqugEcOcAvMABjowA6V438ZLX+wPhx4wiiW4jtYdH1ZLcXJ Xzighyu8Lxu2sM44zkdq8KvFzpT8l+p9pPN6UsK8POau0lGynr63XZH5+aeT/Y8YGMDI/WrG W9q8g8A9a/Zmjvr+bxhpOmWr3d5eRWaQQIAWlYSSHAzx0FfTHgLwp8TW+O2ha3rvhzUfJ0yG VRPdKsqqsUErxRNtJZlL7Y+eitgYAGPVwdenTjKMnZ3/AERwYhpSV/63PV/Gh8W+JotZJ8OX 0qTWfk2luybtsUaFIIgD3UKoz/e565rxZPBnxRbTbWwvPBmvNZec8/kmPMaNIse9wM4BYxRg kdQi5OAK73iaFkuY5HNFfxn4V+KY8IXdxomh+I9HvbJGeGe3LRSIq4bh1wQPlwa5+x+MnjK8 iTU9K+GeutArttltvGuvSx7QVLqGM7Y4K554+UmtaWKlLSlPQxlh8NWfNOKb7l7SPjB4h0fw hb6Xq1h8SzqsDt9ouU8S3UQI8wyAeUZAB8rRg9M53dTzUvfjXpr6hBObHx/bWe8tdRnxDHKb heHjw7qdhBYv/ETkYIzmuqdWpKLTZ108JlsJc0eZP0Xlt73dfgc3dfHvzrW0TUNL8bNJDEsM zR+OrdRKAUwBu09iMbBgMX7ddorLvPid4+8bfDX4iS+Ltau7qytfDF8dOiufJeSFJGwFaSON N7AEAsQM9gOg8DEc8KcrbO1/vOmEISkm91sfOGmMDokeXx1/matZH9/+VeU9zsPSf2cPEd/4 Y1rxfr2lSpHe2FnBcQPIgdQ4kccqevBr6o8A/En9pzWvhtb+JfDHizw3ZWF/cGBY5bCZXZxI IicJCynluoJ4z34r0sHQp1HKbvdPp6I4MRG8k/I6608c/tgXIU6d458K3hQo/wDo9pPMFBfa GJFvj72/3+R+Diq0Hjf9rnS7Jre18R+GC8TSQx2aabcmdpVjZxGqGAfO8cZZVyCV64Ga75Ye G/M/v/4By8rPItf/AGrPi9q813Z65caM8ypJZTo+m7JIvvKyEBhtIJbjHBqj8LPjBd+BvhjD pVt411fTvs1/LdxW1pPcKDmL5SAhCg+YqnOcg46da0oYenSb637nfgHhYVW8R8NvPf5G5Z/t B6tp+i3tjo3j3XdMtpLYXTwtfXJae6ZEQZI3KTGkSL8y7W2gdOQ7Tf2g7jR/EF6mj/E+e1gk ZC0ayyeVL5drBBGFDREqwS3hXcRn5O44PW40+x7K/sieu3zl5+v9P1G6d+0f4uaaxu9X+M07 39vBdE3KSYkSa4uYXmCjyAFQ+TEwwQMqeME58Nsrl4v2ffiA8jFR/wAI6Yxk55aRRXkY3l9n 7v8AWpzV4YWHJ7B3dtdX5d0vM8a06d10WMAZ6/zqz9pf+7Xj2MrnXfCa+sNHk8TW2p6vaWQ1 exWCCSbcFDCTPOAT09BXomk+LvEGmeHYdH0r42abZafbTrcw20V5cJGsocOGC+V/fAPpmt6W J9hdWeplOk5amxa+PfGS3M06/H3TvOuJTPLLNqVy5dyiqWy0R52og+iirEPjnxvaTtcW37Q+ jNI7byP7UnY527c/NDj7vFdDzBfysy+rO5Bqeoa9r0sdzqnxu8IajMEMam7u5JGjVnZyo3W/ HzO7cepqh9lvuT/wsXwDIeeA6n19baqWYwT2f9fMn6rIrXvheW8L3UnjvwS8jnaUhvWjzgdQ qwBRXST/ABA+Lkugf2RJ4+8HXlkLEaZ5LWdkwa3EflhN32YODs43hg/fdnmnLMKbXX7hrDS6 lePx38ZhqCPDe/D+7Kcrv0HRpF59Q9tzxxzk1xHiu08Qab8EvGEmsrYC41q2UKLS5hYM5nV2 ASM4UdcAAADgVyTxEZwcV1t+ZtGk4s8c03Mehwoycheas7/9iuc2sf/Z/+EZDGh0dHA6Ly9u cy5hZG9iZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBD ZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRh LyIgeDp4bXB0az0iWE1QIENvcmUgNS4xLjIiPgogPHJkZjpSREYgeG1sbnM6cmRmPSJodHRw Oi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICA8cmRmOkRlc2Ny aXB0aW9uIHJkZjphYm91dD0iIgogICAgeG1sbnM6ZXhpZj0iaHR0cDovL25zLmFkb2JlLmNv bS9leGlmLzEuMC8iPgogICA8ZXhpZjpTY2VuZUNhcHR1cmVUeXBlPjA8L2V4aWY6U2NlbmVD YXB0dXJlVHlwZT4KICAgPGV4aWY6V2hpdGVCYWxhbmNlPjA8L2V4aWY6V2hpdGVCYWxhbmNl PgogICA8ZXhpZjpFeHBvc3VyZU1vZGU+MDwvZXhpZjpFeHBvc3VyZU1vZGU+CiAgIDxleGlm OlBpeGVsWURpbWVuc2lvbj4yNTYwPC9leGlmOlBpeGVsWURpbWVuc2lvbj4KICAgPGV4aWY6 UGl4ZWxYRGltZW5zaW9uPjE5MjA8L2V4aWY6UGl4ZWxYRGltZW5zaW9uPgogICA8ZXhpZjpD b2xvclNwYWNlPjE8L2V4aWY6Q29sb3JTcGFjZT4KICAgPGV4aWY6Rm9jYWxMZW5ndGg+MzU0 Ni8xMDAwPC9leGlmOkZvY2FsTGVuZ3RoPgogICA8ZXhpZjpGbGFzaCByZGY6cGFyc2VUeXBl PSJSZXNvdXJjZSI+CiAgICA8ZXhpZjpGaXJlZD5GYWxzZTwvZXhpZjpGaXJlZD4KICAgIDxl eGlmOlJldHVybj4wPC9leGlmOlJldHVybj4KICAgIDxleGlmOk1vZGU+MDwvZXhpZjpNb2Rl PgogICAgPGV4aWY6RnVuY3Rpb24+RmFsc2U8L2V4aWY6RnVuY3Rpb24+CiAgICA8ZXhpZjpS ZWRFeWVNb2RlPkZhbHNlPC9leGlmOlJlZEV5ZU1vZGU+CiAgIDwvZXhpZjpGbGFzaD4KICAg PGV4aWY6TWV0ZXJpbmdNb2RlPjI8L2V4aWY6TWV0ZXJpbmdNb2RlPgogICA8ZXhpZjpNYXhB cGVydHVyZVZhbHVlPjI3Ni8xMDA8L2V4aWY6TWF4QXBlcnR1cmVWYWx1ZT4KICAgPGV4aWY6 RXhwb3N1cmVCaWFzVmFsdWU+MC8xMDA8L2V4aWY6RXhwb3N1cmVCaWFzVmFsdWU+CiAgIDxl eGlmOkFwZXJ0dXJlVmFsdWU+MzAwLzEwMDwvZXhpZjpBcGVydHVyZVZhbHVlPgogICA8ZXhp ZjpDb21wb25lbnRzQ29uZmlndXJhdGlvbj4KICAgIDxyZGY6QmFnPgogICAgIDxyZGY6bGk+ MTwvcmRmOmxpPgogICAgIDxyZGY6bGk+MjwvcmRmOmxpPgogICAgIDxyZGY6bGk+MzwvcmRm OmxpPgogICAgIDxyZGY6bGk+MDwvcmRmOmxpPgogICAgPC9yZGY6QmFnPgogICA8L2V4aWY6 Q29tcG9uZW50c0NvbmZpZ3VyYXRpb24+CiAgIDxleGlmOklTT1NwZWVkUmF0aW5ncz4KICAg IDxyZGY6QmFnPgogICAgIDxyZGY6bGk+MjAwPC9yZGY6bGk+CiAgICA8L3JkZjpCYWc+CiAg IDwvZXhpZjpJU09TcGVlZFJhdGluZ3M+CiAgIDxleGlmOkV4cG9zdXJlUHJvZ3JhbT4zPC9l eGlmOkV4cG9zdXJlUHJvZ3JhbT4KICAgPGV4aWY6Rk51bWJlcj4yNjAvMTAwPC9leGlmOkZO dW1iZXI+CiAgIDxleGlmOkV4cG9zdXJlVGltZT4xLzg8L2V4aWY6RXhwb3N1cmVUaW1lPgog ICA8ZXhpZjpEYXRlVGltZU9yaWdpbmFsPjIwMTItMDgtMDJUMjI6NDQ6NDMtODowMDwvZXhp ZjpEYXRlVGltZU9yaWdpbmFsPgogICA8ZXhpZjpEYXRlVGltZURpZ2l0aXplZD4yMDEyLTA4 LTAyVDIyOjQ0OjQzLTg6MDA8L2V4aWY6RGF0ZVRpbWVEaWdpdGl6ZWQ+CiAgPC9yZGY6RGVz Y3JpcHRpb24+CiAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgIHhtbG5zOnRp ZmY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vdGlmZi8xLjAvIj4KICAgPHRpZmY6WUNiQ3JQb3Np dGlvbmluZz4xPC90aWZmOllDYkNyUG9zaXRpb25pbmc+CiAgIDx0aWZmOlJlc29sdXRpb25V bml0PjI8L3RpZmY6UmVzb2x1dGlvblVuaXQ+CiAgIDx0aWZmOllSZXNvbHV0aW9uPjcyLzE8 L3RpZmY6WVJlc29sdXRpb24+CiAgIDx0aWZmOlhSZXNvbHV0aW9uPjcyLzE8L3RpZmY6WFJl c29sdXRpb24+CiAgIDx0aWZmOk9yaWVudGF0aW9uPjE8L3RpZmY6T3JpZW50YXRpb24+CiAg IDx0aWZmOk1vZGVsPlNHSC1UNzY5PC90aWZmOk1vZGVsPgogICA8dGlmZjpNYWtlPlNBTVNV Tkc8L3RpZmY6TWFrZT4KICA8L3JkZjpEZXNjcmlwdGlvbj4KICA8cmRmOkRlc2NyaXB0aW9u IHJkZjphYm91dD0iIgogICAgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8x LjAvIj4KICAgPHhtcDpDcmVhdG9yVG9vbD5BQ0QgU3lzdGVtcyBEaWdpdGFsIEltYWdpbmc8 L3htcDpDcmVhdG9yVG9vbD4KICAgPHhtcDpNb2RpZnlEYXRlPjIwMTItMTEtMjRUMDg6MTQ6 MzAuNzE2LTg6MDA8L3htcDpNb2RpZnlEYXRlPgogIDwvcmRmOkRlc2NyaXB0aW9uPgogPC9y ZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSJ3Ij8+/8AAEQgCewG4AwEhAAIRAQMRAf/bAIQA AgEBAQEBAgEBAQICAgIDBQMDAgIDBgQEAwUHBgcHBwYHBggJCwkICAoIBgcKDQoKCwwMDQwH CQ4PDgwPCwwMDAEDAwMEAwQIBAQIEgwKDBISEhISEhISEhISEhISEhISEhISEhISEhISEhIS EhISEhISEhISEhISEhISEhISEhIS/8QAwgAAAAcBAQEBAAAAAAAAAAAAAgMEBQYHCAkBAAoQ AAECBQMCBAQDBgMGAwYCCwECAwAEBQYRBxIhCDETIkFRCRRhcTKBkRUjQlKhsRbB0RckM1Ni 4Rhy8CU0Q4KS8RkmJ6IoNlRjc8JGZYQBAAIDAQEBAQAAAAAAAAAAAAIDAAEEBQYHCBEAAgED AwIFAwEHAQYGAwAAAAECAxEhBBIxBUEGEyIyUTNhcRQVIyQ0QoGRoQcWUrHB0Rc1U3Lh8ENi 8f/aAAwDAQACEQMRAD8A5F6aagzF0XpTqK0rd8w8GwknuT2jWdt9MnUDVpUTVC09kpmXOR43 jBKh+veMVaKg7HZlqd/qZ6ekfqpW/tOkQdVu8qUTTZ3j3HP9IC50pdT0ulwu6JPpaT/El1pR V64794zuolyKVRBH/hw6lykq/wDDrVloSONymgFf/rd4Oa6eOo6VlkzI6cquM5y35Cc/QBWM wUpprkNV1F4AzWiWvrYw/wBPVxsbjjKpfGPqRnIjxelOttOWZaoaAXOlSc5Ik1KSoYznP+cC pK4SrWfIVMaaapy6Uvf7E7mV4gyEok1nH3OISvWlqa1uLukF0IQgeZRp7pCf0HMUpJtkeozZ cCZ6h3zLrUUab3HvTgHdT3hjPb+GPGlXQx+7nbRrrKv5XJF4f/2wMmr4DVayD/GuCWaDkxR6 yjfjAMq8B+m2AquNyTUW6kxVJdSedjsu4j+6YYnfBU6yWLgP8VOTaSZN6eU2M7nPDXgY+4j1 V5sSqk/OVN3KxhsrbVnH6RJFKr8gDf1vstlx24drauFL2+UEemY+cv8At1hKlft9sMqA8+Bh Q+/rCor1FOorIWMai095pLctX5dO0ZwG05++cQU7ebQQplVZlCntvLScqB9+INe4tVLu55S7 okZN/wCcp9Tp7xHkO9CVAn2wYXM6gyzaVOOJpJSk4KvCTgn2zFWvLAUqqfJ8/fUm5LLzT6OP GBzhoE/2hG1clI8JDDknT1EjuWwfzhlmwYVlGV7Dm3edvtyyGf8ADlEdUAcLWwN5+mYCi7bV 8BKnrRorhC8+ZOPyzA7ZfI7z4NcBU/ctoTq0qFn0dI9m0ZA+vMM7zdrLmFrbokicq5QlIwPo MdoibUhcpQkr2PnKPaT5Kjb8qMYHB7x6bctNLW4W5Krye24Z/wBYJyl2ZEqT7Hi7dsjwSTbU tg9gpUFptixHmw25bjJJPqeMQbk/kJxpPCQjm9N7NfX8yxR0IA5whWYSTGllqziw63J43fwp V2/KI6kjP5dO/AJvSa1Rn/2SVgD8W6Ap0ktFfDkgry8nC+YkashbpxQBzRi1AgKXKLTnsd/e PUaL2slrLzKlH0Tui1VllBKjB5sJpnR+31O/upZZQnuCY8e0atvxgthlwJI7KOYJVXtuE6UE uAlvRqjNOkKScH1z2hJVtGaa40E02Y8w9FDGYnnO4Kox23Ay2ickZYfMuLB9Uq4gb2g9KXsR 89n1wU94nnWBenigtPT8wj94ZsgjuMHtA/8AYVSHU5fnFE+hAinXayiPTQYld0Fld2xE5wOQ cQWNBkOqLfzwGOQDnEHGpujuBdFWsCY0CcSS0ua5xwkCAvaALaBeTPKz9Uxe8FUV2EtH0AdX WVNTcz4bZGd60cQ9u9OtFb2LTXOD38vIgfMe6wapxaPXOneghAQqtpRxkHaTmIjUNCXk1NaW J1JTnAISTBKeSqlJJJoKqekD9LSEPziEj0JHeEP+zj//AGLcWndDYULornp+YSNXbfm0nalE 80rg+yhH6DtC7PpFU0mo9S+VCnW2ShXhHC3DklI5GOMgQjWv94ZIv0kYuTVS2LGmXGb1l36W W1FOXEYRn/zdoLpHVboBMTCUT96SqTjCipSdwx9CeYz+TN5SB3K47sdS/TwhJfY1Ckg0v8OF J5+xzj+sOEj1HdPbjCQNRpRsqzuKcFX1wfWK8qdwdyuOQ126eyMf49p+7G1KdxKljAOefTEP ElrX07PyKjNah0lK2/wlajgD1GRxn7xHSnzYtzPhq1oS9Mo+VvSkKAzlBwVHP6w403UfSJpZ Ld4UtRO7Y4DwPtxASjJYsWpC2TuvSN1JL140UpKcJSFY4x6cQlk65o+CpoV2hcg/ixkH0529 4BQle9iOa4FMtU9H54fMPztCdLZ3bVqR6e//AHgySTo/NLLq10BKFfhyUJAB9ABBuMvgpyzd BjdH0Wd8ztLt9wpByXEtlJ5+o7x6/a2iLrJaXbduKS7hOQ03tH2Pp2iZ2k3Owim9L+n2dSFP 2nbLm7GAtpsj77cf1MRPUbSTQKnyCZn/AGf2662FEYaZbxn6AekUo3tcm52eRjsrQvp+vErk K/phbrQSreFFlvC88/hiSzXRp0vT6jML0woaipGEoSEkJPuDj+/MUm0y1NoiF59FvT+iqIla RZdIZwwXVbWkYOD3I98QnrnQt07U1llKNN6HNpmGS4SWU5SR7/eLUmXKbGj/AMEHT1+zW6hL aR0pEklwNLd2jO5XOBn0hxnOgXpDctd24UaUU5lyUJK1MnhwD0PuP9IjlJcEcmxj/wDw8ely p3O3QJK1JJxb+V+E3uVkYBI5/OPrK+Gb03XL+2lptBCESU0WWlpyUqPPfH0inOV8MiqNcjnJ /Cq6YZF9pc/aSXOCssoWrufQe39YcXfhZ9IDzaFDTaZO4hSgJ1YOSccbceb6nMHCT5L826Ap +FD0aPL8GdsGpKQvulE6tJHr9TBjXwneiJhp1CrNrSVrRnfL1Agj7k/bmBc5XKjVaeBMv4Sv Re6pCv2BX0qKskO1BS8D7fwn+kNtU+Et0ovuutU9i42kZHKZ4n79/T3xB+ZNrkKNZxbYob+D /wBKDtNQF1q52FnkkTBVj6Z3CGef+Er070usyyJOr3A3KOk+YzSluD07ZA+veJulbkqepkOz XwgemUBS03fcyFuozhuYUlIV3GRk/n7w1v8Awc9BG5sB2+Lld3eYOfMEE59APaJCUubkVVtB bvwgtAzUUoc1KuhSU/hAcGD9COM49+IW/wD4Mmg6yluQ1guzYpRKnJkIUpH0CRgY/PMVKpKI SrSQmqXweNK6ZJH5fWWtrUQQgPSwIB9DuH9jmEX/AOD1p7NAKmNZKoyAMeRgcn3x2/tFqq0r ElXYnm/g6aay80iWGu1a+XPB3yqSr755PaCmfgzWLJvhhjW6pvoSFEvvS48x9tvB/wDtEVST yRah2EFS+DTQWcvta91RYUcBtUqkpT9QR/aCf/wfbfLay9r9NNFGdoEnynHr25z+UTzZB+e+ 4gmvhNU9DW5OsEwRuKcBo5x/N2xzCYfCjbdVtb1PUkDs6GiRj6jEA6rRPPCF/Cbn5plMsxrS 6nnHiiUBJ/LHEIZj4SlYlpgljWTbvTwh5nzA578CGqu4xsSVTAUv4TV5IlhMM62sLIH4nWFZ +3AxiCV/CkvJjK062yQABy25LqO48c59IpV38EjUQglPhZX9PuvLRrhJJ2jI3MKO76djCx34 TWoswlHy2tFOwBkoSwTuP0zj+0F5lpXsTzbKwen4Q+rk00kjWGjlQ4x4Z59/TAjya+DrrTTp L5t/W23lpRyUNIWXHCeyAnaMn65glVVwHW3GJ+uqxqjoZNyVtVquJfmgpaXC2nalJScYxGc/ 8cD/APjz/wDUY3U4Xjc10qqUQzSSWTLX9R3G+VJnG1Aj08wj9BXS9VBM6M0vw1AqQMeb/WM2 t+qjnw9pLLFeptW1OnKFW7Yo9Vl1yfKKnKImC2Qv8aSoHHtErqOlGk0xM73tI7c3jPKKc2kH 39I9XoKFOeni2jmVptTdmEsaCaIvblL0Is5azys/s1pJc/8AMQnn794VJ6ZunWZCUT/TrZy1 qTguCQRz9xjCj+UPekpXvtAdWS7gHOkfpbmWhLudPFr7FYUVCW2kf/TgQkX0a9Jz7YaHTjQE JHGW1OD8x5uO594H9FRa9oSqy+RHO9EfRuZoNv6D0hKiAUeZYJHtkHkD+kBHQ30gTmQjQ1tp PotifeSBzwcZx/SAfTqEuxPOkmEq+H30jrcSgaYTTO45xL1SYBH282M/lBavhydHQG//AAFW UuKIOF1h4p49xnBMCunUb5QfnNHrfw3+khpa1t29cjOUkBSay4Qn15HqM9+fSC0fDi6XEshD U1eTaz3LNXWkHPvknMT9m0H2A/USyFy/w2emdua8aXum/mC5jJTVd5AA9AoECBOfDZ6fVTAm GtTdR5cJ5ChVwVH7jZg8wMulUeET9RIE58Nzp/XllnV7U6XbUMjwKi2Nx+vl/wA4Tzvw0dGX QptOueoYQv8AhcnEqwfplPA/vC/2XSTJ+ol3E7HwxtMkDy9Sl9NO7QnLQbAPJOAcZxjH9YGf hsWuCUNdV99MgJ8rmxte7PcKTgA+hz6Y+sLl0ukuGX+obGyY+GNTZVwrp3WNejhIwDNSTXA9 s+oP9IBNfDmraWEttdY9fKGzhKnZJGdp7+0Z5dJiu4S1DETnw3L7alF0+n9bE6uXWd/hKkSl W7PfA9fpAUfDi1X+QdkJfrW8kwChbT1MWOO4KsZ/oYCXSl2Yx6lWwBo/w7NeaPPiep3WBJh7 8IfXJLG3gDJ5zxzC6idA/U9RZh1mm9a9FKZhZccLki4kLV78cZ+8D+yU83K/Upg5roj6vHJk zDfWlRipIPlXJrQAPUDg5/pAFdG/WnLJSuS6vLafQoHJcYLZWke4P654in0u5S1Cjg+V0mde n/u8t1PWaoK4T8wXAnHuVYOIBUulT4hKR4FM6ibLB2kFLDpJPp37AevrFLpLkwv1MbXELvSt 8SQgljXSwnsK2bm3VYAz35wf7CF0r05fEhlpVKGtWLMmcgcLcVxgfiIB4H/rmC/Y0mSOpg8M Mc0P+Jn4CEovmw9vfD0yQQnt2BP9YImNBPieBADdesN9SSfxTeE5/U4H2in0Wp2RUtRAVTek vxQmSh1EvZTjDeMqRUEJAPorvyPyJgf+BPiivsNLmrZtFxsZIU3UkrIBJ7JGCOMd4F9HqJYR FqYCWa0t+KM3NNPytg2q8sdk/NpUc+g4Pt3gwWv8UaW/960utouI/EGp5IT24GM8ZH/owt9J qSdrBfqYc3AzdD+JxNNeO7pJbrjRTuATPDI9eQOITNUP4nywPD6f6Hj1PzwG4DPIzFvotUn6 mNrJgF0v4lMxLiad6cJNRAyFJm0qHfuf07QS0v4m8k64+30vSagk/iE63tUkY9CO/J/T84td GqrBS1MRwZrfxEy2Jao9LDQUnJ/dP7t/3I7j29oSTUx16upUlrpiIcIBDCJnOfc4xkRT6LV+ A/1MLcieoTvX2ZVH/wCyfOtKSAoobcyVg+xxzCRNzdd6MqT0lzpTnClhwhaPcEbf7EwqXRqt rlrUQ+QDV4dbbYJV0n1ZLgWBhlauU+/4c8e0EOaidYyZlXjdKFTDm05Q8FICvb+HI/SAl0up xYLz4PuGMamdVrKA3UOk+tI3KGVIQrGPfJG0j6DmCk6s9TKEEP8ASvV920qAJVuIz/Lt7wt9 NqRLVaPYTr1e17S/unel6tNkqKQEIWc/9RVjA+0KZXXrW2QcJmemSvJKfJ4SGznPtu7Zi/0F TuR1E0Ocj1L6ry8w3KvdPNYkC6oNqdnk+Fzxgcj6xprTW2FVG2hc1wyLQmlNKcS1u4aVtOOc Rmr0/LkkwovucCvjRuuVTV9DkqRtW++4pI45K+RiMP8A7OmP+WY6dH2IapWJ/pg54F9Upwq4 E02c+/mEd+uldTsxohT3E4SkKIJT6K4MYtb9RFR9pKtMl7uoZyUS6kqcpjp2lWeziDu/vF3v SSOVBQ5/9do9r0uN9LE5Fd/vGGMS0u0lQdSCB64hXKMNuBJSr07ZjY4CripDJAO4BP8AaDG5 fCsBAweyTA7S7hNQtuXnX25r5cKWzynjkQKSlMPpYcSEo/CDnt/2ilElxWqVl2MFSckDggR8 pKFoyhAP0ibckuF+E94OUkpJGO3aPKYl1bakzzgJHYEc/nFWBYoSEBCmz3x+UEpUyFHxUYIP eLZD1xDilbUJ4J547wZ8spQV504I4hbRYBsBOUkcjgmBLY8QBwJSAO/PeBkikEfLod5SnIHq THrkvKKlsKCSMbSD3hbRdwj9n7CHWUgAcY94H8slxvJA3DPrFSWCAW/EbWEhGCTjaT3gtDQ8 byNnO7nk/wDrELSwXcFMSDbqwh5GVAfhHGYCac2gBHhp27cd4m0q+Ql+UaabASB5e4EDlGAV Zx5e230h0VgpsNXKpDuAj8XHaPkyYA2AAcYOfeGpA3PFyym5cq478jPcx8uWL7YAHB9oZtwR sAJTaTsUoEehjxhgfLFO7Ch6/WLSKuessrKC21kjOSMwVWJ1wI8Ad0j09Ym0JMHIszTyC446 rKeSATzDrJMTe3cHCfuTB2wCCebdbWeVbjz6wkSxMLfKn+57KUe8XFWIjxwT4B/3hSAB5cKM D+YqDDe75t0lQ7pUcxZAgvTuxKmpp0r9FBwggR67UJ+VaLwnHsAfhC1cGBmrliJu4qy9/vC5 idSDzhTis4+sGLqdXnGyE1h8j6uK/IRmnHASI7U69WW50yDVbmGylXdK1cn7+kGJrFwAImXb hnSQMhXjqyk59D6cwpRwNixPM1+5G3lOylwzqVL7qS8rMeOVO4igpVVn1JAzjxD+v1hewvcV 5qVWK4/WKNTZuuTb8uZ1B8Bx5RRxknyxoa16iymwXnVyuUtSjnI4x5Dz+Xf8o8n1NJVzoUne J+dX4rc81VNZUqdcxjxFfXlRPIjJ3y0t/wA6NVL2IY2PFjsKlrppzmSdr6CQfYKBjvf0Zzoq Oh0pvcIRnelRz/KIxa1fvEHD2E/0olUs69sqS5z8m+0STzypBz/SL3dlFpUV7OMYznuI9x0n OkicfUe9nwZRgEtZhRLSiW3PE9Dzj2jc0IDXEErKy53hZKtpcHDu4jvANIJCvZ50+YjHMFv0 9K1b04BJyOYGyLAMrHilh4Dy+pMHLlENNlQb4z6GI43KPQwl5OFox68cR6acQ+l04IHc98wL QIYuUl0oDe3B9DBU1SpdbCscke57xGsFoIRLuNS/mAIBwOe0fBoFIWDge30hbIeLAStKQIE9 LCYWEE7ce3ECy+598kgAp9ByAOI+EqytHh7Ru+sCQA4x4aiF8Z7Y9Y9+U/hBBJHJEVJYIAUw tLg8QBPAyojOe8C+WU+koCwR/aF2IwhyVVLupdSokk+vaBPSanEF0EHPJMXYsCJJt7aVs+X1 HvAWpUyq1sJHKex57fWDiCwXgeICrxcH2BgTbBU2fE25PH2h0UUARKAJxzx6wYZMNcoP25xD UrooCZTxRtIxgZz/AJwQpDOeB9zmLiiu4YJdCcITgZ54OcwjnacpyYChg88gmLsi7YHKVpwb G4IByP4faFReDST4Tfb29Yi+5EeqQp9vd2J7QW5TVPIC1ryR6GLLPltodV4Kcfc+kFvSwa2p UrP1iEsgLkq2hSVpQBn+FX/2hLOh1rctCR4Z5IHpEauQJebQpja1yFc7cwgSxNIZfXLAAgnb 7doVOOC0RNm2Z1uaM1PPLyFZUSrIUSfeHx2XLuxp5rbxjk9+/tCEsDE7Ba2ZaXl1FWQsdlEd 4SAodaLjaVYBxsV6xewq5W2obTgvKko4CDMbs559eIv2ih2X0nnpl1aQlEk5kK5H4THiurY1 J0qGYI/OZ8TR5E1rW4lhopUEZKVHsMnEZo8F7+T+sbKXsQ0dreWG63LTKyQG3ATj7iO6vQ1W 35jRmUlkNDwiEqGAcjyiMGsVpoOHtZamnE64z1DyaHHCppyTeBGe6vKQfsOY0LuLm3cckx7n pH8pE5Op+owcs2svBG3uO0KZZsFam/D3D3jfJGcPVTC6kDaB9z2gTMsJZwjgEjPELtdFoVs7 FNBWzJgpKVs4ccVkA9oot4D1SrDy0kABQ5IgpTD6F58QKSecZ7RAQWXPGCiMAiDkO5OwkfaB ksEPXfCmGh4WM/SPksK2kOKI9OIpr0lhfyyGlFAGfvAJkbSAhH6QpkCVtFbYcOTg9oExMJeO xoYz6mBaLDSy4HAQsHPqBHvyxJzgffMAUeeG24nZ+I/SPPl/DQUoV685imX3PPlw4cHzfePH 2EhO1hOD65hbLCkb2l4754zBnhhaAlvn0ziCKPFsEL3JXtHbMFtlJUN/8fBGYOBTCZiW2YeC sEH09TBsnKuup2p5I94elgoNLeFBt1A49oE6G1gDZwfSC+xAtUurBUHEjOePXEBbpYcVuQR3 zxDOCCpEk0CElAzCZ6RbU/4QTjMS+LkFDbPy/wC7HZI7R807LoUUhvJPciIiAylClBKQE/nH riMAhByQcGIQB8undv2AH2EBcacUQcDA5yYsgFTO4lJGRjvAPlEBvwijIV3PtFEEkxJIaSG8 j3/KCnZVpQKGk7QRziKlkgTM0lmZQloIGRzuEIXKLuVhx7JHtClEIImaeUtKyoHdxhUIm6O4 khRGUn+b1hijgpsrjVFptq7aMcbVl47Veg4i1q867LaK1fxJoISinLICeCfLkx4Pq6tqzq6b 6aPzn/EXnnp3XmdDhG4dlj1yIz94Ux/zhGul7EMfI40JUuupsFK9v7wEk/eO6fQfUW29CZdx trJcaQMpPbyDn9cxg1vuQdP23JrZ9dXSddaZVlteIS3MNBJURnej/tF7talLSQn9nDjuCox7 borvpEjl6r3jjTdRZdY3vyKgr/pJ4hcjUOlt8rlnEn0IjqWMwr/2kUh7cpSHU8cYPeCGtQaL jLjq8+ue0DZEHFvUOgFsIQ8oHHqO0HS99206ooM5jP04hbRb5ATd4W8h/fKVDgepzz+UGqu6 hqQhPz6cq9SYiVyhYi4qPsDX7QaO3g+aBMVmjPL8MT7J57FUSxA1urUmWdAbfaI7bQqPf2rT 1vECYaOT2zxAtEBPzssHBh9Cs+oVAvmJZIDSikq9QTCnEuwQ7MtElt3aEq7DMeNbGD4rSQU+ 49IFrFyxSksKSFE+mMZgoPArLSlce8AkU+QxJYU1lBG6C0pWFKAVj0zANFgtq23ASM+5jx1a Eo3LRndFWyWAbCXMnd39RHqZgDLXt2MSyB7hqkt7AlQycf1gCmkJG/AKv6wUURiZbyDwscwJ LiGik9yR7xpUShRK7C9hQGCMgR66lPiZaQPbJiPDIehhJQAF5OO0KpVlHhlGzGfSCfBA4yjZ OUp/D3gK5FO8OJRjPMCn2IEzEsELUnHPpiC2pNSFHxD37EQRD1yUPij3+8FpbeYBU6nP0i+5 Ae0gBxKe/wDDHrTCHfxrAzEIC8BgFS2kk475PeCNra8kHn1iEE7smhw7y9kQNSEBKVBkexHv AydiBS5VK1eKzhIPGBCaYl2klSCnnGMiBiQRTMgH3ENIGB7GATEi4lweGkYxx9YaiFP6vv7d QaOy4AB4qs4+32ib6vVpymaAXI6y2R/7LWncMgpynGY8D1nGtZ2NL9NH5zuuGdmKjrZOPPd0 gD7xTmF/yf1jRTzFBPkWUQtIfaW4B5VA5947h/D8qkkdBWTMIUV+G3tCOTyjtGPW+5B08RJy ub8XVuh+AlLZUtzCgOB5D9PpFwuNBUylt5IQU+0e16HnSo5eq94GcqcrRpJ2pVN9Lcsygrcc XwEJHcxED1S9Pcsra/q9Sm1JVt2LWcn7cYPb3jqSnGOGzOk2Ht9Tugk+rwZTV+hBScKwqYCV DnHYj3MTmjyiK1aSb6kX0O0dbPjiooX+6Uj+bPqPrAOcXwyWyRcaz6UF5clI6kUl5xrO9mXm ApSffIEKW9V9MJgfNDUehIJSCA7PIQc+2CeIDcn3Lt3DJfUaylgvLvejOMZ2lxE80cHv2zEl pU/TarLCYps6zMtKOEvMOBSD9j6wcMlWsg/wUeJlpGSQDkAkwXLOuJdKgOc43JPr/pFyRSyf F55SCoKOAeSCeIMLs0lQUmaUE4/FnMA+Cz5M3NNrCFPrUE+pUcx6ioTWD4b6k/8ATk5hTt3C sFzVYqWwsLnnOeRzkQolazWXWw2Zt7P1JAxFO1iWyE0m466yw5Lv1R7chRA3K/h9IUou+sIC Uoqa+CTgq/8AXELB7hirvuBtrLc+cpGcH1+4j2W1BuJTQb/aB54KR2H1gGXYVJvy4vCyH0jH 8WM5gheo1wulKHfCxk845I94HuWw16+q0uXw0+gH+YJ/yj6W1DqiUYU02rPBUe8WChWzqbVe UuSjAx/Fknj3j0aj1BavFMm2r17kAwcURo8XqAt/CzTU4Jzv3/h/KAt6lqbUGlyOQBjcDGm2 AWCb1J/e5+SUpI9c8w/2rdLdyVBUgywUYRuz7RUlZEvckLTkkp0yyVYWOMGFLbaGyco5HrC0 7lh6EK4Kk8Eekeuyzri047e0CQLcQ0VFKE5UDgwNuRQ7lJwD7GLuQImGyh4BSBjvugqbSgtJ 8D6/nDEQC00pxQB/WPnJfwXcbuDziLIep8RwKKDgAYIEAMqy42ksjkcHmIQISlCtzTackfWD WZZeQXSMDnEDKzIEvI2AqwAn2hL4DJSX1Kz/ANJiQ4II5AonplyYbT5UKwRCh5h11pQ2jPum CIUZqq389qjRpFPmUVKUQOcgdyYlnUNKrpnTfctQUrgSJCAT78YjwPWM61nY03sR+crrIfce 1xq6is5C+IqfMxGun7UF3FlOQkTjbLmFAK7D15jtj8NEKqejLSFgFCWWlIUr+Ly4/vGLXcoO nwWdcko5Kav26ZdBQj5pWcnGR4auM/8ArtFxOMjIKgVLPJKo9l0J/wAIjl6r3jBrHJuzmj91 NNt5/wDZEyfKeU/uzyPzxE46UnNNrV6A7N1MvWz6c7LyFsS83OL+UbWpzY2ApRGOVcfeN9Wz lkVHjARp070e/EZ0zrjVn6eS6WJFapAzU1Tksuyr5SSlSTjkc57n1Bhpt22lW/8ACcrNpIdB VSbVnJIuN+7S1p4/MRnsuYkfwwvp8kdTNOdEbJorulelmm9BSJZqZeq8x8xPVcKA3FPkSA8s ngZJ5Ag/V6oaK6H9b1n2ZdGn1Ccpmp1M+XDs9KtqbaqDLyg1gEeXxAvbx/Ft9Yi9Ksy19gdg 9FGl+jesepevuq1Npk7aZZbepUrUEhxqUaCCt5akEY3A+QeuEj3iHdMOpDGrFgzt+02gs06n ztYnBJSEujYmWYS5tQkJ9OAD/wDNDqC2ysSbuiMda9ddtexGrgkNRpui1CUl3ZiVlJV3wvmF AclR7LCf5YX63V2fb0X0+n2r+et5qt1mmydQrMsoNraZcb3OLB7YJ57cDMXUbW7JUEipLu1s uyXsGQcTqHVlGmSVWmpaoyCdxqq5Wa8Nvxv+gjgq7ZH1iyK3ceqCeoG1bBpN2pNFuaRlLmcU 2eWmTLpLsuD7F1XcemIzqcm7DJQVkB6pNY7z011fo7VrvqXSk0lU1OyjeckrcLSFZ+i1IER/ TXWrUh2hyE1ed3pRMLo1fdcW9gbZuU2+D3PbnBSOeYCdVptFqGUL6Rq/qNM6m2iitX6wzSKp LyKVS7bKShx51gFxCiPMlzfnAOR2hPaerOs2pLFFk6VqJSaHMSlDFWmpipN4l6iv515nwuTl PkbB+4ERSkynFJkt6ntTb707qdm0/TudLDlxOvNuqRJ/NrUENhRKWxzwTnPYDMM7F6a6THUV UNFp67KR4dHYlyubMiWG5pa2PFP7wkhIJwBn35xAOck2ieXG1xLaWrGvt1Ui6W3K9Q5SqUCU VVV0+alyHm2k7t34TgoARkK7frCqj6sa7zNt2fP1KZoU1O3nblSuCURKMqQptLEsl5tCkjjK uQcdoUqsuWRwQ3nqovG5LXauOxqhR2ZOoVanUaWq1YyJZt1yUW++VY9toSD29+8S3RDXW5dT bgo9ErchKstT1vO1Nxxg5w83NKZODgeVSU5H3EXGrulYqUbImuqt4O6eaa1y6acGlzdMknJp qVdUR4xSM4yBxEDlNe7mmZEzq6NKJBueSoCU+cHD8l45UPQkK4+0FKdnYFRE1w9StdtbQW0N fqhb7T1Lqynmqm02ohcgvctDWD6hSkpHP80Smuawz+nOgKdXb+pPgziZRt1VLlV5IfcOEMgk e5AJhkKl7uxHHAspOt2nrdm0m5b4vKkU5VWbUval/wDdb04C0D1yDwc+0RbVzqWGnl4UihUu kSc9T6nJsTyZ4P5U4288W0+GnGD2zyewjVvVsC9pa7DJZTyQFdtyexia6SSajVHptCidqQOO 4zDantBLDTLpJ3q5x6H0g0MpKQpI3H0GYyosGyDv8JRwR9YOdQ54flI57RO5BIllbTm5Wc/S DkNrU54h9f4Yu5dgE7LqUoqzxiCwwnwjk5IHcwa4uUAHgtkuFQ+iTCaZeUwUreA2iDIEzdZp dMZVNzs2yyyBkuPLCUpHuSYprVH4gfTFpc69Iz+orFSnUEhNOo3795RBII44Hb1MBUmqauwo xcuDON8fFzuMVpY060vbRLAn97WXtqlDPHlRnGRFh9NPxQLb1OuFi0tSbfbok0+QhExLuqca UsngHIyP7Rnp6mNV7bDJUXFXNY/uX2i4HMj6QmcDbcureODGmIkTtIalZVKJNGEqVnGeYb6r cstT3PB2J3qEEQpm7nfm9dKOFN5CJZxwAdiCpI/9faJz1ZqRLdMlccUgBPy/KV5yQY8B1XOs kdfT+xH5tOrKaQ/rXWlNIIUh4pwfpFZfMTH8sbKaW1Bd2KqUrfMoVt8yTmO3PwuXRNaEyK22 8JRLtb0++QcY/Qxg6hyg6eYlp3ols6lW24Vo2fNnOMp7pVwD7/eLW3bi2S8VEjBXmPY9Cd9K jm6pesbb9aed07uOSl0qWqZpcyw2lPJUVtqAGPXkjiJd0bXhaln9AFo/4uU1Oil21mbpKylb 7nh7/ER4R5J4xtx9I6VTkSr2KyuL4qumtsWtO0XQbpuupmdVlDbj9KVLybS8YC1bE+h98Q0a QdYWhE/0HHQHVfUWZoV31miTctNJmqZMqRLzDzji8lYTjA3JPtiMfmKQVncIl+uWkf7LqNb9 7nTu8avbzTa5ScmGJgBbzSQEuIQPwrOBxyMxnbrs6zKh1cyVDuN+wDbdXtSVmfBmGHFOLWoq S6haR3SULbyIGdRNKzCirO7Ne9fOrrVV+HfQ52RvqQcn7gFJanWZWbSt2YDrIcWMA5/EOePU 5iEfDxaX/wCHaXa8MjbUZkqSfqodh+o/KNVF/vMi37SxtVpaVfkpNE1RKdPLQsqYanGUuLKu OE5HGYP1CkZFu2pJuqW1TajLpcSpTM+0HGmcIyFBB9R+GNDgm2dahRg3TTXI0vyqJpukUmSt G3EyNRp70k00iWAQiXKgpxsZBxuUrP6QibrFPRV0XA7bNOcmKXJGUkX2xhbDG8I8I47DgHEL cV8G6OhpVUF3E7RqxMNz1Xsqkzc+6gyQmXQrPhhYWEj3G4ZgFXsrT+6Z+XtO6NNqc/KpmXJl IUnaUuuYUtX13EcwmVOLeULr6KnSpu3wON02LopSr5kbkq1ryn7XYDbbLyR5WNicIJHYHA4P eG28tGtGV25ITdS0plahK0pTmFB8tJQ2Vl3aUgYWN5JAPqYry4owQoXlFS7kgr8nQ6ki29QK rawcq9NKv2c3vKTLF4bCM9jlIERa8rD0vnbtmdQLu04n3KxMNocqUz86tpIQAG0haB+JMBOC ZpoaGNaPIisaxNDNMqnXJW37VnGZmtMqpM68/NqdWZY5JbBVnCeTxDtS5ezqI1a1xCyZ9lq1 ZR2nUlL7oCflJlGxad2PMSPftiM2xXsaZ9MSaTYyUrSnQi2LQo2nz1iTgpFPqP7Zbk3Ht6S+ tBbCiCCDwePtCdWkGklOqMj+z6Pc9IctqVLDTkjNlCQ2twubFj1BUYvy0mmhc+nZ55HzUHSm yddqYLouCtVumtSEu5KPMSU4ppE03gEoWBwrOO8eUrSjSy69RntRKSqs05yTcl540ZUwDKB9 uXDKZlLZAwvwxgRHC7Mf6O0W78OxHKbodpNJWRU9Pk3ldMxQ1Kbm2adU1ZDSmnd4Le0YwVHB 7xNdRJGydTrHTbF1Tc3IM/MJdbm2msql32SFoIB4yCAQDDYRXA2p06cFcXaZ6IWBb9mNUZyj t1Rp196eL1UaSXFOPK3rOBwOccDjiEOovSzaeo13y9yzdcmqfLolmJR2nSSE7HWmVlbaBkZR tUonyxq8pdjiydm0WGJNDLidxKlEYKj3MT7SBhtpMyCM9gQRDKmIi0TkshZ2oRx9I9QwUqCM xlWQ0j52XdW6S0Rn6wehBUAhY5x+sQjB+GlQ86eB7wFxtJUlaTgDsRELYQ+wdhShe7n1hvqd dodBkF1KtVSXlpdH4nphwIQj7qPAhi4BKD1W+JF0u6bpflJW8jXp9olPydCbL5yPQqHH9YzX qz8WzUu4W1ymltmSVGY5SJqqHx3j9fDGAPsTCa2ojDEcsbCnuyzOGoXUDrRqq6XL91Mq9RRn iTU74cvn/wDppwIhTScDaltCE54CRjMc+pOU8yNCSjwKpCh1WpPFmRp77ilfwobUr+wi1tK+ jrqBvCcanaBa0zIoSQoTk0kpSOe/PpE08ZOV0SpJKNjqbpXRa9QNPaTRrqmUTFRl5Vtp99sn Di0pwVc88w7vS5cV4D2Y7EDEJZpgoTuTnCR7xHa7REzaTMuknA4I4giIqhNMVIa3yqFTCnT4 G8bj28wGImvW2r5fpbrBWMby2Bzj1zn8sR4HqX87I6+nXpR+avqZm2prWOuvNpyFzSsE/eK+ /wDpjVH2ojeRfIlKZlPhjPI5jtX8J1fzOg8ovxsn5RA8xIzgnHHr/wBowdRXtG0fay3r/wB4 v2iTBbR4bc4kqyMbk4UOPbv/AEiz2Q5lOchJGc/ePYdB/lTnan3CiSQkLAfQPD9N/wDF78Rj 7TJZpfX8KeiY2NuTs5LrYaWpCHuFEp2dh6q7dxHQrtqcRcOGWL1BtX5UNRXWbv6q7esW1m0l tmVlBvmmmhwFKbHHJHYj1inabrXdM7Rb20wn72cualLkFOSE/NMBK0ONuJIcR3ISpIII9Mxh rSabGRSYi6WL+m9F74p9/XDbzM1bFSnBJzb0w1vaa2kEqxjB27gSPaJdoDVrHX1nXFcVRnJJ Vvsy1QmfEfQFtJQlwFJSnByTkAfcRdJq0blTvmxYV3dZOgc5aNYlNPrEqTE4w0r5GoTdMC5N x5J4SrCdqSe4zntFhdFF/V7UzRVu47lMqmZ/aMy34co0Gkp2qA5SABz3GI6NOalUwJkrRsx5 1q1F0isKYlHNT5qca8VBLTsu04pKUk4PmSOFZHbuYHWdZtEazbP7WrNaWzJU/wAHeXEKQ6PF QS2nYeSVpSTj6Q5yjdo1U9TOO23YCzrJ0+ydLkribvJlEjTZIzbJeTtSllxWzcAO/mGOPWG+ r6hdNtAuN+0Z66zK1VttQfk/Bd3JB8+5RwRn6d+IVJq9jRHqFWnwI5DUXpuq0u6zK6n7VSJV NvLTvStAOAMgjkHjgcxJ6CLCr9Lb1EoV0ImafLhTiZxxzDScDzEk9seoMBi5dbqM6kWmhBPa wdP9YQxddT1Co5l2V4D63gWlkehV2/7QtqmouiFeotPpo1Po7MtVXg3JIRMjE8pJyUJxkH8J yPygW4szRryTTfYWXDdWnVa8S15q/ZGWmZFQcUlD4QqX2e4PbH+UN1Mo9gXzNKp9A1ak6s4W VJmm5abTMLWjcCArHPccRTs8XNVDX+RHbY+maLpgu4FOvXvTBNyK1LmGHZhCS2kjnePzjyVt imXZSW6RTdSZSqNSRbU2ZZaXEy6RnakpHbOMRn23kan1bdaTXAI0C0K9NzjYviUmZmhoal3z LnyyiknISr0B5AMONSpdJqU9Va2m6ZBH7TbaaLpcR4LZQn8OexJ74MW0hcuo7nua4PqXb0pR 7UmqRULgYLNRy0X+yDvwBj7nECs+06dbMxMtt15mcceZS0WnVgrTtHsOYoV+sThJW5dxqk9P pxynJkn7pZfaYQWJdXYNha95HH8ROfrCyb0+DtrTFEm66hYeqAmvmX1AlKiAMZPrge8Mpq7H 1upqa2pE2SEq87WAEgDPfjHcfSDCwtR2FoA+p7ZjYkeelyeOyqMDKQc+ueTE70jlz8i+sY/H iAq+0iJntIOzsMekGJa8qVg5I7xmXwMBoSnapQHJjx4tpTlSyD7xZQ0XFqFatq08z1yXFJSE unOX5x0ITx9TGedUvip9NNjlyRt6tTNxTSchKaM34rZVnHLn4RzAznGGZMtLdwZl1W+Lfr9d bztM02oFOtiVcyBNvn5qZ+mE8IHvnn7RnPUbV3UnVWb/AGpqRfdUrTqTkCamVhpJ+jQITj7i MVTUubssIbGmlyRxt1Qc8JCQjjsniJDaOlN/3+6JW07SnZ4KyA8w0Sgn7jgfeFxg5u0Q7pF3 aX/DH10vN5D1e+Wo8sQCQ8dzmPXgev0jQumnwmtOKVtmrwrU5UH0/wAKVFpoH3xjJ+0bI6W1 nMXKr2iaAsPpc0n05ZS3btqyTCu5caaAV2x+LvEtaoUhKOBMkylI9Y0qKjhCW2xV8shB4IH2 9IAtvxFBeCQOOIKJQnnNyWjhPI9PeGyoqaMitstjlPIz2gy0UmgJOv6g2fMlhCAM9vN7Q8/E CqHy/TNOOBCkhbqBnPpzlOI+f9Rf8ZL8nYoe1H5tdeX0TmpVX2ZC/mF5B9DmIR8tMe4jerJI CXI505pIIUkEAnufvHZr4RCkHRaT3N8olQFJJJ53Hn9I5+vV7DqXtL01Tcb/AMUUpxwFH++t BXpjzcfl2izGSTsbShWVj155j1vQHfSnO1OJBwUGFBbSEjaQO+cY94yfMaY6iWT1cK1hFvSE 7TJaffdWBVJeWcWFgjG1agTnPp6Zjo6hO8WhVN4sNsxpjrO7rlM6vnRigXHITc2t1FJq9ZlX WloKjjfhXlA4OD7QdTulzqBvLVisTtTtG3qY3V5eYQFSM8yJOTUpIUEjB5SMcbfaMUqUqjsh qko8lwaTdIdTtDQWtaLaq1qlTAqdQXPyk7KOBYYWUAA/iJByMHHpEA0x+Htq1KVqsGrVuhfL ztKfZYep06FneVJUhK84xnZ2/WNE9M7RsLU1cW2tYPWHZ+hle6ZKZ02yVVlqh4hXcapplLmx St+EEnOQeBgdh3i0uhvTS+9ItFv8E6o285TaqKlMzHyriwohDhG3zD0ISIfQi997A1HuJR1G 2LWdQrDkbet1Uq3Ny9akahumFhvCGngpzn1G3PH2iJ6v6O3zXNUK9qvY1Jo0zKs1qj1eSpM1 NhtM23KsrbU2o87Qc59c5jRODY6nRm0mkRrUPp51k1HuSl6qVChWtTKjSacmYRb9IeK5N94T ZcDG8pGMIO7kY3Zh9ptgaoDqvr2tVY09Suj3TOB5TqakgsyqSylCipojzKBzgjgxndNp7i3R nxYJqOiVbasnVCUb01kKpN1i5W5+ly7D6UuolUpRuW2seVJCgTs7Q46XWDqTJdOVwWheliU5 VWnBOfJ0BLpZL7KwQ34ixkBagcnjGRFOLuC6U4q7RALU0Tvid6edTrOrekEvIOzNKbat5E14 RnVvhCQrcE+UAchKuCfaFvU3oVflwVcyWjmnFGXICyJKRW0Wggys2l5C3flu213cnKie6STC NjtwGqUubBtG0Gvx3qkl77vOzGpq2pq731TDCmAtSpdcsNrrpz5mN6j5fdI94m/S7pPL2BUr 1n/8As0d2auaeMipDASp6TKwW8HklGAcfrF06bTuypwkuUVtofonc81rxRp7VjR6Xbt6crNZ M5POBTip1gnKA+knjBA2e4Iiw+jPTGWsbSkVOo2T+za5OVCc+ZLrXhvPITMOBkEe2zbiKjB3 vYFp2Kn03s6rS6tYLSl7Ir8tKztJfQ/WFoPzKpozAcQ0Afxq2gneP4RjiCZex67VemicmpC1 HW5ig15S6dTXpRY/xGHZcNeKpvu2W1E8nj1hDi28EjFtMuW0bPqNOmtN9F6vOqmn6BLIq9Yc UrKPEQra0jJ785Vg/wAozFG223M0+6K5MWlS7jlrham7jcrk5OMTCZdySU0oS2xSvKfMSUhO DnEVUumiJCnT+xLmlNJNUVydDrltztAolHrNGbeeW+6/OtJCllJ53FwA7kjsFjMXLpzobR7l 6d7fs2+qzVXJqbWiszsw3MLbfcml/vFJUrg7QV7dvskCNFFN8gSVi3pKXbk2WpNo5CUBCQr1 AGIWCXYWgtgbcemY3rgzMAlgOr86SPpFjaZyTLVE+YKwCtZOfWE1vaXElLDTS0FROYKnJqWp zRmJlaUNo5K1HAH1JjN3GGYNcfim6DaZViZtm0w/c1TljscbpeAy2rnhTp8v6ZjKmrXxUupL UCYmJCy1020pRwEIMqlU1MDnuVKwnP2ELnXjG6hlhKF8sz5d183vqFUVVW+LyqVamVnPjVGY UvH2H4QM84AhvptMm6i+JenSDjiicBMsgkZPbsPWMDbm7sckouxZ+nPRV1B6oONfsKxXmEuq wH6iSygDPJJx2i47f+EdqxOsB6p3jIyylDllplSlJ/8Am7d/YQ6GmlLLwDvSK51+6DdU9Drf mrpn1IqEjKoU466yjaWgBnJHqI310I2ZQv8Awt2bUU0tgPTFPQ8pSAPNu55I7/eNlCn5TaYq ck+C55eSZaO5CEpAGIGpthlO5xzGecDmNLA5I7dGrOnNiS7k1d95U2mpSCczsyhvA9+TFEak /FR6SrE+ZlqbdM1XphjJUxRZdT27HqF8Jx/80BKSi8siTfBe9jXC3f1nU285KUcl2qlLomUs PfjQlYChnHrgw8uy+xoDOfXvAt5JYaKrcEnLPCTUtPijsM8wnqBl0Up2bfT/AAk5i92LF2yU Zabv7V13nnUoRgNox4Z578Qb8SWaDHTMkNOFK1vklR53JCe2PQc5/KPA6531kvyden7UfnD1 aU1M39VHkKACphfr38xiNfLp/wCbHSj7UC1diyTbUgpStWArnvHYr4OQS9ow2ltwrIlSNxVn BC85/T0jBrVhDqfBf2trfylYpU4N+DUJdAUO4JcAyYtRDJRKttqGVBOCpJwT+Ueq8PP+HZzd X7gcu2pONgSSlQV3789oqTQ+k6GWNrnqlqP1GUuoTLVWqrdEocizS3J5MrKL3l6bCU5CCPEH mHICPrHV1KdlYzwZBuoCr6UURGjslp3Yc7Vpa0p5uVuh2Vocw2moNNzeC6o8FxKmfOCCc5wf aLQv6mdCWo9MqlBfkqrImbq9XnpOq243OSjzLKGkuyzavKQUrGUoHoRiM0YSuG3YhNxSnw/x q9pJStIKdcEvS5y42mK+KkZ0MqkFIwVPrcx5g5wpWOyzzEwlrr+Hhc2ply2+3Yb9Lp9vUKoP T1UlZR+TZfeS6hDZlk4yt5KVKI75CcwxKawUTWz7B6Jn3KhQrcuKgVREtTKZ8k7OT7uHluNq 8VwlfqpSASMHaVY4iO9FVTrlb02rkxcc2t6YlrkqEsjctTiG20O4QlKyAVJA7HAHMaaG6+QG T+/qJUasphUlJOPIRKvtnwxnClAY/tETk7RuaU8RmrSD7ksw7LBTKR/xmUg5SPfuRGySyer0 kqf6ZRfI+0Zb1HraZqXtOpNSU5KhltlRKlIVuOFKPpwR+UM81Sq4/QxLN0WoF+Sl1tPulJ/f KLwIwRweOPtCZLAVFQU3diStUudfYafZp0+iQM2pTQmW1bvDCRwoD25/WF1NlHFagNPSbE8p Lx2lD2csAJyCfTEJaGajY6bt8Ar1aqrt7LWyzOulr5ZCX0KPhIBUcgp9SR6+nMIg7MOUKeea nKj+0wVmbCgrYlHi4yPXO1XGPaBsVGMdkfwCrzknLzlM/ZFWqBpaXHv3kyVo3DcMY9/zgyVq JlLmnl/tmcQ0th4IcWV4SAnKSU9hyByIjQbpQlGzQ8aaTs1UpOapjk1MuIxlLqlEo+6VQ2PJ qEpTqtMv3FUC1L1BEkFuu5DbeRlQ9u/pAWOdTjDzpxa7jvZ1QfetGcm1VR5CW3XEInlZ3qSl RAUf8ojkvcFefp6UO3IoM/NrSuac8xbSEFQGcevAgJIPTQjJTTXcX1afqqdM5K4WHC3UpsNp cmAjKyN3Iwfcf3hHMXpdv7ARPKr7vjNNPEZ/EghxKQVexxC2hukoUp08ruz2oXTckk/8lJ3K XGUTCmhOtpSN6Qke4xC1qs1Rd7ylNVcxfllqShKkNgbyU5OcdufX1hsEDrdLRhTe1dmWBKsT DP7pxe5HBSod8QrQGifPkHGBkxpR5NhrbXlCT3HYxZ1gSCGrcl1qRjIJMKrcFxF9vTJfbf8A EBwlxQGfvGUPin9SNU010/ltNLUqPy0/cSyhbrasLbYTjeR9ycfrGSo7J2DXKML6V9N2r2tZ TM2bZ7q5dxwo+cdSW0Eg4Jye8XKj4UGtDlPM9N1ynpfH/wABCFHP03f5xmhp5NNsa5JYKwPT Td+nmvdp6ZahUsBqt1eWlC42ctuoUsBYzjvgx1B0y6SNGNOWf/y3Y9OYdP8A8cMAr4P8x59I dQp7Y3fJKjyWEzQKVQ0FUnJtoUB/CIVSwl38ubfNiHrgVcj+oliUa97fmKFU5Vt1p9JSpK07 gQRggiCdK9OaXpfYtOsmig/LU5oMtJP8KR2H5QblgrlkV6gNUJ7QPSW4tS5yVTNrpzCnZeXJ wHV9kpPtyf6RzE1P69OrfUecmJeqaszlMlHVYEnQGxKoCf5d3Kj985jPqK0oYiHGK7lPV2o1 K4pg1Cv1KZqEwoYU/UHlPKUM55KicwlLLrbK0My6cKRwnGB9+0YacnKd2aXZJnbPQOXMro7b ja8KWmmy6SQMbsNp5iTPB5eSnAA946LeTKRytWqxMT/7WYVueHJPpHsyw5NUZxkJ3HaeMxV7 oiKPsRtsa2VFtsp3NqbTjtnjP+sNvxRZ5dN6d2VZCQ444ranByAgjn1GDgx4PVZ1kvydan7U fnNvtXzt1Tryjje8sjnPrDT8p/1x1FhIFoPl3Wy4FKBIzxHXr4MDyl6WpbT/AMMS7nf1O4Y+ 3eMOuxFDaTwaP13AcckFFsHZOsKAAyf+Inj/ALxbTcuFNICgnJH4TnvHqvD30Gc7V+4GyHEI KEEZBxj39YqLXux9Uqre8mrT11/5O4Q1KTykKARJeG4lRdByMFSAUnHf1jt1Ytr0maLSeRNP L6w7OqUyu06kTIJbLUuhT6XNqi6kFwIUMY8MGHOYmuqyadekJ2qOzcnLTr7fiyZbZXOpBHhu K8uNihnIgFGqmW9rAXRd/WAyueta1LdlDMLEwGdrDPgS4S2ksr8UjcsryoEY4xH1Zv7qkoNL n7lkNNmZ6WZm0ysjQ5ptp1/atgK8bdj/AIfihSVZ5/DF2nfgHAO6Kx1O23cdSrtRsqhTzNOl 3VsSUlTW1tvgIygJI25JVxgj9IuDTBu65izJOpXnKyEvUZtImHpenMBhpsqAONo7Edj9obTv fJeLIT6lsTTbMmGRNKbPiK2yjhSoKCTtJPqAe49REbRPXO1PMrVOP+A6uXacIzlpRAz9geYe +T1uh8p6eKfI7WjMz71zSsu5VHnVOmaTNNKUfCZ2OfuyPqoD+kJJmo3JO6hOUhc/OIYenTKp LClJbba2cc/zcc/lCpC4uEas2/gDIS1enbQrtXfuSopekJmZS00HeFpb5ScY7q5hJX6ncVFl KZ8rWpt1T8p80skAhCs/xH2GYU0NpVIV5OLR8LyuL/ELsyirPOlpSg2wgeVICMpIOOTuMHLq NfatCbuKWv1x55uVRMPtJQncnIzsKxz3Pb6cxLcB1VClZJB9SrNw0NbdLVV8uuS8vumn2Unw vFWAVYIwOPX7wiVqFdFtPoepc6hz5X5llyZbA/ehKygLBxgpPH5GKkhlOnCpFXFbFy16UuCU aRPywlJhCENhCMb1KRkg/wDUFZ+nESrTttFwUCXcufYHX1Hxv3Y2nBIBI+2IC2Di9SiqOYdy c/7LaElIl5CqsFjspIIA+2IIOltuLS7SGpmX+XThW0IGFEwDRyFWnHhhjmjtJS2lt2sSymiQ Uox+DHaAjROguJU2qdlHEO5CkqSDkGBUblx1FSHtkAf0Gt1Ui3JvJkVtA+VCWwAmElF0dpMx POTUu1LIeYcLKXFDlSR6wUUHLV1pra5YJKjSh4Y/9rMFOPwjvBFY07dpdPcnVzrbhb549oZF 5MbI+0Nq9pTwDFrWlsNtMFBzhHfMBWxgKIK2mg9Krm0rBClKOAfrGK+o3p+qPVJ8QSmWbUEq Vb9u0dudqC/5gp1QS0P/ADEHP0EZpRuwjZNjaZWhp/QGKFQqayxLtICUoSMAcQ8tS7Bc2NAK GOINLBV8leaz9N1v6o1uhXC82hmdodTl6ky+BylTSwrH5gEfnFirdMgwDtwEgkxUmlG5HLBS epPUlWpWsTFItenslDR2l98k59+AIFojrTdly3em37ieYU282SChGClQPb9P7RxaHU5V9V5K WDJCu51Ldi6ltZSFlOYMaQXCOwAjtXubSserbRer67aLVrTalzZl3KkwWkuA4wfQ5+4jF1lf B+v6fUf8b31LtDGCmTbUPbt/3hdSkqnLLUtpbtj/AAoNErVbTNV5U/U3m/Num3fLj1GwAf1M Y266LAtjTHX1dq2fTRLSiWGf3SBgZK8Y++PSFulGCVg1JvDOp2lbP7O09otPCMeHIsp5PP4E w9zcwD+72c/3h0hYhmkuIXsbH1hLU5VLFPceQrjGSIGJCjNLpJc1rJWamlxISmaSnGeThAH6 dog/xgakzI6IU1lobfFafCxnH4Uk5/rHhK7vrJfk61FelH55ruSmYrkyG8JIcVx+cNfyMx/z h/WOsnglsh9NaIf2HHP8JjrP8FSppVYqZRQG1KHkgEeoI9PuYwdQ9qCpGp9cfmMyZATkTLOP E7f8RP8ASLfkJVDsq2EZICQBk/1j1Ph3+XZg1nuDk05ptXilePfAg1qnbsPty5OeOx4j0JjF gp5eRtDfpwcZzBjNN3tZcaUFJ+h4glYgYxIuM8nJ2+oHOIPcktg3IQslXI47/SLdirAJiUdc 8NHgkZPIOcYhQzIqbaATuIV3A9IpWLwHJkFK8xayU8Akdo8RREKQtRkk5yDnHeJfIyM2uD1N Gl28volUpIHcJwYINKY8rhlRvB3ZxzmBbQaqSve4BVHaCCy3JoCVklSf5s98/WCHqHKq4VIJ 2fgOU54/0hTZFUkspnybYkVEPtyTYH/lxziCWbTpUu06xL0xjwn8hxtKMhYPvEug/wBRUeGw 5615ab4fp7biXQEKJHJSDnEEotCkgfLopDXhJBRsCeCD3ERtXCWqrRwpAxYtDRMIn10vatsY BOYMkaYiRbEtIteG0n8KBC2wK2oqVl62DQF+Ktpt1W88kAx6ymaaUpAeUFc/izmBuZg2ZM6p patzgPO0AnvBGKktKXHHHk7R6Z7xSeMkBS/7QWguPTL5KxgkLVCiWfqJdLTcw4VeoSSCYIgr YmaqwpIRMvjb/CVGFj8xVJprw3Zh1aFD8JUcGCTKsEMSrpmW2vCUMkA5EWtIynydB8NhO3yc AfaF1uUXEIspCTbyPCSRnJyfuYLpWnlDpNyT93SsogT9RShD7/8AEpKM7R9huP6wm+WW8Ipr q11nvCxkoo9tOeFuSVKeA5T9IinTP1RVNqcmJPUe4NzWwrQ88eQfbMezo9Ep6jpSq01eZ4Wp 4iqafrD09eVqaRO5fq7pV139JWjaEn47b7obcfdOOPUiLoq7Ti6Is582zOB9o811TQS0DVKf Nrnqun6+n1GjKrS4vYyBXmHWa7OpQAcvLzu7nmJ906WLXp26hcvy2yWlwRuWCCo/SPDdNpye scrYJQjeoaDeWiWlSt1eEoBJ3HsIDJTSJ2Qbn5RQLTg3JUDwoH1j1fY6QclxLiPCX2MEuAtr 2/hHoYhQmnCkMOLU4BxjkxyS+ITPsTfV3UpZTrSmmZiXQEtEK84UnI++QIXU4QS4OpVoMKk7 XpyCncRKtJ/LYnj8oXTS5dZ2bSFY9IKQIjmEhaws7kkevaENemDL0t8rTuTtPaKSwTuUxoHT 1uajXBWJopSyJpQTlWd3lSOIqD41M+7LaTyMpLLJQZZ4p58o47iPA1f5yX5OzR4SPz/XAgrq T8yrjzqhu8ZPvHXQL5F0mwXcKKPN9I6pfBRdal7WQzuHibH9u8+gwf8AOMXUF6UHTWDXPULO NfLygmEbdk5LqUD6fvUD29zGvada9KFHZLMkyCE4VhPcx6Xw+7adnP1nuFLNqURxJD1PRkjv CiQtGmMhaRKNqSe3HaO9vMYczbFMCiEyKODzkd4WN2vTAorVItfpFObJa4obtqnFvyyTW3+X EHIt6ihASKa1kemO8LlUfZhWR8bZoimzvpbQ+uIC1atESrIpzfHbiBVRolkDZtekhJCpJvaf TbB3+GKWGgRKo47cY/yinVZLAf2DRZlrHyCNyTjOOY8ftWlvshJkG8p9cf8AaBc2iHirUpKm fNINnHuI8TatEDZb+QaOfcZinNlhbVrUdLmw01oJ98QebZouMCnsn7pib2Sx6i3qEtAZ+QZO O3lhPMWtSBwKc0n32DGf6RW93IGIoFHLAR+zWzjuMQndoFH3gKkGs+h2xTmyj025RVOAqprQ VjvjvABbFKecKf2e0PuO8DuZLBn+HaQk+GZFo/XbHrtuUlLeRIt4H/TxAubJZHrNs0lKApFO bI9Rtg5i3qQhO35FrPp5eYtSZLIMTblJcTlUg0P/AJYPZt2jpbOySb4+kH5jKsEs0uk/NbTI thQ7HEG1hKE0p9CVbcIOMekS92WEWmwuXt9hpwYKU8k+pgyTrdNn596ktTzan2Mb2wrlOexx EtfJdsEZ1R0Rt/UiXJqMukue/eKD1C6LqtIMvTtAXuTjOxHEeo6J156RKjU9p5Xrnhyj1JOr BWn8kI0Rser2lrZTJasSxbUXdoUsRuVMuHpZLL6RgjHMK8UVY1tUpx4aG+GNNPS6J0qnKbIx MaPWY5U11VykNKccPJKe8SGm0OSorIl5CWQhA77RxHmIxjH2o9GoqPBmv4lfVfJaC6STVGtu dQ7cVYSJaUl2lgKQFnapw+wAMXppDJ+BpbQJdx4rKKewlS1d1Hw05/rD3iCLXJGeqLX6g9Ne lFQ1MqsqZlUptS1KJO0urUcJTn0BPrHPnUL4wHVBXPFZtW0LYt9CiQlTqnJ1wD7HaM/rCalZ U1xdhxjuKfvTrh6tL9YcRcGutUal1nPytLQmWQk/dI3f1iAUafqVx3zSJmtzjs7MTFRli6/N uFa3CXU8qUef/vGeNWVSauFKKjHB3JtyV20WWISCkNJ5P/lEDcYlnXfEYIKkd8RrtcUgL6G1 J27E5PpDDeYZYpDo290n7RHwRclE6C1PN9Vtt+Y3+JOrSBnjgJH9vSKU+NrOpk9O5ZlBISKa 6pJJ75OM/wCUfPZ/zb/J2aRwXriwai94uRlRyn84RYlfp+sdpYAuOVOUsOpUCDHTj4Ms6UUp DhbJ2Ld5QewwMn+kYeofTHUlixsvXpL9St8zHnGFpVu7dnEqP9QMxtKiOJnaLLTGAnxUBZAP bPMei8P/AEH+Tna33i1qVLrifaFbMs40QEHHvn1juMyWFDTa1KO5ICT2g1vYDtgGWGspKEEb c57fSDktBSgcYH1gGyBy0tlO1Su8FhpsOhBGIAgcllJGPp6wHaEjaU5Tn1irkBoQ0jCkNiA5 APA/KIFZAAtSwQUbR7R80ELGwJ5PvFXKAMtFe9KznHpHq28khII45iXLfAWylYJ3JP3I5gTv P70nPGMRVwTxOSg+GmCTLhTn73j7RGQCpsJXgkkDtCB+rz7VUbkGKapbS0kqmAeEHPb6xTIO aUoKNxT5senpHzSktgsPc5P6QHcgLYlKsId8uI+8Hc4HEqOPoYJEFkoEOYbwR9feBeEUEoxx 94tEC1SzYcCynj6QVWGkfsh47hnEEiAKalCKWhop3eX0jK+pup1xaca+ztcoTynPDCW3WCry uoOTj7+31jTQjuuju9G0cdbKVKXdFsafdXWm1dZQ1cNUFNeV/wDxZCU5/wDNnEWvITtKr8gm epU2xMsODIW2oKSfzEJqQdN3OfrdBV0M3CoiMV7SGgVW45W50MJamJU5CkD8XMSpsoQyApP4 BzBVa0qyW58GCMFBuxn7V/4m3SZo5Wpy2a/frs5Uqe8qWekqTJuzS23EnCknYkgEHg8xm/XH 41VQq1PXSdB9OZiWL6cJrNfcDZb+oYTlRP0JELc4Q+7DUWzGGo+pV56xXMu7NQbgeqtQmXmw 4+4fwJ3pyEj0H0EdwdN5QMWHSkhXk+Va2p9hsGIkZboX+5TVmZe+MC+ljp6bl0r2+JPsdlYJ wT7/AHjlrNub54lzOeYy6jlDqfAnU4FLKEjKR6ZiQaVy7U5qdbjJIQlVUlQTnAH71Pr9+ICj maJUxE7nUllYprW9RKNo5PeBtoZKilCUpA9BG++RIB1lBVgp5HrDHfDbCKE+ruQM8xJcMi5M 66AyCnboqk0JlS0vTzy0lJ4A3dvyORGd/jg1WaRZKWHprcJenqwCnGNx/wBY+evOqf5OzBWR w+qayl9atuST+sI/HV/yz+kdpcAWuL5EZ2hIxzyc9o6c/BFLM48ac7+ArdAV6/8ADyR+eIxa /wCmNo5Nw9QlH32XOqlW8hLJICuPUGNdWzLqFsyT2QlPhI8v02gx6Dw99BnP1vvH2ntBbYUl X3hay0FLCV88d47bZkDC2EujB49o8SAiZxxhUA8kFLDR3YxxBziEpVg94W2QCkfuwpf9IMSG 3FbgkfnAsgrlmm3GNxOfbEBclUoyrOR7Qu9mQIABcHl49oEZVC3EuFWCn0HrBN2CBvpaKDgD P9oSrQG07hjJiL7kPGVNADd+IwYUecYxkiLIwUwyAAtxQ49II2tqO08gnvFEBqlwE4SQILcY RgBKhuiiWEk1T5hSkusOAYPmB9RHrUq3sG7vFFIGZdaSCFdo+cLakApAz6mKKYEIyoJQOPeD fDWn93gD6wSIlcUMIWE7UL/PMHtgElChz7xZD3YEjb3BhDcbHhUxSkH8XGYtPJO55JtEU1CU L5KYoq9emGsXnqFUbkn6gESz+FhpHByBjGfYxoo1FBu51el696GblFZKDvi0pi0rkmKFMSu3 wVEICknzAdvvmL86I5O8JeQnnZ111VMcKQyhaiUoI/lHp/nDq7Ww9T4hqU6mghLu7F/zLyGy lveP1hvvFSmLZnH2lkbWicg8jjvGJHge5wqvuddqN5VucdecUpVQmSStWT/xljk/bER18eI8 drRH1zGSXuY7sKKchAnpFuXYSoCZa8qs/wA44+v/AHjvZaMqli3ZOXSobEsN47/yiNNP6Yl8 mPfjMu+BojTZbYVhyqMnaf5hk/2jmLMLdddUpXA7ZP8AFGev7kNhwEbSleUp25+sTbp7pom9 crRlkKyv9rSxSMeocBEVQ96Cqe2x3HpkmF05tBGE4yMmCpmnFolTajzG5MQfJlEeXKs59oZN Qm2GLdfUVDypKjEl7WRcmdOmNvxlzMy3OFRVNPqWoZOT4isgDtiMsfHHnW/8PPSAUrCJEbic 85OcE/pHz2OdS/ydqPtOK06SHl5SB9YTb2vc/rHaXAoPp5w5tYc5J7R0n+B/PKXcqpNATj5h WdxwBlHvGPX/AEg6LOk/UlKfIaXVOpSUmHHG2SQlCCo8jtgDnEaTsNCZnT+mPOHPiSzagrPf KAY7fh5307/Jj1uZXHaVaUlWG8BJ9IXNN7kgbskekd6TMYqMiXAFJWD9oLMoPFTn07Qrdcgc lpxHGe8ePNr7E8wN1ctoE0054XKc4jxQcVlP9ohYqly6lAIOB7QpKHBhWwcwp2uUgptO9ZAT z/aBJaAByOR3MQsLLaVAlfBxiChLqDBVkEiLIJnWC5hSVAfQQYPFUAMZI9feCIeL3rG3vn0j 5H7vLY4PoIFkBDcUkq9Pb1j7wUuAOBP5xRAJQtQUnBhOQ42NpOTFMh64oLKck8iPpaXS2hSV jO76xXBD5uXKQQlPH3gwMqI54EWuSHqZZxCElpw8nPPpC1tvwyFLAzBAg0pTu8RztjtDTedS Yp1MCnEKcCz+FPJi45kRnjFQkJSSYmnXwEO4CfuYU06rUaquvy0pNsuOS6gh1tKgVNkjOCPT ggxbT5LTI9cujli3TUhU6hRmlvJ7rI5MSGg0ik29IJp1NlUMMoH4UDAEXKcpKzGSrTqJRk7p Gfrz6r5Oa60bT6ZbJdTMF0TMzWnwchlKG8obH/VuIz7CLuv+cZas6dCexZUfLyexi2sqwo4P 3HOFysTrm44VNOqBV3ILiiP6EQ3KIDpVuOAMj2jDPDZoXAut1uV/xHTXJt4IZam2nHFrJASk KBJ/SOqqviz9E1ApLUk3qc7OzUu2hLsvJybjjiTj1AGPT3jZRS8vLESXqwZU+IT17aS9VtoU 209PKLWWUyU5805NVSXLGQEkDaM+ufURj98uLV4zeMn1JjPWacsDYKwFBccUEhIz6j3i9vh3 6ST+qHVdbxYaX8lbzgqk2+E5QkJyEJz7qV/aKoK1S5c3g7Hy6W3JdCN2FJEAm842AbvtGtci BI8jncrjPoIjGoTjjVAmC5ykJPBPfiCl7Wy1yUR0t0pJor83LvbUqecIR6A+IfX/ANcRjH45 NTcMjUkTBSnMq2MJVzgHA4/KPndF31L/ACdiPBxsncvOEhRIMEfLJ/nEd62BbFtPQNu1IwvP 4o6MfBInXWL3YZQlJ3TwJBHOPDP+YjFrs0w6PJ1S1eprtVsaoSjDhyZc7k899pi9NLl/Nad0 haySTJtE54P4E/pHX8Ov9xIya33IkDSGmxnb9cQoZQHXPEQNo9478jELWCWkeb+hgzYHlBQA yeIS/kvuDXK7B4hd7x89LjZuSvKvr6wFywYa8Nv96o7iO0AZYJcO3zRLkDnWXC0EtJGTBzbY QgBxWcesA+CHiwlKT4cElatxCux94tEE8y4pCihBPbtBctNOKc8Hw/LjkwXYgJxpKkFSDyn0 949aSMAE4MW2Q8ebU2fFUPtAtiXUbynnHeBIfSzTZbLZ7+5MDDSUNlAV+kUyHjbZyQtWAR3z CWc8MEoCc59RFEANMjcF9we0HFnCCrP6QLZATDZUME/ig4tpWQhMWmQEGFBY2qyB6QJTCiN4 P5QVygieqknT5cKmphIUs4SnPcxD7rqFZKiqRlw8pXlxnsDD6ULu7AbF1Cq8qimNSVSQkK24 SCOBiOfet3V7qZ0gddN4VmmyS6nRaqzLOzNHcX/xkpQUpU2T2WMEe0RtRTvwFl8FnSfxvdBH qalc3pfeTc6E5VKokwpOfYOZxFP6/fGG1Ov2Ret7RqyxbMo7lDlSqL3izSknI8iUjak/Ukwm VSEeAoxb5MwWVrPqPpxf6dWLMuJUpcTfiFuqrHiLSXBhZO7Ocj3iQV3rQ6sbtaXL3Z1BVuab dyFsS6W5dpaSMbSEp5H5wCrSSshjir3K0dSqae3OuqWe+5XdR9zACwFpwpIODCpcBrB6Jd1D WR2gTqHnAkbinjHtET4BfISpslI+YUPbcTxAmqVMvObWGFOFXBCQYOSyEkTnSTpf1i1irrdF sizZs7lYcnH2ylppPuSfSOpPRN0fW30y2MZBB+Zqk4rxJuecThbij6fRI7AQ6nDblipyvgvX 5dtAK0q4H1jxC2FkoQrn3MMQsTLAKyFj7YiI6tK8O1ppYGAEHGPtFyfoZceSjOnGTVL2/wDL su4QSrKd3IJUf9Ywb8cerKmm6kypwbT4ack8/wDriPnlBfxL/J2krROSMz+7UpCx2PBEEeKj +Yx6CKuhIvkGztQo9lfWOgnwW1eHqCA08lO2bbA3fw5BGYwa/wCmMpe46wahz/8A+Rqm+pzO 2UWo+H3ICCf1i69D5lU9pPQZsclynsLPPqW0mOr4c+jIx673IlUqfE8rhxg8wvYYRt/duZHt mPQTMSD0bFJIJP0MClkqUvcfSFMMNdQX0eElXI57wFhToSoODlPaAxYlg5K1upAURn6x7LFf jE+kU0rWJYPVncRuHI/SPQk7cDB94AgB1TbaFOqIBH1ghbyloBKBj3gkiBbrWXg6MEesA8il emfYQaKAgveKU44H9YNUgpIc3Dn0EU+S+D3Clo/eJxBSC+jyoRmKKBqUjwlBWAo+xgTKf3eR 6+hirEDPBUpGNoHpyYT/ACJlUcK385yeYF27kB+EjAWf1j5bDjvnbwIEh8hpQSRtwfeDm9yT +AH0zEIGpSSvKB3j2cQpmWU4FYwCTBLLBKAu26qtXK88TOqDbDikt7SQMQzLrNVZcLj1UfJP oHDgR11CywBctTTqnuVO1Zefm3Euu85CznjMZl68ehmv67D/AB9ZbCf2xIhbCUYx4zW7dtKs Z4JOPvGGqk00Mi0uTGlc6GOpW0LaqF03Np8uUkac2p91anAohCQST+QGcRTK/MoJ/gUMhXvG GUXF5GxySzRXRy59ddS6bphZbLa56oFStzhIQ2hOCpauOwyP1jWNI+CtqKpXj1fU9kIUOW2J bO0+24nn9IbTgmryKk7MktD+ClJKKRW9SZ5QHq02ElQ9ifQ/URLaR8FnSVDiW6rdVYmEp75e wP6AEwThTXIO9kip3wgOnOnOAzNNnpoDuJiaUoY9sRLKN8LzpeprBR/gJmYSeVB9Slbvvn0+ ggk4JYRW5kxo3Qf02UNpIlNL6UCPdhJA+wxiHhPTdozR0/7lp7Sk47Ylk8f0go1Lsm5j7b1n 29QZcS1KprLIHHkQB/YQ7NyiUJyhXEW2CBdZ8MbO4I9YSOy5Sd4OMc/eLRAJKAAg5z7mIVre ppix59Z52srUNvqQkkRU8QYUeUUp0ySrwoUsqZTsTsSrK/XPPPvHOv45U8EVOoy6X0kqfQRt zjtn8+DHz+h/MM7f9By0n0ubiDgkwk8B3+X/APWju3M4tk3HElKEgcRvP4Mz7ytS3G2wDumW UqSpWB3OIwdRX7sOjmVzrJqbOuytg1nLOwmnuthauyTsPOPX7RdvTNMNzeglrTzSiUu0qWUC Rgn90mOt4c+jIy673E8al9/PqfT2hVKyyWVhxA78ER6CTMSFbTXhrKVEAH0ipOonXmp6Yy6a ZbzLap14+VToJSge5gtLTVapZ8HV6Vo4a3UKnPgqi3urPWWh1iXqV1/LTVPWcrQWyjy+pSQO 4+ue0TTVrqvuK152lTNqSku/KTjSH3A6DuKCecH0OI3S0dNyujs6rodGFa1N+mz/ANB86guo C6dMJCmP25Jyjpm0FbhmSrhOP4cev3iOX91cXrbP7MRRKbKLM5JomFreJxlQ/h+n3hcNJCUU 2Voug09VCEnK17/6EiofVW7MaNO35OybKqkw8qWVKp7eJwU9/QgiGfTLrAuq77j/AGDWaFJt hbTjiXZVRwCkZwc+8UtDCzbBh4eUqc6jlw7DVS+uKvTFelpasWYymTeeSlxTTnmbSTjOPXGc mJRrV1YvadV9ugUGhszoCN7jinCAM9hj1yOYCWkipW7By8NW1CoqeGr3CXOq6dY0olr+et1v xpmb+VDCVnaCOSc/aIsnryrKD4Y06ZWrn96ZvaPtjGTArTxfcuj4ajUpubnw2iS1XrHNOsym 3Um0CtdQ3gMF0DZtVgjd/wBoQ0nrxpb84hFxWDMyjOcGZZfS6lHuSO+IH9MuzE/7tzlQdaMv kmurfU1b+nFqyFyycmZ9moALbLK+6SMgg+0QWh9fNtOupXULfmGmlKAU5n8IjsaTw5W1mm8+ DXfB8y1nibTaLWPSVU7ruSy/eq6yLUl6XNSkk9OoqaQttbIyAD/94s23q4muUiXqjCDtebCx 6YzHJ1egqaSEZVO9/wDQ6+l11PVSlGn/AElf6xdUlq6Tz6aQ62qam1DJabI8v3hjsXrbsa7Z s0qoya5J4DyBf8fuI6FPw7qaumWpj37HN/3j0f6r9J3/ANB1sPqusa87uNlIYelprCigujhW M8Z9+O0fTfVxYUtd/wDg5lt1x9KygrQMp+8Zv2HqN8ofCuan1nS2i78uw5acdR1oalXk9ZtG Q+JllKlqLiSAQDjg/wCsWJPVSn0CRXP1J0IbQkkqUcYjBqNHU01byJcmulrKVaj58X6SoKr1 w6W06sKp7Cph1DatqnEJ4Jz6fSJirqH08m7IVegrCTJEbV45KT7YjpV/D+robHJe45en8RaH VKbhL2lS0i7NPryrz79HqeZNBLjqkDlI7mC6DcGnN1mpT8hMvolaajxFOOeoz7RtloNRC6ce LX/uOXVdJJRkp8q6/CCpbXuwaFPtmz7xwyTjwn0kAD17xf8Ap7cls3bQkz9HnmZpCh5loORm Of1Lp2o0cFOpG1x2h6ppOoXWnmpWIB1zuSlP6Wr0mW2diWqPMEqSOcbCOI4moS1JSKFrcwht pO4qOeABHHksJnVg7HUL4RfSWdONOV63XnSkJrdyjfLpdTlyVlQfIjPoVfiIHuPaNrpl0TCC kNfh94Gb24XYBgTKEJwW+PePvCSEbMwNygPhI5RjkjvHjTCG/wCH+sXcgJTTaUHA/SEc60hx vYpHPrFxeSDe222sFLaMFPqTAmSQkpcA47CNBaQU6VZyBgexhM7uzuV2iyNBDyc4Unv6iK/6 g5oylgVLZkAS6ySDzjac4iqv03+C4corHp9kJ1u1ZJpEkpzKG9yh6DaI5kfHPLjN2TjDjpUt UwEqPbgDg4jwGm+uztN3icx55JVkJGMZ5EJdi/5v6R272ERwK6f6JUOR6pjdnwcpxqW1OLaG wD8yyfN/Fz6mMnUV+7YdDk626tATFhTjUqVKUuXWnYBnJ2kYHvzFv9LNUkV6B2pJJmkB1qky 6Ft5wpKktgEEeh4jqeHM0ZGXWe5FlSmHNriVdvWFyTs27sYMd6fwYhYPCmCFk4IigermyKNV PCqztelpaaQPI285gq+w9YdoZONWx2uiVHT1SklcpiXn6hZk7LS190QTMm3g+E4nJKc+nvDh 1GT1EnZimV22UeHJvSaVttj8IGT39uOPyjrtdz1tWjasqkX6WmTHq3Y2UehqSrCSykHzcAbe 4+vaK81MYKDQEeFgOUthKSeOAMf3z/WBp+yI/pWKdL+4zCanJSQetMIIQ8+HFgcErHGYftK5 KZp1+eApIDjMs+PrkoMMna1joapRjSaj3I1MU92ZmZialU7kMklW7sBnjH94FXajPXbOO1h9 O3wUJCjkkYHH9TGeeDTLZ7+6wSubW8rpmlGlJx4daXtIHBG0D+v+UM9l3caSZWQcs2Wn2y4B ucbUVOAkDuPUe8I7HEnTU9JN7rZZYPVzQ6bRG6LJ0mVS02w0pKGm+wB5/oTFcXDXLTrFuU6n USgmXn2W9kw+rhLquMkY9OP1iQ4QeijOWhhO+Fe5Jdc6ZOUfQ20pCoNuJdaYHld74ye/5Yiv 6vWrVqlnSlJotEcRUWwA69jhf2j3nR4zlo6couyTd/wfl3xFUpftTUQcbydrf5HHUOmVGkWT bjc62rxfCJKD3T5jj+kbn0/cbltPqY2Wx/7qk5T/AOWPL+I2pwpNfMv+Z6joKcXWi+cf8jG2 saadW+o4ylfeSzKvPpbcWpW3an15houGgW5R9b6bTLUnEOSfjoAcbVkHJx3j0tOrUhRjC3p2 f6nl1RoSr717/MFfUDbFb0rv/wDblKWphSzvZdb42/Y/aHvpisKduOVq+otVbU54DaghTvdS iO4hWq1NP9nQrR5lZDNHpqn7UqU5v0xuxf0bJeb18qSEY/AvJ9vNF+9U8+5IaTz5adKVKRjA PfPGP6x5vXR3dYgvvE9DpnbokvxL/qZPsOxrfqundVuWpzTaZmVWQhJWASMe33gNuVF5Gj9b k0ubWy8khOeQeY9nKpKu5KS4krHiJUqenpLyu9Ntkf05vSYtF97ZMqDUw2pDgH8XHaJBpVNz LtrXVM+KraWeEoJ9TD9bQUFKfy4/8zL07VPUbaTftjL/AJBGnulT10WTWryWUBumpzlR5UrP aLo6AajPmfq1NW+pTCVYCSeAoH/SOH4g1C1GkrQ/4Wkek8NaVaPWUXH+qLbLA+IM+Geke+FY 2n9kvjI9MoI4+scwugbpjd6pNeqbb70qtVv0ItVCrOhO5K0j/hsE+6yMn6Ax86S9KZ9LXB2j otClbcpLFJkJdKGWEhCG08BI9oc2WeOAIzSd8lHjyQlPl5+kJyoODDQAx3MVEgXNbhtIbJJ9 RHqUb0bTx7mC7EDWG0DjaMD1PrBc4wlzzEDETuQRrk2wnelAAJgl2TbIwn88Q5SCCHGRjYkZ +sJpqn5O48D7w1MphHyYH7wJIHv7xWXUv5dN6oGUDcZZaR9MjvA1n+6l+AqfuQydP9Gal7Zl J5QylDQ3AcpPAyY5G/Hcn/H1CmX284M+pKU54xtGf7R4PS5rHYftOaq0YUouc5/pAcNfy/3j stiNoKSS7hDiFYxwRG0PhJVH5TVZx0ZOXW8ewyoZ4hGv+mxlDk7BV17x6G4265+8LfiHzccQ 1aMVapMae0x5mZWlxKSkltRCeFK7fTAjreFfbNMy67DLo0x1jqLMwzRridDiVcB88AflFzyc 9ITbKXG3EKBHcGO/qIWd4mFMWIQhf/CBz9Yo3qo0Yrl3vs3BSW1uraTtKE+oitHUUKvqOr0r VQ0moU58FRSujmsl91VmRqVOdCeEl6YPDQ+nvE81g6a6tT7Tp7NBlTNLkmNi2zyVn1/rHTlq IKagenq9c0vnwjH2rkg69OtatS56WoVak5p5tjDSXXU7UtpHGR78dok2rWid5KuaiUq36I9M syzLbHinsNuMkn9TE8+EZbbh1es6OFVQpP0pP/LB1nQC6ahrJLu/sImnrfS884ewAAzx9x/W C7e0ru+S1jn6s5bUwJT/AHhIeI4AWggYH3xFSrwnwwP21p6kbSl2Q1WPoxeU9K19ur21MsoV KlDS148693OMfSE1H0cumn6V1qpzNsuom3HkNtIAypSEnJP68QupVj8j5da093FS7oU1Cwrs R09S8mqgPJeFUU94GMq8PHBI9ue0R+1bj1TsqXakKNQSgNkqHjSe8/bJhcWmhlKtotVp5RqT 7vuPur3+0K+rIotfrlCmFVBSngUNNKGAD5ePTIhPqlohOWxZdErtPpjwdmpZJmkoyVNr28kA DnmKU0rIzQ6jSoUoUIyw7r/sOmtpr+p2jtuVEUF9EylHhvIUyUHKeM4IyAQAYs/QPpmsx2wq ZcFapCTNqbC1JcTg5+ojpajqMtN06nSpSzd3PkMOmwfVa9ecU/hlZdaloVGUr9MYoVKWtlkE 4bQSBALN6p9a6fJSVtf4VacaQA0Fls5I7R1aej0vUenUp1pepXOCtTrtF1GrThTvGTWSHaka f3JqNrYmWakFtmdWkKe2naDjvCT/AGO1iyNZKZRHmnnvBmm1bgkn+Lv/AEjoT6jSWnWlT4gY 6PRa0dT+rafv4+3yWv122385SaXMyUktTo/iSO3HaJJ030OZpXTKEzEkUPrQ4SFDBPJx/SPO Vaql02hG+dx3aOnnHqGonbDSM/ad6j3Bo1qRULmp9B+ZU6paQFZSME+hiy7n1zr+tendWl6h bBlPlmgRsJO7J+0d3WdNpLUw1qlnBwtD1GtU0dTQSp2spZ/yVDbejV13HaE5dsq642xLKKVt nIz6wtt2lTTOldWlnJdRcW8AkhJ7Y5/tHZqaynXvGH9MkjhUOkV9Gm5Z3QbGuf0yqqNOmLml 6e9lxZRjB4xyYkOlVHfktK7imlMK3PpQ2UkdgDnP/r2itTqoV6Ds/wCpL/UrS9OqaPWSbWHC /wDoNun2pE1aNl1WzFSDixUVAb/RODF8dBFqVaUTU65OSimmHl4bKhjdHF8RUoafSVXf3tM7 3hfUT12qpNRsoRaZMPiJMT8x0i3nLUqSW/NO05aGWG+VLWrypA+uTBHw2ukprpi0Dp1NrbLa 7gqiEzdUmNoBLqkg7fsn8IH0j5xOW2kfSTQrzHJWSI93paUE44jLyWFPJw5v9/SCi0gkhIxn 1EGngh4psKGz6QEoQEhtY5PtBXIGhAwAB2EfFtJASRxFXIFPsJ2kjHEJnJU8AYH5wcZEvgTT DD7agstgJH1gBZ37ioDB9DDU8BMSvy5CthPl+kVF1WNp/wBn0/KNObVuslKVdwCYqu/3MvwF TXqQ3aMvzH7PappZX8uGCQEjKir7xxo+N/NomdT1sGZ5TNrVtPqRwT/69o8Lo81Trf0nPOfA Q/gL5PtBWXP547Msig+SbCpcDHI9uDGt/hZzLrWreEKykqby17nenB/vCtc/QwqOJHYi6C87 Krl5RSEoDKkrTySOOIcOmyz5Sb0qp09WW3m5FaFqanWSCkp8RXrjtnIjp+F3ZyM2u7F3UjS6 xqzIIVS5oKVt8roPJj1dPvCxXU+EtT0uDjyEnj7R6iUtz2swImVr6h0ybbQ1UCGnT5QT2zEr SqWqDAwpC0mOfVg4O4Vw6WpkqCAhhAPuBA5imNL/AHLyQQYRvdydj2Xt+SYWlTUuhJHsIUKp ckVhQl0FSeyjAuo2S4aKfKFwEtp3e/vAXKRIoWXBKoyeTxC97TJfAyXc9K29bE9VpaURuYaU 5txjOBGeE656hl0sNrlVoKiraGs4B7cdozavWVKG1Q7mPUV5QkoxF0nrDfK5SaNRpMt4bbW5 twtYSlR9SP8AKGtOtt4Y8QU6nLJHI8DgH0zGer1LUQlFJcip6maaSJZbus9SNhTtYu2gS65p hwNSyGWylLhIB4B5wDEbOul4PvB6fkJB9KDlLCmztx9/QxdXqVSnKMbfkupqpppEhubWYOUW SnLdosupDg/eIeSf3avYcQ3S/UxfEqyliUp8gGUjuFHt9sYi9R1OcJKKV0DU1MoSwH1PXCYr NuGoVi25V54PhtPiJ8qkY/FnHvxiCanqfIW7J02sSlhSLoeZLiyk8g57J4+kP/aU0vixbq/1 WJFqBqBb9pUWnXTRLeYenKglDiQohJQkjOfyhluHWajplZKtJtdh2pPJ3Hcf+EB7mAr9VdJv 7BzqqN8CKn66yV2zzFPv62ZZxpbmxLjKuE+xIMP8jrHTkXcxpxS7dR8i698uXELHkGCScevb ESj1V1UlbvYkKyvxyTSa0Z01eSZmbobCsc5IjGHUR8SvTTRO/wCr6T6S6HNXKqlvfLTk7MzX y8stwAFSEFKSVbScE9sj6R3aeqqNeqTNXkx5SLF6G+t3SbqjFX0yn9P12xXJCTM+7SS6Hpd1 gEBS0O4BO3I3ZAwDntFQ6k/FM0Wt26Zm0dO9AH67TJd0pXU3JxMul/aogqbSAcp4OM9+DD6e qnFtqQLoprgtzS/q36dtQdAq1q5Uw5RqJRv/AH2RnwCuWdJ2tt8cFSzwnHeGjpb6xdD+pO8a tpNbGl1RpDFOkHqpNT0/sDPgtnBXkHPrnkQ/9ZKF0pfcW6MJcopmY+Iv08UKrBqgaKVmuyaH yTUUuoZS4gHkhKucflG4+jHX/SXqK04Td+kwUwzLueBM059O1+TcxnatP25B9YTr9XPVRvOV yUNNDT+yKX4Llm6NT6u14U+0h1HcoWMg/lDhLsBtKUIPAHYRw5O6saQamyVYHaC/AAcJUPKf WATIeLYSUjHMALSUIxk7gIJMgmCSqZxu4EHFtJ8xHPtBsh8sJQMj9ICErI+h9YpcZIBKD23w B1sghaVZIgkyCed3ng42/SE6wpSc7eB7w2PASE8yha0AgdvrFMdWjLbtivSz6iEuFKTtOD+I djAal2oS/AdP3I90ucmJSgNJCMeG3+P34jh18aKcM5rE414hOJp7IznB3c8x4nQ5q3Oo/YzC s5LNB0pTwQOcwR4A9/6/9o7lrinkUy37tKXc7gT2+kat+GK8iV1mD7Q/EWsBP0WPT84z61Xp sZS952cqVKDUq4wlg7nG/wAQONxPEPmktRaoXTLbVn7XUvMtu7v5SjxnNuD68cR0fC/ukZdd 2JNp+3N1OcYlpGork3lKKUeEo7ScZ5H1iwxX7qtdxMtdtKM3LdvmWhn9RHrKtnK3cwLgVu0a 0bwlhNW7PIaeznCD6/WEyKpedkO+eWU/LJ9R6/WEP1emfJZObLvil3GylxiYAdH4mycEGJNj eBuA5HvHNrQ2SsyAtpAGD+Ygzw0hO4nIEIZD1koU4FqA9u8GzCE7PxYB9RAvkvsRrUhAFmVA k5Hgq/tGVqFL1tyoLboBUp4ggpQnPGfb2jFrNznDZyc7UpuqrE9n6FWZXRSbnLklfBfDisb+ +z+ERAKEquy+79gNOKzyQhPaEalzVeFubCqt1USLSvi0VT+kdOmKk+xK1FpsLdRvCQV45HPe KnQ3PU7a1OyYWwo+IEHsv7H6wOsjtqqTKrK1QvnTGnWBc9gh6l0dpCUhXiNqH/DXjkfeKosu hyT+tLFHeSlcr8w4PCxkcDtj07xsrqMnTaRoqRTlBok/UfQqZQ5aQlqdKhlBUThI44HMRy76 Ooab0CrhO1SG/DUoJ/HyT/2/KMuqxKpb4F1VmRHKxXJ6v06l0qZUlwSTYYQrOFKJVwM/mPyh Re9NbpN3Io82CWJZKEuLTwNoxn78RzXU8ym6kvlCW90bia+f8JOXMuatBtQkVbVNhWRt7Q5W 63/+mWntLaO75wBZUrGzjOf8vzhlBrzfTxuQVO27HyaFvicbkZeSlfHDQmnfDU5nAQMEk/0j nv1D3N0d9FesVSuewrLTdmoU+l4t01T3iyUg5McF1beCFOnKsDPY9u0euhbade+cEN6W+nvU 7Tix9SOsC9KXM0ZKLWqzFLknEFl11Uy2QpYTgBKQDgD6Qb8L/S6yL20A1XqN129LVSap0vLs y63E7nGEiWUsqTxnk98c5AhsVbJG8MZ/hdWPQNbba1f0v1EklTFKdpkjPrQSSht1t1ZBA/nB SCD948+FrRaReuvuodrzM6uWkqraM/IrcQoBTTK3wg8984zDEkwXgR6tVDpH0Bt6saE6JUyp Xvc9UWGHa5UmgUyO0FPhS4RysndnPunmNf8AwdumDUTQrTK4Lt1ElVSU5eEyzNopyxyw022U oKv+pQUSR9oXWsosiNoNITndnGPSFsunckZAz9450ywT6FFOEqwTHgbV4QSk8wHYs+8NRT6c wU43gHKYtMpiZUvtO4jA+kGAJKR6Z+sG3ch86hHihonnEEMzCi8WVjBHbMRcE7BhbJQfJjPr BSW1JOCMj3EEmQC9LtqQUZAP0hI8wQCDjgQyLLQkU8rBTtimOqxhUxa4lXhhC1tjOSP4x6iB 1StQn+BlP3IX2TKFm3wAdqUsrI4zjjtHBH4vs342s7oC8/vXFq/NRGf6R43QfUZ037GYwdaD sxuPOI+8Fv8A5QjtgH1O8NAHiI49I0/8Nl4NaxeE22POE4UT2O4YjPrV+7YdPk7eoTJKpDQW 4d2BlxR5x74hp04dmBbKqUuZU6iVddbbDn8CfFWrH2yrtG7ws/XIzazhFlaKMM/41bS+1vCE FQz/AAkesX8JJmoyhS40lxCx2PtHpdU7TuYOxG6ppS0XlVC35gyb/cFHYn7QCTr9bt8fs++K YHWcY+aSMg/lAqarrb3IR28rks2mziKhaiFJnCMB1vhIHfBhTJa+1yTlUJmKYhwpHcnvGh6T zYLzOQWx8pPUPTHFtiq0hbaVHBUjzbYsOg1qjXDKCZps0h1Ch/Ce0cvVaV0Mp3RadxU6wlpO Upx9RBgSS2N3pGNsIZ7vpL1UtubkpZA3uNlISfWKt0B0quCg3ZOVO4qWhttbXhp3HKgd2f0h c4OU4z+BMqbdVSJjrdaM7W7OeplHk0qURw12BihpfTXU2noKZGizKEqABS2vj7H3jJqaFSpU jOBm1FGcqu6I7f7KdTa5az5r/iPLady00+c7UgenaGBuzb5n1t0RihzKg3wkOjypPsDFajS1 ZtNASozlJF4aVWFOWZYipCZOZl7Lix6An0iuLRsW5ZXWeXqTlIWmXafcWt1Z4wRwR78xqqUW /LS7GidN3h9iR9Slu16qy8g5SKQ7NFtwbks84B/i9O0JarZFcmdCZeTmZFRnWmypTI5KTknA /KE1qE5ym0uUDOm3KTK/09sOv1W9aa1MUN/wEO+I54iDtwOQD7Q4al2Pcda1WdZlaa+pMwUj x9uEJHbvHOho6n6ZQtm5njRk6aX3GS7NKrgtuuIpErJPzCTtIcSMA/SEtXauG3rocnmZd35m XUD4wTnbx3+sLemq0L7VwwfLlT/yPdla4VquV5FMuyaZnZHasOy/h4cB28HI+uI5rUy0upux tU5nVKl6ZVd6rMT777E1MyPzSQfEVtUU4IOE9sx6PRzqVKSlNZOhRk5RuzTnT9rx16dSNRuL TXXuzTNWrUKFPMuTf7HTJbHVthDSSpJO78R425/SM82Vc/UH0tN3LpbatuvIauBIlJpwNLUp xKUKQlSSB32qIjo3cUmkOVmsmn/hj9P956UaU3bf9wsNyblwNjxJbP7xphhC9gI91KUT+kUB 0juX5pPbus96iyKpL1Gp2y9I0lS5ZaFuLfmcq28Z3beePaGbHhA8kO6f9V9W+mi4Zi8bc0bk KxVX0Bozd1Ux1/wB3JQoDCVH3joh8PLrW1z6hbUrZ1T0mZp89T5wMSrlLQpEs+1sGVefnhX9 ICcVKNmiPDNNSNWuqqEtgMS6scgebZ+cSGhMz0jLBFSqImHAPM5jbn8ow1YqOEWOKHWlpJQ4 D+celaFJKMfmIz2ZZ6k5SNw59veA7UO58QAH6RRLBaWUlWNvEeqZQDhH6wVygJYbUrxR3EeG XaJDi0DPuYu5fY9LYCSlP9IIebSkDAyr6RcWSwUtO05VxBakNKAOz0hiKQhmmkIO9J7nsfSK T6qwHqPIyinMeJOMjH83nBx/SB1T/h5/gbT9yHa3UzMnajk0tJIEsskpHYbTyPrH59fiwTTz +tQT4oVkLJWf4vMY8lofqHTftMhOtpMx8shWCRk4j39nOfzf1jsLAKR5IqUtSVFIBH9Y0n8O peNammtykbgBuSe3Of8AKFa36bJR5O49GSwq35abfYHDYJQkcp4hdo7phcN10SbmaWwlDC5t 3966rGPPzwPrmH+GpqEpNidYuC89MtMZSzJHw3FJdmV8re/yH0ie01hLDfhJPAj0dee8w8C+ VIcRgs/mYbr5txy47fdpsuAlak4Ck8Rlpy2VE2DyUjV7BuCmTgknpXxHifK20clQ/wBIJn7b qVMQlFTk1slXA3/xR6CNSMrWYLXyevWhVJWYZlp1HheKfKT25i7dKLI/wlTVKXOeKXwDgdhH O6hNbEl3LiTJTSXmthH+sBCdqtgBwI4lwwKm0eJwPTtBTZ8xwAnB7QS4Ltk9dCHk+f8AQwWJ eW8JSA0nPocRFwQIeY/cbHdp9OBxCZqRkw8V+CgEeuIcngqwqUhrAUD29IL+SkysrS0kqHri BRLAXUSyz4bgQr6KgLqJVbCZdTeMccCCKSCP2YzLOB6Xl0JUR+JIj52lSK3hNPMpLn82IFlg J2lyjygtxltShzuIiHSVnPM3PPESLLgeO7c8nIA9hBRKcUyOXvZVefU5mz5DcAoJmZZOF4P9 fQRGabaNy28tNRbUpop4CXTkgD059OY2UZJKwO23AZSr8qFv1BampFhIdV+8Q2jAVn1+8SOq UnTOtUdV6pt+TVU2EkZWgb/qI0tO6aBGGyqRLVGbepUupUtLuNnc23wCPaEklT6ZRKsVzsuj dIoLcunHA9sfrDU82ILbMtjTSsuOzF8UlhwsHxElfAV9MesTGmXnYtFaNNoVOTJSqTw3Ko27 vrxCqqlKX2CQoc1SpjKS3TaW5k/xEkZg+gXDUblV+9qrUk2OMLUcn7RnnBRTbyWTGh25KNrQ +iuOPKHO3fxD6Cls+GT5o503dl/YMbQtZCicfSB+EEjJVk/eFss+ShA4PEB8MIOOPvEKC1/8 Tb2+selkLTk8j1iyz5R2pwBBSklXPBMWiCaYSSCVAZgkKOAMgQ6PBSE080SkqCwRFAdVboM1 RJfxAEqnmyQo8cHI/rAap/w0/wADaS9SJRLOusaczbi1fgklq3pyPTMfna+KFU0zWuzzcxjJ QVkA9sqP948roPqHS/pMrvLWFl5nnb7wX+0Zv3THXKQok2/DBUr8gPSNEfD5dI1tllBHdI/M wnWfTZVH32O6NCmfHoTKlpAUppKtwPukY4i3+kGRmWtK1tzwHiftCbUc8Zy6SP6Yi+gYchet 7Fqy7aEulvHbmHFhAThKiBntHo5s54vaSkIz2EJq1VmKPJl9xXm7JSO5MZ0nKVinyRuSq9v0 Zt64a46hyadGcd9g9EiGabl2b7qMlW6i2BJqcUltkE88EZMdCEZQbqP8Ir7Ht4z9PoMkq36v LeKCP3L3qPbMK9ML/Qw2ml1CaSUA4ClHt7RdSl5lG/8Aci5LMYcbW0l1haSD7GB70LOwp5Mc V4DR6plTSeeT7wnQlCskHBz2i0W+QSmkho7eT7wX4fl3KSM+0WiwmZQHEbdvHvCYJKXcJxj3 hseARRLgOS+SkZMeuM4Rv8Mcc5EBfIRD1StRXfwW5NkM7cpbCjzEl2YIc28A5h0uQeAInCsA AevcQIFsje4sYgGQ8JbddARgCPVSeFApxA3sWkfNyzO4lwZIhpr1py9aJcJRwOGyODDac9ru U0QG4NBqxOTa5yQm2+TkNqB4+kMX+z27rdS4ZunnwxkFQJIjoQ1EKi2gONhfQLUuVmZSZeXY Q439eVE/SFlTtGsy76xUqOxMZG5SsnI+kFv9QNhEzaFFmi40iWdlnkkBfjHOwH1x6w9t2/ZV KCW2ZKbmlj+RondEnNvgIktE/YzqRLS9qeHx3cbwYcpO2aO7MATFOQlJ54TgCMc5SjfJB6kb co9NeS5JpKSe3MKn22t6Vbs/aMTk5O7L7hM1VJaSUlMw+lG7gZMKZd0zACkq8p5znMSUbK5Y cvZwQew7x4QPUfaARAtbRUseQAR7tIQUpEQgHaCPMngQBaF4wgDjnMEiCRZ3IzjOeMQmWAVF tScexh8SCKbX4PC+30jKHxCKjON0qiO0ZxQWzVGniWyQoJTkkfX/ALQrW/y0vwNpe9Epti6q ncHTjOT1UcKJlUi6FLHGBt4PPaPz9fErW3P67TKQ4C4hoArB4PJMeZ0H1Do/0mbC34WEeJkD vmBZl/ZMdVi7IObKUNbEHnuMGL46Blv/AO2eTdSRyCQknkkA8QrWfSYVL3nc216luteQ+Z2l KWEArSO/lAEXj0kvmZ0/nEpScIqUwBxgEbs5H6xXQHmQGt7FsyjQLpWfzz6Q4ttp2ZCQTHop 8nOZ9UKnKUmnLn5s4S2MwySUrP3Kyu4qkjY2pJ8FlfG0e5iqfoW8p8lUXhPTap9dNccQfCUR lHY/WFdEvmZk2pWSnEfu5Ze47TyR6x23BTggOGJ7uuNd0VIziAQ2kYSlRyYNtenInZYvNzCU PIJ2BXYxU4KEFEtclpaeXQ6pApE4QFp7D1ibNthSgrufePPaqG2bGRDppJThSxx7whW2Uu5B 4PtGePAXe4POMIByILfDjTZKfvmCXJYnEz4jeEIOIAyE+IFK7K9DDVwA+Q+WIG5IAxmB+LlJ b2mFyCQhmKbK+KJhSP3g7EekelKgnwz2x6wxSuUwoJaaCgcH6e0eNyxfbC0r4ipOxEg9DCBh KCP9YNeUlAA547wu+S7BSwSNu/iBysm3vwTz94K5BSpoBraVDI9oZ7zQ07Q3W3U5Cxgj3EMp P1IGQz28huTU0+GUlROOfaB3FUJZqdWHGSpKtvKecGNjzO4AvtmTp1TWupfLpK18KKh3xDm/ Ly0o4FltGwc5x2jNNvdYhX+tXU1pjopTlT1w1EeKRhuVlxveePslI/v2jKOrHxT9RHXCnTew KfII52Krr5ccPsS232+26N2n0ia3VAZSthEdpfxNOpF2jBdXqlrsPkZBbknCE47cbu0WppH8 T+i1ShH/AGgTMmmdZGVGSztd5/hSef6w2WipywibmPLXxD9F7lqyZG42aoxLqcATMBA2D6nB zGitLNQLQvChN1K1bnl6lKLHkWyvcU/Qxk1WncI2XASJikhSBtSMH2jxbZUdyTHNCQJCUkbF HH1gpe1J4V6xEX3PF42/i/KCyQkbT3x3i0SwmcbcQCruPQCEywCrK1cEQ6LKEc3LpdaKQcKH 9Yy/1cyMsq6aBIzSAtLk2SpJP/SYz65/w8h1FetC+5FLp2itXS2x4aU09YSn0Bxxx6iPz5/E FUZjXScdUR5AEkkx53QL1tnQftM+url+W/D78ZEE+Ax/MY697ACqSlU7UvLPP0PeL16F1qZ1 skiAQSlWADznEI1eaTCo+87mWzLKVY9LmVIGFy7SikHjlI4i9OjJB/wFVWsglqrTCScHGcIJ x+sB0L3SA1vCLjlJcFZOcZ9PeFC3WZJsuLcxgZKlegj0csuxzWRWY+YvV8Tixmlsu8Anh0g9 /tmHSYfmq7NC3KKo/LIH75xPbH8oMNltjb7FEI1H0tmqI4apTm1uNK5KRyREM+VdDhQ4kgjO c8R1tNVVammgGrAqZTJqpzYlJKWWt1RxtRzFu27o8xKWyGpvHzKv3gWP4TjtGbW6nyrRQSVx vEs/KTBU1lE4x5Sg5G8RO7MuSXqkqGFLAfb/ABJUY5+qhujuQUSRzKFuIBUmES20JKuBn29o 5kGNErbbiXwS569oPmpSYQlQIBBEMvZldghxhDLI2N+kJdqkuJ4+0MTKATUjNpm0TUsoq45G eIWtJX4IU9gY9ICTLQYZdBQCeyhCKdSWSN54MXFkaEzDLq3inw/KOd2e8LmWkNtBISMGJNkS AuMNofSsk8QZMJYW2HNnPtAXyXbAmlEvEOF1kAZ8p94Vy7anOyMKiNkSB+EtO4qHAhmu8JmK Ufl1bVEj0+sNo+5ASIhdM47JMyEswrYt3uUnGeYXTUjUHqg1sUEtJSA5u7q47RvFkot6UEuw UhAAPYD2iHdQeqdG0utN+tVabDbbSCsgHzLwOAPqTgfnCKUd9axbeDmfq7q7O3ndM1ed0TBc m3QQy2FeRlBP4EfQcZ9zFd0SVnbvqapllHBSV71HgCO0hT5JDVtPwu2vnPHcW6kkpbAwCPeI e3QKxNSkymVZUj5b0QPMYL4Ij6iNVeZUJWole0/hUfT25iwtEta9SNC7zbqtBrzpYWseKysn w1j/AKgO8C4Ka2stux0w6Yupm2derb8SnzSG6hLJAflVHkHHJA9RmLYXMhljx3jhI5McCvS8 uo4hp3QVK1+jTXEpNIWT6JPMGeEt4lQIGIQ04vIxZABlSHStTvHbGY9Wkjjj75i0RiWZSsgp 3D8oTrbUOMQxMnYb5x/wAoHv2GIzV1RzTT2otAk0pJdW4tSAvOOBycfYxl17/cSQ2ivUrhur Hz8noFXlFxPimRWlsHgBRHB4j89HXdNKc16qjYBOzaDu9OI4XT+Wb37SinEY5PYekAyj+ZMd ZoAV05DYQlC/MRyMxdHRPM+HrnTAlxSdxKTiE6r6TCp+5HdKzZlw6fUxxbiVj5ZsJ7jd5QYv fojWXbSr7ZOcVl84xgAFDXEK6HzIXreC5UL8N084ERi5Zqbu+fTbdIfwwT+/fCsZAPIEeogs 7mc5jlMPNNstWXbjYJKdqyjs0Pf7xKaHQZSiyqGZVAT7q9VH3MZ6srKxEOaWm3wWXm0qGMEH kGG2oWPakwrxH6Kyo9/wwiFWdN+lhNYDKZb1Cpw3U+kss7udyEbSYcVY2ebOMcCBlNzd5Mq1 sEbuy2hPt/tCn+WYbGQQMboikuZyTmxWqerZMsH/AHiXPG4RvovzKe1ldyyaNc1Ln6e3NKnW 8LTyCrBj1yZlHngWHkqBH8JzmOdscZNMZdWCXglLoITjPtDgP3iA2rnI5Jip8loLflQUFKU9 h6Q2vMu+IVAYxBRZGg+XUkIBUjP5wN5xpCPHWjCQPWL72J2Gpy+6GqoIpEu5vePBSPSFrzKZ pAUIJx2cg8gTLBLYUeceggJf8JIbUg4gJMJBi2kOAKBJOILdH8KvaATLBsq3EJUgwoYIB7Rb 5ZAS1IKwMd4aLkQx8slKzjByQIfR9yFyIjeVNW+adMtNFQZCSrA7DPeFs3MNz8+Q2FAJVwod u0blwgCSUicbZli9Mnbjscxgf4oGtbr91S9myVUCGWUhx5lJyVjdwPpE0sbVJSBeTGFRuaar 84pT2ENtnAaB4A7RJbQuBVNlFtslCEE43ZwVD2+0dJO4DWSVUrUCSmK01LPKQpjhIGOABDmy 5QkVOamG0g+MMrSe0EnlAPB41aNKZWj/AHnCX+2OcZ7D8oZq5SkIadlFMhLyMjg+o94ZwguR +6Ztb6jonqRTL6kZlQk1OhibY3EBSTwcj3EdVKLWmdRbLl6rQKgkMzzIWh5HIIIjla6O2SmX TfY9s7T7/DkwqYfd8VSucxJkS6CCBx9I5laopy3GmIXMsbUEDiCOAoZzz6QKZGglScrO4Qnm lpRhQHaDRQzTvhvKLx45xiM2dRyHJnWCgyqOdodVhPcDA5/Uxk6g/wBxIbS9wdr8+qm6AVx5 pZIVLBKgM5IH/wBo/O91nzYm9bqwoc7FgY944vT+Gze/aUzMAYLiccfw+0J/EV/JHUFrHI4S K9rexQAMXB0ePoZ1mpw8PBUThXrAaz6TLpe5HdLTqabOntHVOseQSbOQB3OwD9Yu3oZnGHaD dAYfylFXWFHJByWmzjHpxiE9C90l9itbwWldFedm1qoVEmMKUD40wnnwk/6wglX35SWRIW2y fGmPKl0jkD1VHrVFRhk5fLJtZtpy9u05LIXveX5nXXDlS1e5MSBtJ2gbhj3McyrLc2w0hSyl IVk+pg2abbUjdgRn7hsLQhOwFQGAO8BUBjHHPpFoEbLouKnWzS1Ts2QDjASPUxSV1XtU5yov ViV/c7hjY33Ijr9OpXTmwJDPL1iouS6UpnHAD5tu7GIdrduK7Uzrf7JnX3Fg+VIJUD+UbdRG Lg7gxLqt9VSfo7T1VaxMHlSTDyy5gDccGPN1OTTEUNpwM/5wln5cr86Ej6iBi7Mtob/CVMpL Slbdp4xCh5gTMmphfOePrDL2YC4I6vTilv1Zqoyzq2VoOVbP44kSZUsp2A/hHEFUqbuS0rAX wQkKT3HoYTFxSkgON8iAWSwYUtrC1qATHpQTh5Hr6RXBAYICCEDn3gxkJIGRz7xRYJSVIOMD HuIj18PoYlmyXAglWMmNFD3IXIjFTuZ2n39KU4lLrDrCW1NfUnvC17a/U3JSmTe1xAJUwocH J4OY3WsLIxfd23WuYp1j2itCJ+rPqlUTLqCtMskIKnHSPXaMYB4yoRyv6rLrk7h14vFuj1WY nJORqr0k1NTa/EcdLZCVEnAH4ge3EaIWj6UCV626mWb8LHnX6wreqzknT/l2l9hkfSHxdgWe W/WZ5yopfSVHw0889hEi/wAaCUnA465hLhGUk9/cQ1AtXuSiiahNOUxpyZfSpbaiAkHuM8d/ SCW7wlq3WXJIpSCvOVZJxmDvclsDBMPvyFxvUVeAmZG5tXbB9DHSn4c+oc5/scasuqPqfckG vGllE5K2s4UPyV/eMmrhvpMkfcaRod3UmutD5V0FQ4I9YeENoWneDhR+sefqR2OxpiEzLKtp 2wmcZIOQc5i4sJoTvMBIx4mCfUQkmUeG2c8wxFDS4uVWo7UH7RmfXlZe14pDHigEy7uG+eeU 8xk6j/LyG0vcedTrc1LdO1ZLrquWkDg8cnHMfnf6t5oO601xTac5fIIz7Rxuno3P2lQzW8eU pgnA/wDRjqICyYvklB1vOQD6fWLW6TZgp1kpSMc785+g7wOrX7tko+47haYVlpOmlHZUlO1U ugqJ7/eLY6W7skafSbooVOfxOzVTy0lr0SWUDefrnML8Oq9Z/gHXe0tymuihMiUU7vddPmb3 ZW6sxPrJth+SlhUaiUmacGTgfgHsI9TqpKKsc3uSllttCClfp65g1JSnHHCvrHLkGhU34axx +mY8deKB4SEZ3ep9IVa7CPPE/d+cjENtUuGTll+BKZfex/w2+cfeDjG7BGuqWzMXdLpVcCwy 0nkNMnkfnEYqem1qNzBlqal+Yd7BtB4H3joaevKHpjwgWMNYsFy3X0vPSIyrzhtPIx7GLPtC QoP7GYnpCntNhaAfKkA9oLV1XOClFkSyOkwUlrayrsfSD5dJ8EKV3jlTHRDWn1KQcjt6GDwl LzONoJIhYYhdky27+H17x74CkJyOTB3BSPUZCdpQAfcR6Ukq3YAGIq+S7BE00QQrI49ISTJL TC+c4GYOPKBZCpu9riRcktTmJNK5Qn94nBKx9om0oFuNj2WMgQVVJFRyKmZdAJUSOPeDkNN/ iwBCrh2PQk+GQUf1hiuanMTjjaH05CRkCH0XaQuXBAKzIuO6sy6UNna2UDcBnskmJVKsSYq2 ESmHljJe/wAo3yeF+BS4Kg1O1GkNHZC8tRq0tCEUCkzUw1MrPmbWtvKUp9MqU2B9TgRyeqcr N0+j08VR3dPTLXzkypf4lOuneon/AOYkxqis7gUN8sozM+nLicJBzk/pCudo83MTCWZFHirX jCG+Tz9IcrlFkWlonVWZNExNUOZAnGSlKfDPlOCP6GI1qBZqaLa0lO/LlMwytTL6CDncCYY1 tRRDHp1bZCErUn12k4zDtZFWMxUXG3l7VIG7ynvFRd2XJYJLe4Hgy1RdRl5GAHgfxD2jaXQN ea16c2hcCVITOSlWmKW7s43NPtqUM+/mbz9MRKqvBpgrEjbFg2szQ5UOOAqWvkkxJ0EIwo+0 earO8maoLB8paXD7CCnWEbMBP6mAWAuwjdaKlHAzBEz4IRtX2A9YdFgsQPiSS0dgTyCcxlTW mZcmOpOQbQ2CGJJZyO/mWkf5Rn6iv4aQdH3gereadlOnqpOKcxv2JUDnH04j86PU9NuPaw11 7OSZpeDnuMxx9Ajd2Kxm1gq/euHJGNsJ8M/yn+sbyrXHGRUspCnE4PoItXpaeSxrBSytvneP t9RE1OYMqniSO1GnVakhpnRmFDKkSyAFkjJ4i4Ohiao0sxfl4T0gFzUvVUSTGSecyzazhPbO T3hfQPqsrW+00JZdkvCfN3VlO2Yd8yGlD/hiLEk3t207siPSah73g5iQ4eG27k5OCOYBLqwS yT5fQ5jAEKgptODnt7GElQueSkv3SXA8+ezLfJMVsuyxvWmtV14Jqb5lGB5vCbOCofUwlmL0 sC3KgLfl6lKLn1DiUadSXT9x3h0abk9sAQxSa1VZUzk5MBiVAz4LZ8xH1MRip6jMW3WESdNl 0IaIyo9zGmhTVW8FwU3YcJy6KfdZl52SBUEFSV5+0NaLsm6RNoZEwpMugkKSIaqNobZdi75J pZlV/bLDrzKt7QOAo98xIApttAB9vSOTWVpNIdDJ6nhB2iDZV0pTlXEIfAaBKKFpJA594JCT vxz29Iu5LHvgg4x39sx54W3Kc8H6xC7BRb8MlSzxjtBD7TTifN6+kGmAxMilyRd8US6Qsfxw az4bii1k+XiJJ3Ig9CCDwciDWiMg5HA9IAsE2pQCgtPrxzELqU/Pzt6TVObdIaaaSAfRJzyY 1UOWKkOFaeRJpbcZl0qUolKngnkH6w2SU7ItzZEzPJ3JSCUjPEaYXcQGZj+JdTvmumuuVBmd LMvUZ6SL6k+rbTu5KfsVYz7iOal11aYrtVMw44MqIxj+FIGAI6EPaCh00/0+nb4mEyUu2oJd d8MutjOD2jVelfw77uVLylV8Jve2oLDziTkc5HEN3qmt0gXd4RsqyNC5CnWj/wC1KYy5MMo/ HsxziMsdTWk4uOluU+QtBphCHFr+YZa8yCDnBA75MSlV85ysRq1jFuo1s1u3ayqWqlKW2QnK XCghOPrxEZoEwuRrBUXTlQ4HvBJWYTyiXSdwy1Uk3KDVlFAT+Bf19I0r0GzEyrUu2bBZmnFM moCfS0DwooSoZP2Cz+sFN2gxb5R1Jpo/3dtpRAITCpaQBtUf6x5afJrgB/BwPvACrarKjkHs IFchiR8rbJVu49oSLYRM/hPPtmHQYEhqq0olDCkLc7Z7Rk/VyrLa6lJdtDYKESIHJ9S5n+wh HUn/AAzDoL1iDrTqJf6epxPi+Gl0pHB5Jj87/UTNtzGqtZfaTnMyvj255jk6FG18FeTLYWC8 r+vpBG9qN3ANx3ZTsZB3A8xYnTctw6sUgFIUC8nyn05itR9Nkp+47P6X0qad0wpM62NywwM4 PHJ4wPyi/fh1W3LVW4L2fnVKDcnUWFCVOdinFS6SXMe+AB+UK6I9tST+xNZ7Ea5Msgq8PACc fh9BB8vKLbw4BhP3jvyd0cwcJTYASXO/pmENUr9OpjgQ4re6Tw22NxhUY7pWRBsdfr9bJbXM JlGf5UnzY+piCar9T3Tl0t0tTuoN7yrU6tKlolEK8SZewOcJHP68RpjRdR+XTJcwZ1N/GE1T 1SdfoWism7aNKJLZnFFK554fzA/hb/LJjLchqrqHL156u0u86ozUXjuXUWZlSX1HOc7857kx 06dNUIbIhbb8luacfEU6yLCSGJXVZ2sSgACpW4WUzGR7bxhX6mNHaF9flpawVVqj3ylukVZz hLK1ANO/RCvf6GGQjGN7LIuSsaVodxmXkEpkJn92s78p9YdJGb/aLTzboyojOT3hVRWyRFja Q0iekqEtU2na24rcn3MS0spSeRn2jztZ3qM0R4PFI8mFDBHtBjLfkAK/yhLGdg5CDtzxBK0q QrJPb2MREYIBafwYOfeClh4NkuKB+0WQK/eOJ2KTBXglLm4ke0WVY8XhIyCPygG5KV5DYyYn YoPQhQys9vaDWWfN4gTj84os9ca3q3AYx6Qw1dqTYrQYLIS44Acp9eY0UeRU8EfotcmX67Vq M+ncglS0Z7D0hPOtTUrSpmYqUilK0hXg4/E5xwP1jbFK9kKfBhj4pOtSf2BTND6PPAqpjiZy pLZVkeIUq2Mn3xuyR74jDtHeE874rmABxu9TG+Kskge1za/w8tJaddtJYVNyLakLX4hUpPc5 7j9I6IyNPptvUZmUQ2hO1IHEZ9Y3dRRI8XHmnv0NdDU1802VEH17xC5vTWg1wOqekm1HJzx3 jJQqTouTYbMr9cnTBSJi1JurUqTa8RCSdqRHOy9LeFEutMo26nCUjO33+kdlS3RUvkD7BdQp b06hl+VScqUEqA7jmNGdJV5J0x18tCuVlQRKy75S65n+BbZR+fJB/KLmrwaBfKOtFLnZZ+Ub fll7kOJylQ9QYXBKsZJGPaPMVFZmqB4vbtAx3gp1W3CSmFjLCOYXlCvUwheBSkuI/PEMiwZI bqwEmVU4Tggd8xj++UipdRs8h0A+DLNhJHc5Uo9/6Rl6jL9w0HQVpEd616n4ehb8sHSEcnGc YIB9I/PjrLNeLqHV3cAJXMrOc98mOfoMpmxrBC3XnF72lNnaIJ2yv8v9Y3sW0PMltaSoYOD2 Jie9PLny+ptLJc/+MOfziahWpsun7jtRo6mbe0wpe7dwykjPAT7CNF/DmaVI3dqDJIUtaXX5 J85ztSSypPH/ANEZei4qy/BWrd4Gq04S4SrGfbMEVS7qPQmgahNpBPAbHKlfYR6NRc8I5oyu Vyu1d7fLsOysoruVDCj/AKQpk5mkySC3s2uK7uAlTizDtllZEKI6/wDXu4NENGJmoUGpfs+e n1fLSziyC9uVnzJH0GTHJ65LpuDUG63alcVXfmZicc8z0wsrVn35joUUo01buDYS1K2m5Ca8 NEzvB7/Q5glVHmWleKhYSBngk5/KGjVwOFJkXFhDr86Nqv8A4ZVgn7QrqUiiWUh+mNKLjZC9 +eEY5/0iMXLkvTpw63b/ANN5lqjX7PO1ekPKARu/40qMdgf4hn0VzHQzRi8rB1VtKSvbTe+K fWpV5P74ybmSyod0qT3SoHgggdoRWeCksl/2o+0uisoRjATDlg7Ae8ecqL1s1rg8SlspJV39 o+LiAsBWACPeFMtBviNhOQfyijesTXa9NFqVS7ioEz8rTm3yZ+aMv43k2nCSMEgFWMkcxq0d KNaooyAqS2q5Gbj67xSrXolQkqO2JqoOZdMxv8LwUpKluNqA8w4wPY8GNC0GsSlxUWUrki6F tzjKHkLHYpUAR/eD1WmWntYGE9zFqw0F/hx9oJcQneHNuYyDgC2FHKiBtI/SApQlIG5vJHpE BYaAMhOcZ9IEkkL+n3i2WganUJTuKcH3iP1T5NVaS8peVpxjJ7w6jzcTMbKZSpanPzs7NAfM Pkkf9Kc8RVGuOqletK9qTRaXNNkTbM694b2Tgsy6lpwPbcB3jpaeKnN3EvCObHU1NicsWi1O ZlnRUakXZ1+fmAQ5UlKcUVvKz7k7U/QRStOHgs7khKccke+Y2JZK/pOknwvVMDTKUnlvJWeR nPI57f5Rri+a1ZjlsLk63dEvJ7xgLL4QrP0MI1MZOrFxVyo+0rim207cypej2vqeuUalnAtH guhanOc87s5EW9JS4oVNSJid8RzHmWo8kwGqauopBIzN1waqytJtaclUrBwk7sGOVFzXM5Wb tfqW4Aqc4UPvG1LbTjEFcsl9CmW0LamFhOFDI+piWVGvMPW9LzzDYEwwo8pO1XBh3YFs6Z/D i1zXrLoewxVny7UaCsSMwtfdeBlKv0/tGicoJB7R5vVwUKrSNVJ4QB0oIJxjEJlrJygK494y jxG/+7GFqzn3hFNPLTgjtFrkCQ2Vd7xZB0JHODzGObrnFS+vdXdXgFpDYO0+b+I5z9ow9Ql+ 7G0Vkrzrcr8w9ow802XFIKVFSgrnscZ+kcDdUXXpu8J+bezlcwslPtyYz9P4ZrfCIySFsYUf Xn6wDEr/ACx0GgLDtLn+FHOPTMTnQhal6l0cp4/3lOU+/MVqPYwKfKO2GjEylGlFOaDichvg Z7euIv7oGuaQkb5vdD7pSXDJED+YBpYP5gmM/RVeq19itXiJpWbm7jqwUqnpEq3n8bnKlD6D 0g1Mrb9AZE9Nt+NMKHdfnWo/QR6ZqysjnApOSuu6FFbzCafKAnagnK1j3x6RIaFalIo0up1t gKeVklxfJJhFSpZbYhI5Z/Fq1Rrd467OWQp5YlKG2EoYzwpa0hRV98HEZKkZCdamUOJaJUD5 SBkgx21HbGKXwKuTeXttupWU3VJ5WJtc0Gm2cYUU4yVE+2e0TVrpu1CuSxv8TSdtPONsNqdd f2FCQhA5VuP0hijctSsJbd6SdSLutqXuqRoE1LSbx8s0ppRQr2I49fftEcvnSu9NKKymj3JS XnEzDe9rxG1JDifcZHP5RHHF0De5GKpI4b8SX3pUP/h57RsD4K11Tkxq9fdlTuzw5ukSk602 DypTTq21HH2cGfyjFXdojInSyx5oBDlLUnzMngH2iRELAwckfWODWVps0Q4A435KuDAghKgA vmEsL7AlJbSfKR29TEW1c08o2pViz9sVaTbeRMtKTtV27Q6hLy5qQM1dGV6bSbK0WoFQsm/Z /wCXkpcq+UZnmysBJBIZQrGMkg4HrmNEdMGo1k6j6M0Sv2JNoVIiXSylgcKlingtKHopOMEf SOh1HKTE0uSwlK/ekA4J94+XvQnAwY5RpPOBkjvEG1i6gdLtCLamrw1Pu2UpchK4BdmFcrUe yUp7qUfQDmGQg54QE2lyVfor8STpZ14vqXsu1NQkS1SfUUS8lVG1SrkyR/IFgbvsOY0TLLS6 N+4FJHf3i6tN03ZgwluyGrbbcTtyMERHZtqW/bAK0pyFcZPYAQVHuVMZ0tzdRrs1+x3PGMwk AKVnajBij+viwbU04taW1zqtfUK/Kyk9TZaV37RNKmpZTSUpHoUrKVZ9gY3Uau2qoLuLccHL HUeqPurlpSozpemEAIVyVBvt5R9M5iNuJQiZXKIWPKfLz3jorAL4NcfC+16pdtVqc0nr8220 7MOlyV3nBXkeYf8AaNk33oRYd+TAuOpW6xOzJTgiYKlIWPtnH5wbbjJNAJXWSCTGhdrU50S9 EtlyluNqymakJpxstn3AB9Ilkhdz2l1vlVx6h1GrHb3qCgpSB6AHjP8AeGuKqclcGJutrqOZ uV16l0yeBcdUUlO7JxGVaWw06+VTCMADJwcY9oXLLC4RJ6VUXFUM/KpKnZVfbHcfeJ2r5Wq0 OTmmWfO+EpWy0kqJVnAwBycwwW+TpJ8PDSCe0s08ampqWXLTVWCXn5dYwU5Axx7/AOsakTt2 AAcge8ee12arZqpLFgt0BWd4wP7wSUtgbuM47ZjEPQgnfOfDUe3tCGb3JG0eb6QSAlyNlVWF SSykbeIxLe00pfUNXW204VhoKXnuOeP6/wBY5vUcUzRR5Kr66n6rStKppHifuHW1FLZHOQD/ AKxwwvmZfnrinFuJ2lTqjj84X0/hs0S4I1OEoZKSocn9IRYT/wAwf1joWBQ/yYKXVqByT6A9 om2jSnGNQqStpRG2ZQTtP1gdR7GLp8na/p+KpjSenMEb1NpO5fvk9h+sX30OylKp+qN1uTjY WtUvKeC2eVDAc3H3747+0ZuifWZer9pqf/2tUnChvEu0rgKPeHKlW9JyLiXFJ8VY/jc5j0s2 krI5w/yylh7wkt+mYNVnaUBOMxifIXY5G/FLpDtM6lahMLThc0htxIA7jGP/AO2IBpPY8pXp dtbrCCVDbvJ5x9o9PBXt+EZmyy6foZJPrl9iU9+UnIOR3EbL0P0wkLr09Fn12QQ5TpxvwXZb sFIIwRE1L8undFxyaQsvSe0LYtyVolOpDKJaVZS0yylPlbSBgDH2iquo7SbS6/ZJdBvW3WJp oAhC1DC2/wDynuI4WhrVKld5HzSSuc4+p3pDktOpqfuWy5tZkWEl3wXFlRSkd+faNbfCT6Uq dpzpg1rzWWpZyrXbKJUw60dxZlCdyEZ9zjccfT2jfr7U4WQEHc1dLPsUm5UvLcAS8nYST6iH 9VZkVo8s22fcBQjjVYNtSsOiwaVhaQpChj+8HJeG3BHaM8lYNBLj4BC18R74qQkDbndERfJA NctI6TqBb7rhp7TjyE7tjiNyV/Qj1gzpktTRuwNOWtOdNpb5MS7rj0xKzBw+X3Fb1qVnuST+ mI01ZudFL4FxilK5YMzKvSnmSgLT6H2gsOJfRgADEY73H2CZ5XgsOOIVyEmOXHxVq/cN4a12 VatUS6aIZOdfbZUMtuzaH0trKvTKWyjbntuJjpaNcmeozOt12NJ0mgzNWpUyZadkWVzMvOtc ql3kAqQpJ/mCgCCPWOyfSlc163Z0+WhX9RpVbVcm6TLuTyHPxeMWwVE49Sefzi9XHBVPksbx GkIUt5YSkd4iSaLP3RX3ZiVQpEuF48Qn8QxGSD2JsNq7JbJ0yh2hTFzK0tsttJKluqOAAO5j lv8AER15uTWzqarNDZL7du2fKNSsjL5wmYccSHXH8euQUJB9gY1dOg6lR1H2F1XZbTKF4UEO 1spWvJbSFu4HCCf4fvEXraFUqdSpZIW7yEk8gR13wLE8hcVVt+4JO5KHOLl5iWdS6h5tRSUK B45HftHTTo++IlptqlZMtQ79qjdOuOUaSl9qYISl8jgrQexyfTvFbdy2kasWRqN1DaY0Okuz hq7KjtJBCgMxhTqQ6xKld1UfoFpbynBHiFXEPXpjZgq9zN9Ucq0/PmYqO519087j3iQztj1G RVTmZZgPPT6BhpJxjJx+v0gIIuRI6npZcln0pdQqlEfYaWkEpWPxfb6RfnQnN2HQ9Q5ao3bS VPyiAhLaw2XPAWVDCyOex/SDadnYX8HUK1KZR22kz1MnRMB0cLzEgQEt+Yjt7GPM125Sya4B L6iteR6QmmXNis59OwhTQ2PAkUd2VKH5wU82d58npESyUxorLB+TcIHGDGHrmQJnXuvzLawv /eEg5J4wkf8AaMPUo/ux9Hkqf4i05NyWjbni4BDLpJHBI28Rw2vF9YrcwQocuKIhGhXoHyI3 MtgnxHXPLkcZgGJD+f8ArHQRErj3ItMKcV4QwU9zmJfpPOMy1+0zt/7wkEq7d4DUe1i6Sydp unh0S+ldNmAThSMHPPEaN6D5yXqGt93Jb2rCJGSP/l5d5jJ0fFZhatek1yvw0uhOQB+cLJda NqQoY/OPRy4OYxbLubXMbCB7mBOLLa8iM9sk7WOafxXbDqN2a80mXtSSM1PzUv5pVk5XhKuF Ed8ebGYg+i+jd/2rUm/8V2tNSjSAB50kAc4j09FNxi/sjPJGgrboVJrU61S5ZCS6oZUUj8EX vZNZo2llsGo16cSzLyw3LddOAAO5zFapOotiChjLE9P+J70ttTyqPU9R5aWQkYMy6FBsHOMb sYzCbUHWnSvVOkmu6e3/AEyppR6SUylas+xAOcxzdNoammrbnwMlUUlgzr1TVS1qfp7PruWe DapmXW002pWC4pQ4H5xZHwx9YarXejm26M2lYVRi9TQ+RgLS24dpHuNpA/KNmrpxmsgQLumZ ufmXFLfmFqV75hrVJXU/55NEyee6SYyelcjCf6ZMXpLtk3E6SzgeGlR835xNUpCyFBUcavbe 9o+LAKZ3HCjxmPS0EuJI4EJCQMISobF8xDb/ANPFPLF4WgG5asSfnacAwlzH8Ksdwe0Npys7 MpoftO9SZC85Ay880JWoM+SYk3DgoV649x7GH+fpsu+AtpW1X0MInHZKwyLuhqnm3pfyzMsp W7jy8xh74m2gU/WrQe1Ikqa+Jy1m5qpyrjav3akFtPjIWnH8rYUD7g/eOho5WdjPVMiy9W0c u289MNPqXPTqKdckzJylefU8XXPFcdOfDGMhJ8icegKo6+2bU5eRo7Nu02QKlyyQ1tQOEYGM f0g9W8FQQ7Gg12qzDP7QWGpcKyWknkj6mHzdS7epq333G5dhoFSnFnASPcmOdJ7sIarIrC+7 sl9U7cnmqRMrTSm0uNKcIKfGIScn7Rzm6kWaTRNeKtNzgWCmhUpb7OwHLolcFQ9CFJS2f1jv aKCpx2mWq7u5my4p981Z1qZS2hSnSooQeQfYmK+uWbfm6iXJlWVFRxj0HpGqoRHtMll1HehC SdqSTiB2JcDlvXGxPPeVKV9ge35xUcNBWLvvi/Vv2kPBmFrW8gYSCeB6RD9N7Qln1zlQr6CF N7S3n+LcYe8k8uSV7EqmrWoL7iqrLsJUWxhKcdj9Yv7pu6Mbo1dmKfezjrUtT5I7mi8jKnFj tgH0EW9tNOTKlTbwXjqf0bVeYs6dkahV0T63WF4UpG3YrGBgRReg+m1f0huN9U0wWHae4GnQ 8D+8H4vUeoxF05KtHdEHy2rHRLSerUu57OZqlM2JWG/xt8cxL5N4OS4UtwH3OY8zXVptGqms AVqZRuUVQkefSoZGM+hJhVhiWBI9NIabJWkE+wMeMzaXUZUCBjuYiWQGNNyTsu3S3/BcBISR iMMeItzW66nnWSgqnAEgjjhCR/eMPUl+7Q6iimvicVQNaNPJeWCv5ZzAH2PrHD2vLLtRcdxn JJyYz6JWgaJcDPUFhLQQ4gEEwk2yv/JH6xtRXI/ye7erMSnTKZYRe1MdcIGx9PJHGciK1HsY FPk7RdPU4hWktM/CfKpWSc4i/uh64GabrtcTcu2pSnqRLrQgdsh1eT+hEZOkfWC1eYGuRcc7 MrCm6aoq+pwMw4sTVwPNAiUaTn+ZXaPTygksnLFsqi4HWtxnWQQOQBCR/wDaiVqS7XEg/wDT 6QqO2/BHwYx1cTLWV1qCuVaa+bNRpmxlyYO4tFLqVKAz2G3P6Roa+TTarZ6a1JUtlEvPypUn 3xjIP3juv3QfYV2ZRnS62ud1AcmKi+kpbWpoqUfxnPB/9e8akvnSuSuS1VNNUxmbQtP/AAHB lC/oYz6ut5NaLfBcFdFGX1pXqXKWHMylp6R2lLVBCiJeVdpyZlCxyMncO5EJtKPhu6ezy6Xf d+NOU2ttLD0xK0JRlZdxXcgoT6Z9MxVXVRpxvB3JsvyZo+Ipa9Qs2/azWK1OtzzHzZkqZRG9 yTKo8NOxfspaiSB9o2l0L6Hqs/pes2k3BRnKfPmnNPTMo4AFNuLG5QOOMgn9YHV1nGCl8hRR bVRtSmUlbDqGyoqWByYkLApzTqZdDSQpQjlVJupFMNCoY3fgGO2RA0ryC4nH2jLJDYnrT+4B KkwLKhuKhC2g0fMl10hzkZ94H51pKcgj2ii2iF3vpdL1eb/xHbtQXTqs2naiab5B9QCOxGYb qbrhULQmU0TV+SMmokIaqrIKpd37nuj8+PrGlx82P3AUtrLCYuamVGSROSU2242tO5K0nIMR HVrTal6wWdNWfcAWZObTtc8I/wDFR/Eg/Qjgj2MKp/u3cqauZl0L+HDb2hXW4vVmh29JTlqT 1KmGqZILb3G2pgeHhSVKyVFzzgK7pHGY19YNk06yKY9JySlOLmpl2adcdUVFS1q3Hk9h7D0g q1RywXCI9Tk0xJMqnZt5KG2wSSo8RXtWvel6iszUsiWWaUwNqlOpKfFOcHgjtE00N0t/wVN2 wNN50WQtvTWZpEipfguMuJSWj5sKTjIPuMxz/wCsuhCV1Ttm86qkt0uuyspKvPOHCkrlFhh5 J47lBbX/APNHZ0rutz+TNIyrcaBWNRZ9uXQEibnXFMoPGEqWdp/MYiJajUtqmV6YYQrxG2co Dg4CiO5jVU4LjyJ6AF0+3pibUna5M+VIPcj3hhmnG2D51kjPJgB0FcvHpPmZS6a4/J1Jht4M S+Qh5Occ4jSNpaTVe+ZhymWXYCqm8kDxESjG7wx/1HsPzMdGDjGlukfUekw0lLpkaldKw7SG h11i5zYVP00m/wBqoQH105Mv5m05wFK9AnI75xE5osnr9abybGokpcEnNsth79nSbeXEJJxn GMbc+v0ieZQliTRpqR6TV9MtoomK/wBRslMIotWrNzOTcwD4cjOIG9eBklKQnJ4iNOsXvWlz tQVKzk0mVURNupRnwikchR9MY9YuKpRXotYkdD0u3pih3pWpWtNkUyXVIVqoU2Tm8KSQ3tS/ kZBBI7Y9odW9YupL5NpyVuyrrl1edLstJ7klPvwkj84z1tPQllpEqdG6VZScVn7hQ186jahu Mnc1TfDRG75OR34+hwk9/wAo+l+oTqKmlrYlrimVLY4cbEokqQe+CMcHHvGaelofCA/YnSnd KKx9xPWOpDXqQAbm7idYUsbkqeYTu/QjtCVzqw11SlLbN1MEjvvlUncft7QqWko2wjTDwv06 pHcojXVerXXCUlVlytyiyBkr+UA/p94hWjF2VS8KrULorTgVOzMwta1oHqOM/wBI891yEacU keV690nT9Nt5Pcp/4pNYLulL4SAlXyy8+hMcXbheQJlSEY5Vzg8DmOdpF6TzkldDRNbVHaOw I9e8A2j+SNiBix6k3UpWC5xxyRD/AGC40m7pAoBI8dJwfXmJW+mxcPcjsR001M/7LJGWbm+V EnKsnBOMjtxGgOiZVQnuoKsMUjwVuIorJUp1R8qfmFAED1Oe8Yukv98huq9hsuVotyKf3zNY SAe6Wk4Ah+lqVUlBKXKq5tPtxHqZNWycoWi35bPhrnXlk8YCzzBybSpMud6ZfcT33EmM7qOL wSxS3WT09U+77Xava3JNpurUY+O08kYKgO6CfYjiKFsPqws27tM5mgU6uzjlapoUh6lJaUUS wBI5X2+nEdzR1POpRb5QqeGxr0AupydrTr8oCAHNycEjJOcmNvaP3+XKSzTamnfx+ImE9Toq pTuXSZOphqQmnUzCG0kexENNwViVYnBI09lJdA3EZ4Ajg0ouUkmNlwYA+J/QEovikVn5RD09 WqrIS0swg7t73joTwP8AynP5Ru165pOiU1plWEFLYA+nEdXUU/MUIr4FrgjK74marsl33wpT a928QiuquViUukVaQqawkNBPhhXlH1x7xXkRT2l3JRal8/teYakEOlxRHn+kFaza+6c9P9pz F66j1tEpJS6cnupSz/KlI5JPsIxy07lU2RCUu5Ttj/Fe6R72r6Lfcu+YpDrq0pZXWJdTDTpP /wDMPlHf+LEaMtq6aFddNbrVBqrM5LPJyh5hYWhY+hHeE1tPKk8jIzUhyCkrSNvEB8ZDW7f2 HrmM6QbZCNSdetLdMUhV3XZLSe44SHFfiP0iIs9TfTXqMhqiG+6Q+ucwhLLywFHJ7c+sbIUa iSlYVKSvYjtwrf0WuGSqVr11S6FNPBHyrnLbSiScDHoe30i72qs3IPNrkZpDklOoDrZSc7cj PH0gdRFXTsXB3Vh4pc18ww4S2ApPY/SF8osuYUQcdowzHx4G+8UImJduScGUKJKh7gRX13z0 vRrNmSHEtjakA++VRv0ivFIz1X6ivKv1kdOdsVqm6VXNqlRW607LrJYfmU7G1pI8ildgvngH 2MVr1XaOSurWmlZoFCQhUy0RX6dMNqyhalDwnUJPstJQeOMoSY6VKm4ciJO/Bg29qfRpTVak 1VFAmKc6acx89TZkk7JpGUr2q/lVtBHtnHpFYakNhFVLGQVuKJUkenPaNkknwSLyI6mmXkqG 0tZ2JR5cH3iImUeqL5Qhsncc4HeKUcj4NXL96N7XnaTV6jUJ8eHvl9qW1DBUCR6x0E6TWb5k enPUGsaVy3jXM5OAybKAkrWpKUpA547BXfiGapRWnW7i6/5nv57f2RS38XLp0PTrpPPXFPaw S9DpdeMkwzKztP8A3iEIwo5XnHIUeRnGe0WHJyEoze8rVZ99lc83Si2ucCQN43JJP2yM4jz1 bbvls4t/0PNVreY9nAgrblOmL1t1tLSZt5aJhxueCMgDaMjPpnI/SKZ0Hkq9ZOt1xWbdlqTK aXdE3MvBcwzllaiSrue4IGPzjTR+jKN82/6s6GnknQnFvOCCdX99s1vURdrUsoakKEj5dLLY KQHAATx7AYEaQ0FYl0aK2qwiZYQlyUSpTaxku8cgQ/Wpw09Nf/eDpdYi6OjoRR7YFMlZKjT0 9YVJlJT5yquLmC+gp3YVtVx78cekKKHb1GolXuSrSMpKy7s26hTjnhDlQQBk4HMYXJts4EKk 5Td28mOOpW5KpXdSZw1d2VWmVV4TD0qyprejvyDnJznkRW3jNowpZ9eFE4xHYTSikfYunw2a WEV8DTdC0N011aXONpIB9IM6fGkNSEwvABW4o4HA9I8z154R43xasxKS+KfUfA01nVOKOAwV E+x9sRxwrhUmedWnsTHP0fsPDyEDyRvQ4OATiDMf+sxqbyKHSRUjOw9sckxIrFllN3RJOpWC kPJOPzi63sYNP3HW3p4l5hWmEo8h1Phkdh+LhIjS3w2kKPU1cyXAFJFBlig47K+ZUDz9iIwd J+vkdrPpm7iz4KsE9+0OEllLQ3cx6iXBye4uk20FRUTk/SDlLBV4WfyjM+QnwQHqbvakWPoz XK5WJ5DLbEm4QpZ7naQB+ZI/WOZ3SfSZqaqdWLRSy5U0uqccSMBRWCrn35jt9NVqf9zPUyyb aIzExatdfoVUe8Fcs8W1lXfvx/lGvtK71kEpZlkvgnHcmNOpjugVDBa9U1Ntq1KEmaqM8lOB ySrEUbrRrpV5xx+4bVkZVYZaO3xZnbvP2jBotI4y8yQyc74MtdNNHvfqs+IdRVXxW1T9LsFD tZclPE3ssO/8NlA/m8yic/8ASI39rHLqk3GVMJOFI5xAzlfU7SW9NyI214wcW6oAgD1gVQ+Y fdKyrJPGcw3uUPml8lPftpM4wklCAQojtGXviBWvqnrnrZaGjdoStPf+YXOzniVKYLDEuWUt AFasHJw6cADJhVOyqyf2I+BBqV8OS0tNemyZuSqTqKteEo4manGpBZ8JpjHmbQk90p/FuIz3 9Is/4TcpdlH0Om6bVXFIpSqg6/SZZecol14USP8ApKyojHpCdRLzKd2XFbZGuW3SpkEJxjvz EL1m1Kbse1puYlWluTQZWtttsblHAJzj2jDp6e+okNnK0TlV1IdSNyXndE2KjPiaCFFKGs8N n1ik01yoTcx82mYUHknKXAeQfvHXqZYpfcklX1318Zt1miT+qNZmKcoEIl5mZK0oH/T/AKw/ aQ9aHUBp29KyVL1PqK5eX4blZ9zx2seifNyB9jCpQUsMP7nUnoB6mJ/qR0xmqvXKaWJ6mqRL TLqAfDcXtBJST94vxp9qXY+YdXtQnJGeI4lWG2bijRB+m4zVitSNUSZmUmQpCG1cpMYp+Khr neWnWlMnZ1jVL5OauGdlqYqd53MIc3ErT9fLj6ZjpaGG15MtZ9zPdyfDT0VtvQao64T2ub71 UmEeMhibaaEvMTBGdhP4lKJ9SePaF3wndaKxRNVJzSm76rMzFvtyKnmvHKliQUpYBGSTtST6 DgEfWOlK8ouwpdiU/E50ct237lt/UyyNkzJ1oPy5dYUCgOIAWDx7gn8x9Yxxc1oInZkT7Li1 PJwpTbiskj1OcQym3OKbJxIZ6radWrko0glplAJK1TC9oPPpCyjW3Q7fpK55za8tJKVTjhwg c4wn3g4rI2LyWZ0yVRVVrlU3fhZYGF/zc44EaW0t1G1IsmeTI6cXa9TXp9aWMhtK0KUpWE5B HoTG1whKjaawfWdDQpVejR85XSL0kNEuryt1ut0Wo6v045aZVNzDqTsmt4V5cYykJ2jj6w40 rSvq/may5b7WrtDeblZRKHplDRO5tRI8MA/h7Zz9Y5T1Ok/4eDgfrOn/APp8CWUsDrQtu5JO wrbumUaZlGC9LVFbaXZZpAIG1WfMSc9h6QdP2/1tzOoEhQahd1ImZtttc1LT4lgmX4ASoEDn PmgXV0Upbrdi/N6Zv3bXwRu7+lPXm5LhTMXHN0uZqFRUpTj0q4QnIHJx6cD9YBVqh1K6f0Bd Vqz0nLSFmvCWbJQUnPACk/zg7hD3X02o2wX/AN7Ha/V6DqLhRkvsv7kamuqvWObQlqbqsq34 Ux8wEyzZbyr/AKueR7iDpLrK1opb8y/LzFKU5NKCnfmZdSkg4xwARA1NHSthHVfhbQtJq6/u QXUzVK4dUav+3rkblBMIQEf7qnakD6DvESceG0rChzyfvCpNRVj0OnoKhSVOPCGe7ZwIpiiU 8YI7wo0Dmm2aI4ELzlxZznPJVHmetu9keG8Xe6JQfxW591Om84hTmR4GOTxz6RyLqDyHnSF4 ICvTiMmkxTPDTYgcQyibQEg43DjMLfDa/k/qYfLkXwGy6UnC/DxzgkxJLHS5/iCUUlPPiggZ +sMre1gU/cdYOnSdUvTaTZcSQUoHOeOUiL/6GqxN0zqnnX5CdKFGhAFOCUrHjjHHvkev1jD0 hX1Fh2r+mb0lLhq7zwdmW23E9htODD1J3JJ7Q29lvP8AMI9VKF1g5A80+oSzqfEbfSoD2MRP WLXHT3Rq1Jm7r0r7Uoyygq2qV53D7JT3J+0Jp0pTnZEbsjmT1UdXV69UFwuTrpdlrckVgU6k 7yA+vnzuD1PYgHtEp6YqaqRrsg1MDYuYGFoPv9I7lKKgrRM97stDXrReqUKoM3ta0olcyMFR GQF+v6w06c69MUpPytxybktOoONqzjn2xD36o3J7SzLfr9R1HQX64wiZlAMpYUcpP0MVDr/q /ppbomKLUtO5xE22laUuBRShXHBGO8V7UXzgmPwN7D/aktqNrxMMKCKvVEUuUWRwWmEZXg// ANRwj7iN5XLbtPr0iqWdQkqUMBXqI8zXquOockaor0lePWYqhVIU5hwKLqcgwqlNLai46DMT SEpPt3jXLUpK/wAgWJXbttyNClDLsHJP4lZ7xQPVFa1oUq/aZeVelUqZSF5czhSFYxwr09P0 gdHNyrP7lSWAVpdQGmtXsxxNYpjjc7NU8Ssw/MtlIfOzaoBXr3/rE86bpu3UWLLppjDDCZdP yyWWz+FKOBx9gP1g69Jwg7lJ5LOVPNNS6nCsbQMkxhv4lPUWzb9uvW5SKu7KVGotFuWW1kHY FYWc+nbEJ0cPU5FyeLHOaemJiYVMVBxfmKz+I5Kvc/1iw+l/Tal3VX/2/ctPE0xL52SzrgQk 47q5/FGyQPBfvWJ052G9pBQb3tKmMMVBFNMxvkwdq2yokbx24xgRiqRmw4pBAwQfWAYaeDod 8DmozDt2XpIz9QnFtz7Eu41LeIfAaLZUFDb/ADqyDkDsI6IX0E/4bmGWXEpWpBAG7mOVVX8Q h0fYVLpDNzEnRqlRJybcedYU5lToIOCSRFA/E903Xc+ndAq6qeH0SValXX0nhXhJBKsflmOp RxVZmqcFb6Y27pPdlwTGnUhZz8xQlqlqgw1MJLjLD6WyFrI528459os/ov6EaJofr/dupDNT /aEpUWgiVUDhKW1kqW1t9QlWMGNOolsg2gIEh6sdK5C4NL7hoLEm2n9gTjVVlGwO7a/I6gew 9YwdfNo0imSakMyvgutIXuKjk57Qend4FPDKVrE78opK5+YUpuXSQG9xhjlalPXPN+HMqIk2 j5Ws8D24hy9wyPKLw6WvDTUaqlvYja2gAq9iY2l06aC23qZQ2Llc1AlpGp02otPLkZgAJLSF JX99xGeewh1aq6dC6Vz6hHUTodGgoRvfBqO0dQbWr1z3N+za5IuJaW1LjxXQEKIRzz6jzYiO 2i9R9I6vft4XJPSTsrOttzvyVPcztCUEKSB7naD+ccHyJvdTs7ux5inpatVulbLsF6T69f7Z rrdmqCWaXJSkv4bVOnVjxJkk9yfTAxgfeJtTmralNV0TTdcSZwyKm3JLx9yG/MDkD0MDXoyo ydNfAOp0k9LVlS+BoVR52Q13k71nFy8vJNyD0uG0zJV4iiQoKKew4BEMHVlclu13p3qtVpSk PJmVoQpKDzuDgH9MRdKLdanJcYN3ToSetpSSxdGMHHA6k7gAfdPvBAUokIURuOec9o7lTg+t oRrIUsIKhn3z/SE7p2kpSCeefrHNrPI0Y7vdBo7u9I4BycwdovSG3bdKpc7CokpAzxz/AN48 z1h3aPnni9+uKM2/FdVMyOnkxJKmCVhsZ3E8ekcq59KVvKJ7g+kZtL9M8PPkRuJUubaVjBz2 ELdjsaWrghqNoTsGP1iQWI4tVelAvIKXU9u/eCre0VD3HVLQKd3aWyKkIKAoBRx/5R6/5Ro3 4edbbpvU9XKxV3226bK2ut1yYd/C2lEwknJPCRzGTo6/if8AI7V28sue6vildJdGqD8lJrrc 4tpRHiSMmS27j+VWeYitY+Ljo0lSWrese5phzJG2cl0IQPuckj/tHtI0r8s5DeCAalfEi1o1 CbMjpbTZe2GMYVOIX8w8efxbVDaIoi9anc92VdFcvi8qnW6i9kmYqj6nNgPokHhI+wh8IKCw A3clGmularzmpKRlm1OJQsuFKeeeO/6RoK2tN6jYt2UaYmpRaAVgYAzxnjMNjhA2zg1Dc9tt TVuNOuSoWlaRkH0jP3Ufopp3N0A15qoCSqDIKkvJXtJPoMeuYqjLciTWDPdt9XF66LvN0+76 BMKlFKITMAY3J9/6RGNReoFXVFeUlp3ZkjKsVGvTKZGXfmlhtpgr4K1K9kjJ+pAHrEqTsmi4 rudXek/Q6zenHRChaR2fgy9Nl0hb54VMOkZW4r3KlZJMWHMTLbKd7igke+eI8vUvKozSvbYr 27tSLDpF4tsVe7KfKltG4pfmEpOPziHao9eOgGmsmQ7ecrPzOPJLSC/FUs+2RwPzjfHSzqKN 1ZCroz3qV8U68Hpp2Q07s9uRaABROz7gWTkeiB/nGYNdeo/XTWOebmLkv+Z8JtSsS8sA02cj B4H3/pG+nRhR9vJHnkklLvyXcptMdreo63panoC26e67tQ2rbgqVxyeP6xCtUerLUKiX9L3P pBe1Qozvy3y7/gPEtP8AOSSg5T6DnGeIOo1tsBbuWj03fFN15od5U+2dVqk3ctKqL7crsalw iabUshCdpTwrk5IIzjMJfiqVaWlb7te3pOYLjiZGYqE0z38BTr2Ejd/KQg8ehz7xnpwUXgvu ZKnJlpUqFuOkd+3oY1f03VvRd7pomZS8BJpuOjSTqZBtS9j0+64Ow/Int7RHyE7WJxrs5aF1 aEtam2TqG6zO02jppLdvMOFkKQ0yNxcbP1yPXMYBkJtJUFOFSjwSBAMkeDQPT7r1qf0zVSVv DTtqUbXUUj99OElCx65A/SOlvQdf9zdS9tzmr1+1sTbgeVI/Ly7h+XbcbPnCR2zkgRl1MYwh vSyHG/ALrj6qdK+mh2k28ypD91V5QZYpUmkl0NHOXlgDhII7mM69Q/UjVa7pDeds3XTqnM1V ugOXBSZ9iWKZVMu3tStSsfy7wRnuMxp0cW6Sk+RVR5aK50Ot+y7A1HpdGqHUbXGaTPUFusVq WUyqW+VW4lLgl95G4pVzwOeMfWJ7cHVVqGjUqgnQGv1GSdNSdkF2XWWA3KT1PaYStM0HtpKD uOCc9iOMxslHetslgXF2LYt3qDsTXK233Kld1Fbmq5SkoXILnUsqLaxncN2MgKyM/wDTFR3h obopqUpm257V5imz9TLgk36c61MBW1WCV4PlHIIzwYOEFBWSJIobVXoKtKhS4rVQ6pLfYk1u pbl30oTMrmwBlwpbbORjB5PqIYZroxsp2wnbk0I1yRddUk965qhTdPXKvuoB/wCIzyQcAHKT z7QVu4cXkgOmGpk1pXO1P5uirfcmglvwnMpI2ntj0wYmTPViDMtoqtmupSo8OBwpCftj3/rD 1WtFRPd6HxNT02mjp5wvYkU/1LW+xNMrlpBx+Wd2hRSdu08Ak9v/AEIvbTK2pC+aJL12k1EN pmhnhalbuPXnniDU7u45eLqEPWqZO53QOqy1E/aUrcikAclLK1IPY+owYS2ZorU7wqnyEteK WXDhJU664pY/MEH+uYCpUSTZb8Xaao7ypE1mujvUGTeQ0vU1xzwxgLW84Rj2GTEar/TVflOZ n0N3Oy4w0nxlMFxe1w9icZxmM8NTCfCG0vFekg1emNNv9OFcuB9UjIVmWDwb8RCFHBUO2YfU 9E2ozjLUwxVqcQtOSSTkGFVtVGHJ0o+N9LL+hiJ3og1XTuWZqQUoc+IlZAP0xjOYRTXRhqq1 hXiSG0jkB0k/24Mc2rqISd0aoeNNE+zIxf8A0far0u3Z2pTTMh4TTZKvCf3KA+2BEA0XlnpC hiWm0bVhRSUEkZOTHnepzU7NHmeu9Vo9Tmp0uxk34uVQS3aExLF1QKAgJUOMjPaOW8+6C85z tUDn7wGl9h5yfuE8upxybb8TsD+Iw67mv5xGkoJY2BZwr9If7PdUivShChnxRj9YusvSxMPc dVem2Wdqul8sltIwkJPJx/DCi8Zus27PqkJaquMMzsuWZpDKikvN7goIOO4zg4+kZeju2qQ3 V5pkU+SdYkVzXJLh2oHbCYU0a1nphAmJrKSTnnkAR7qJyGSW2bdmmmlVJuYWGAogIPG//tBt dUtU8zhrckpASc9uYPsCuTfnw0+neg3LpCdXqqnxJibmnJeXaHCUttnaTj3KgefoIvbUjSGT mJVqdTKpSplYI49jHNWrbrODHbEldDpVZBoW6xK7QVlAG2K3vXQuRrwNbrUuF7fMhlXbMaNP W2c9wJRKC1l6Oazq++mi0WiFbrygkbUgBKexJjFeqWi9N0/1FctWnzKFJYeLDkzLrKRvScHC h2wR+sbJ7JPDyAsFyaM9YmuXTm6mlyWodTq9EGEmRqrpfclT/wBC1eYjvwSYspPVBOdSm+hU nUm8ZqtvhQapMg98qgH04GM85gI0KUXutkvc3gq+5umnqbmqgpVZtCqvbMrUuYWtX38x7mIH cdJu60ZkUypWtPpdWrAR4CyXD9ABmDk01gFYYc/p9rZWKS3UaRpbWFsDs482Gk7RyTk+kRKs 1F9EslK2/DU0ohac9scY/WFPAxDHVp1JlVO/NYCsfhPaIlOzq3nfHS6fDT2BEKqF9jUvwmdA lav9SlM1IrtKW9R7UUpwFxGWnZpSMBOTwVISrd9CRG+etP4d1r9R8zI3JIVw0pUhLLZdZYZC jM87kZV3GDnt7xzp6nyayT4DULxuc1upjon1H6fdjVzqYDU8HHZYIypWxKwkbvYncn9Yr/S7 Uqoaf1c2/PWfM1d9af3crJMrcfQQCcgBJ9OSTxgRsvfKAkhNrLeV512qs1CuUCbokrPAFlma SpkP+m4E4CvyzEXkKI8/PusMJ3vSrfivst8rbR6kiA7lqyRLdaqPqFo9V6dpzdVRacUmmytW lW2lZCWJlG9tWe+SBz9Y6d/BCuldZ6KZVibGxxms1D98f/ipL5IX/U/pGXU+qGAo8mXLh1Bq vVd1/VW9KBqbIU1a1T7NLXNKRiVZknBLNJTu4KnSVrz7QmtaZpF/UijCo65TMvTaNY9ZlqxT Kg6lqYmXglwttJWPxIKxu5HYJEdGnHZTSQiXIupNL0T1BVYc3qHq/UqlO6kW+yip1OeeSyil LlWmlHO1IBJ2OICe+SOTDl06O2j0vaz0uYvyza3NsXBbzqZqfqIQ4iW3zuWicnyIVLIb59fp mHOLkrC18gVXnMU7p+sPSG6+lNq4XW5aZTKpn3kFZl2593wwEoG9Hlxyo/xekPNlaK6+airu +q1Todpst/iVYVLPuONspkm0g7ENgYPHr7xW+NNeuVkHtcuERvWD4fXU9qBVafcVrdP1v2+K ZIokvlpV8ZdCc+c4H4jknOfWJX0HdN96yuqNZsu8JxqkztBQ07MoSQpxYc3ABPuODz25xEde G1yg7k2u+QfxIehGvP3zT9VtCbJXU2USXhVumU1A8fKDlMylsDzkgkKA58oPMUPamntt3za7 TVZkDLLGQvxGyhaCOMFJ5SfoeYKhPzYXfIbbRBdRdMZiz2XDJzImJdJO0Edvp9YunpE1UeZs FFDcmQXpWYKGWxyTntmHxla6Kk8Gt6ZVKnNWctqcKkuFByruMmK8srUh6zNUKc18yp9D8xsd QBj6Z/UiE1X6Wik8murkrrNOZYmpwY8RGQknjtFX0i62bxuCelG0OKQElKlK4Tg+n1jFRVoX GyZEJm5XbLuqizi3lDwH3KfML7jB8yOe/YRpS01sv0dtxs7gOQonvmE6z2lwaHF1LagUkgZh E7JsqykIH3zHNlwOTyV5rg2mRsipFCiAWVZjCemkylUiXytRStSiPXuon/OOLrlhG2k8GNPi 8ze633kLJCvGQSkHB/p9I5oTTrTzxdUE/ihmlX7sufIUwPEqrcuFDao8gesPf7LY/wCTDngJ CFhTaDlIBSO4h1toCWrEu7jOHEnH5w2r7TPHk6y9I8yXNI2VtjyjwzjnI8vv9oFqRJLqt7yV NaSMvNOHckegxGLpP80hmp9jG6eRKN1BiWWPwJ2hA7BWYc6vLCTkWZcLDalDcQPQR7uPByGx RLT78221TZZRCeMqGcCDpymrm3x8otKnG1Z2k/5wfYFYZ0f+ETecjUen6fs5+d/3uj1iY3y6 xtKG3cOIIHscq59wY1Hc9CFZpa5eWxuPIjzVZ+XqHL7mxK8Rit61lLranKpJq2MICUhX4VH3 EK7is1y4X0S8u2lllI5MW9RtqbvgmxNDjSbSotsSJMpKpLn8ThHKo4r9S70vPazV+ZpMmiXl DVJhLTCP4Al5Qz+cb+lTlUdST+wqurNJDFNyMrPPuh1eSUJUtPvn1hkqtJqduut1yizcxLLb VlD8q4ULaV6EEciOy+BCZcWkvXP1Y0W23JGU1SbqrbKFIT/iKVTMuJP8JS4Np49jmDLB619e ZC6jW7tq0jX5oK8zNWZSttaR3CePJ37phOyKWEFc3lofrvpT1G6Vzbluy0sxUZRnw52knHiS yynt2GUn0PrHJHVirNWdqNclrVtaZN01WYSxLOK8yx4hwEpGSc9+PeM1JOKkpF9xZRunPqKv OjCco2iVzfJbS6J6bkHGGtvfduWBxiIBVKNUKXU3aRUG/DdllbFozkA/eDm01gtcHUH4FxvC f0Kn5eoUGmt2/JVWYVT32AoTLq17S4pz0I3DCT3xxG8qlOyzciUvHv5cGOBqc1cGqCtAoTry 0EZ1o0dmRSKW3N1OVS05KtL4Cih5Cykn2UEkH7xYGnmj+n9FoP7PpViUynszjGX225dIWQtP LZOMkY4/KGOrLy0k+BVk3ka9Qul7pqrYp17X3pbR6m7Z8m4Ke5UWg4iRQPOrYg+UHyjnGeIg fRtbWkWsWjEveM7pza6v2s4886zIy6Fp2rcUUpWccq2kZzFxrVPLbuRxSkZb+PH042RaFuWf 1F2vT25GacnGLanktpw05L7HFS/0SW1gpH0Xj0EQzpw1vuDph+EpPXRQ5xSa3dU1U26cjeAZ QFzw0qSPYFRI9cmNem/ewW4GSs8Ec6Y9NJqrz93XRTdKrBekrXsqSbearRcWh11SHJjxkFP4 XlFvznPf3hwszSG4bE6fZWn1TR+lzNp1+2ZGrVKu0OaS9PqS5lamWNxBKhnPAI75jowabsZ5 Bd7WtblV0QvGk1CVptRqem9K8C2fkmioyrD621rXOKSMBezCMnPmH1iWaUakW9b+jE/bWnN+ MXhfdVppeq1u3YlTzVPkmUFTjQfX5UthACh9cewg3dpkiam+FhovOWl0x2/cmpMuubrVaSuo 5n1F1co08re2yCecJSUxq6VEihAQ0yhIHYAR5zWSlOozZSskHlplxOdiDn6RkrqW0Q1PsrqT pnUFo3SXZpmYljJ1mnS/Bm285Rz7g/SGdOqRjUcZvDRK0bq6Lp6f6TWKzLTd63RTXJVybIbl 5eYQUuIaH84PZWSYY+oLol0v1nlnqlIU9FFrSzv/AGpTkBC3D/1jHmH9Yi1boahyTwF5alCz OcvVpoJqZoQ+5J3xQsyjxWlqeaytlaQcAlQHCue0Unodcsvb16ItqqJHgTrwWjcrbyDkcx6O E4zSnF4ZimrYNkav67TOiehn+N0UxmbLQQkyb7xa8Qq7AK2nB9e3aMo3L8TK76o6wmlaMUGn KlXfF+aamVrdWrjuSnbwRkACM9eo4toOEb5JUPjR65P0NVJremlBm1IR4bM4t1aSjj8RQByf pnEPXS/8S+57h1el6RctsSiGqmAhYlMkNnnzAe2ITTeLBTVkaY1mebk5tyrSL4WmoS7c/Ktg kfvEjJH5pMaA6YL9lr8sBqcXnxdgBbVwRxCtWrwJB5J8QlYwpPMAUUJXj2jmyVxqKs6ln5RW nNTQ8zvSWlBSTnniMNaYtplqSgrRsATyEnhP2/pHG6grWN1Hgw/8XKfW5SVHbhRfT+mMRzid CULUHE8d8+8HpV6Bk+T6k/v6yyQBwoGJX5f5B+sFJ5LjwRtlLylhaVYGfww8UwqbqDC2l87h wPvD6vAqCOr/AEarcVpMwkJ4KEDJ+3MPWoKfk7upzzLQSp7c34n3A7Ri6V/MoPUL0MZBJodv Jcs6gbGUAhOc4V3P94Mr8381X1sHlGAN2M4Ee8SscViyjAyjCXWzk7oUVCXqSEvPqkF+KpO4 IAxu9IO2CYLc6L06jTuudn25blyz1LmJ+otF9uTeU2lTSCXHAsdleRJGD/NHX+VSUthPfiPO 9TsquDZSyg1LaMbtmCY+KUgcDEc246w13dXKdbltztdq0yhmWlGVvOuqOAlKUkkn8hHEq8Jp V6XxUrq27JWcnXplorHO1SypI/Qx3ujRtGcjHqcyQBSGv2ow68EqS62U4HrCNNOD6TKLPk3Y O70BjtS4M8RstKmqpsg46oBJDi8pzgAAw2XLUTRX5CcQ1s8clJx+Zz+kKCJjo3WbwVqTT3bE vSYoc44hQfnpMkOOMJQVrbxjBJA9e3eNNTd59NHTDTqhqa3pzRZu40S6XWrirp8ebnn1IQoh pCgShAKgNwxk5hc1dF2MtX98SLqy1lmpujVuvSrVPdcUUykm2UobQTlIPuRwMwx6E9PM71TV SvUan6tUOg1yVaQ5KMV1awmoOOLxtCkgkY5Pb2hMrRjgJHYroc0TPT50+UDTmdVJrm5GWS2+ /Ight5eOVDPPJzyYzT8Wjqe1vsXUS2LG0FuR2nii+FVqwuXAJey6PCZVwTtKULKgO4Ijj0oe bqGObtBIvnQjqhszWnS9mry84EzDjfhvyTw2uNL7EYPpnt9MRMrW1PTckiJ+TlnkSYUUImHE lvxNpKSQD6ZB5g50duAb5KW+JN1PI0r6U7smKTNFucqEmuQYdR2CnElJOfonJgj4WVt0rTLp a04tJ8JlKpWKA1U3mlvlapjJPnwf+koyAMAkRUqeynYtO8iw/iVaOnXLolvuyKdSHJ2ppp5n aazLo3uGbZUHGtox3Kk4+xMcrddKBqTpB012x0939ImTnKVMvTLjJTtW2Hglwo/+rn2zGjpz 9LKqci/pkr81JUirKu6gsStNvSUTRZu8HQ48un7UKCQlKDgEbzyQYmVFqNoUzWWUk5Jr5207 MtZ1hU5cMy40woNNpDWxtCh5txVgHPCo60EZZjDK2rULg6Yq5a0hU6hJXxfdzpZ/w3j5dDsg 4srK+MqcS0lCT5jwCQBEv6s5mWTqFphpZYWm7FFVNvsWpNCmqO17xnELeKnB33IRyD6KMU4y ywlg6j2hKydIosrS6a0hplhpLbaEDASlIwAPyEP7U3tSE55jztaN5GmDsKmaj4SSVjgd+YOl 6nTZ4bUrSrHpGVxfYbe4pY8FKf3KUgH0EG+VX8QhTGR4IrqlpTaOq1rzNr3XR2ZyWmUFC23U 5Bz6/eOUvXj8Om8On+efv/S1p6o0RtfjBlxQ8WSwc9/4h7esdzpeov8AumZNRDuVj1Ha5HUj pQtKWQVh9+aUidKuAtTSQAAO/Ygk++YyutSlOrDpOP7xvrq7ZUOD5DR2Yxn15iyukcyUhr9Q JuorShnxTn7kcflCqXJc1g6Ma927elf0Fs+7qJTiHLddeRPvNnJXK7RhXbnB547AGJZ0PX81 R0GhqqKFoU6ShRJOUK5H+cVUjvgwFyjVq8pdLqCOeR9YKcC1Kyv0+veObYaVN1SJSnTipJbU EksqHJxjIMYhspCmKEwwlfbaMA43YjkdTVrG6hwYL+LfOqCEy6CAozO3H0AMc9p4hbpwMf5w OmxTQ18gKC2s1lpbhIwoHAiX+In2MG2XHgjLCt7v4uBx37w6UwrbqLGHPLuGT+cPq5TFQ5Oq vRPMzR0klhLELbU03kgcjiJNqNMIbuGl+OQFB4/iOCrj0jF0pW1SD1HsY3TqvkrgnZ5zO7aA n09PaAzUi3Lz8lNPNEl9BKlknHPaPeI4rJTSKU2/MI2MjjzH2Vx6xKaZT5d5tb84gqSgBI3n y5hrVokNL/Cy0oVc+rdW1fm5UGSoct8nLLUMjx3DyR9Q2P8A9aOhDO8ncQMY7R5bqMt1Zm6i vSHAgAeX84A4cJJSnkRz0MZgn4qfUXqnp5VzprKTxFDrLSGjKtJ2qeC+Fbld8fQRithqZqK5 uZmHENS7CNyW0DG4ge8ey0VOENPHZ3Rzqjbk7hj8sW7bpVT8MFQUUlWfwgjGYA1IqeccQhJG 45GFdzD5ClzYbqyn5CRUlgAkzO0HPPIhkXZdY1m1JbsGxZcOTzEqt1qXBI8Uto3KA+uAf0hb GIZKXWLt03utDE1LOyFRp68gOJOUnt+Y7j84Zr3q1zX7VZKmzdSWtcujw20OKP7tAPHH0gSx BWGpe0qaKbLPEvkAuOq7qV9Pb2gWkOoty6Y6iUzU62lsicpLwmGxOIK2nFD0UkY3J+kZ5ZCj axrvST4w/VDbdwImrqp9CrdFcUAumsy5lVtpzz4a8q5x6K4i87rXZPURWajqzYjjFeariENO olF7nWtifKgoPKVJ7H84XSoxpycl3Lk74CpKs6y6SUOnXOxoHTJuWk1iT+bYmkMTT+84CnUD O7aOd2M4HrF6zlyXNU7Blq3U6fIyqJdgKLaJ1OxORnJ/0MBUS3IG5zc6+db7j1qvE2Qq4Wpq k0/c01ISiQUoKhhROPxE88n0i7Lc68WdC9ALBszS+lyl33pSqYZebqdaSqXRTWzymXSUglzH lz2Hl9TAVIKWC4ysXj0UfE4uPWavrsDXuyKfR557cZKo0p5SpZ7akqKFb+UqwkkHtxGR/i0V aQvy95XWSjVeQcp9UCW5VuWmNzi2xlIUpPoSQfyitPp/Jk32ClPcUloQupVWgzlsMahopzU4 E7pN/OxWCFd/QkgROXbxtBmoItG/pRDc0AlLc0lIU09zkZB79o6kOBEyca2u631JVA6jKbRp GbdpEm5LprMn5HXm3CD50o4ynbgH24irqNrhc9Qo9u0uo1JQcotyt3O64sAvrfSpO4BffBSn bj2iNXuiJ2Z0s0k+IXoBetPbLleeproA3M1FktlGfTPIP3Bi8LK1WsC+JUTNtXRITyfaXeCj +YjjajTTjnsNjJEnl3WnU8KyDDVXbSqkspVVtiZ8xGVMKPB+0Yk1GXq4HJiW37+mWZ39m1Zt TLyDgpXE2p1SZnEBaFA5EBXo7coZCWRVwQMCI7f1p0a6qI/TqvJNuIcSUqStOQYXQm6c1JF1 eDiL8Siy6bpz1FVTTS05INUyTbbm22meUpU7kq4A4ORGc5WjVGcdKJeUWVeqQDHpJ+pXMy4H OX02u2YSHJakLOe4PGBD5ZVuVWy7nkq1WJJYQw4CpIPp9IqnFpklwdaOkPXSyeojRxdkWxQn WpqjSvhPNz5TiYynuMc4OccxTdv2bdelWqDM/wDsdUsy3t8WSC/+CSTgj3HeKirOUWL+Gbqt 2qtVq3pOps+YKbGcn1hUtST/AA4jmtWY1Mpnq+mWk6X1VZRuUiXcIA/iO04EYts5sM200t0h K9oKhnnO0f5xx+qK7ibaHtOePxZX0TEyyC551PlQOcZ9zGClu53JQc49c94Ch9M0PkU21ufr TSCPWJn8j9DBskeCH/uS5wnCgeT6QvpaFvTjYSoEbu+e3MPqcNio8nVXoWc8bTCXC3wEeE3h CT64iX6h06XqFRk5ptgF2XdK0rBweMHH1jF0v+aX5G6nEGRqq1ZJcekxgbnQCkHvD3dsotEj Iz7KeEbVApHaPeo4jJDbjniyzTzaxykcbuxiST1OqE2huk04OqO3xHA13xngD6k8D7wU3aJa ydPOh3RNvRDQCjUGalvDqM+j9oTxIwfGdwoj/wCUYT+UXK2dqsZEeOrz31HI3wVkCJBI9RHi zkY/zhCCMOfGBoLLcratwMSyFOuF5grV7gBQ/wA4w/WC5TrSWppGFuowT9T9I9j097tLA5tT E2AS8qZ03aZ3gFABKwc7cHEDlJ1tEtLPuJIKhyTmNMuBceSKXvcDrNRdkmUAJQfEQCeN+MZM HdF9yTtF61NOp1mZw5MVRUq8tSsbkusuIUf0P9Yy1ZbYh3NO/EQ6f6TfmoVvUDSmlMO3JUXE qU2hOxnZ2UXHOw9O8Ryo9L2h/SxpVUpzX2vrue+amwUSSaEwS3KufwcAE4HqfpGX9XTeFJXF 748XMW3tbd1T862+qjTnnHowvjjn0jSvw7uhq3NfKXM3Zqv8w3LBZblKWQttZSCQXlnjAz+E D7mF/qqcZcheYlED129F7vTHc1PqdhNvzlvVcKS2sErVLupAJQcd8jkH7xVFt3dqHp8k1q2J qr0h0gbn5RtxBVk8dhzB+dGWUyb75L20e6mup7Wu3ntHqq5Jql3nEpXea5ZaJ6RTn8KQnCVn H8RGQRFk1rp0uVrSNWnMpeNSmKi0+5PCrzUwta3FLSU+FgEAg8HnODCZV4J5ZXmJOxH+n3Sf TydoUxZ+sTVKo0k4pzfXlI3zaFNIJKR/0qIx94i9paVWVqteD1H0vpC5VqVl1TMzOP8A4EI3 bQsD0B9ot1UsvgvdbJrDSToF0MfoE2i6babqnjFPgzsy64ha/INxSARtGciMH/EylaPaurx0 atCjJlpS2GG2UScs0ragKAWjn1OFd4ZSrb7lp8MrfphtNq9tSqZb8wspDi9pAJGeeYsrrH0c ldOasugMJy8y3v3lXKO8a1NWsDKWbFo/Cg1hoV+0GsdNd3zypqZYllT0q2+oL3soO1wA+wyI iPxGenKj9P8AdVAvWzpdbdNuR19h1rcNjLyEhYI47KGfzEWppuwKZQtBueoyUwPl3VgnncSc D/SNF9LlyagV9yYsyz70ao1QqoG+pIZSt1vacgp9jBXTWSr2ydA+kDVm5rmoVX08v2uN1Ct2 nMIlXZ5A2mZaWgKbcUP5jhQOPURdslW9i9i18e0cHU00ptI2QldDTqXbIuCirrNFwmoSw8Rs p/jxztP3hFplerdTpbTy3dq+ym1d0EdwfziRXmUdr7BRdmT+UqSJhoKSe/1ijev49U8zotMS fSkw0quOHDilLCHPCPCghR4CsdjCNNGKrLfwNqNuODlVamn19Um/Jx7XBp6YrMqpTEw1UVFx 0qxk7lHPPML6DZ1JYnpySetSUS24rLbrGQUfn/rHp9qsYm8i2ck5e25Fa3Gwsegxkjn7RIen 2x7cvHVqiVS+ae05SJV8PPodGULSB2OfT6QmV1ewy+Dadb0J0s0W16oep2jgaoyaxIrlpuky CSGZ0EhSHCOySBnt3yIL6mJAW9M0vUmWlw54Dgl5tjgBxtR4Vn/pPP2JhNKTlZy5KasWHoTd 8jV7dTKyk0koz5EbslI9omjswQ4BnBHpGGqrTDiUf1qTaWdIqu6pznwVcA44weYyDazra7aQ sL3pwD7jgDBjhdSfqRuoe05t/FdnC9XJaXCc/vV8+sYddbdZyUnAzEoq1MfLkcbPeAq6Co4P pEz+Ze/nESQUeCEtvJQ6sLIxntnvDhRXSZgFHBJHAP1jRU4ERV2dTOhENK0tlplaEhaWkADd znHoInmoM7+wXZd/cnCluIIXwBlHH6HEY+l/za/I3U+xkAnVocUqfDhCGVBXfPc+sWiqRNas DypCVBkKSPyj6BFHEY12SmtT1Km5CiPlMxt8i9u7YPU4xF09INnVrUXXG1rHfbcmEvTKXZuY IPmaYIdWe34c7R7ZIhOqlspNhU8s61yjQbl0tIASAP0hS2R2OTiPHPk6KBg8Yx2gKlnBAx94 hZlT4rNrftjSGiV0oJFPqiUq9sOoUjP64jnpctNwPklubkNtlxZzwkDt+mI9b0t30sf7nNrL 1sSyMir/AGVuzYASQ2Dg9lEq94aqtOmk0WT3euMD6xsksCiuNSas5NV5KZbCQtGSVHGIWdL0 0Z3qItiXacG5ua8QOjuCEnBB9x3jk9SdqErF1PazowlTy1ieLh8THC+5A9odrYsqd1KuSWoc qlpTy0k+K+NwSB3JMeFop1am25zYXlKyH+udPUrRZySlU1uQcanHvlvGS2NqXOcDH5GHyi6G 1y25CYqc3NMsIS+GEqGQp7JABGPTJjqPSuPDG+TJSvcUXT09XRVKrJUKqOMzaHELc8d1JU21 jHGD6nMVtdOntNo10OWdNyEnMzEutKPK2MJUvGAP1jHqKEotO/cXOjKDySWodOtUtGgzFaaT S2HG2/EWxKIwUJ78+5htuK2qpaFRZo1VqDTjrraHEBs+iuw+nMMq0ZQja4105RxcU1/p3q0l QHq5UKVS1pS2p5bYBW4B35yO8G250716lUNy46fSpJgPy+5cs15VrRjODj+0H+nq/Iflz4JX b+nOqtUt5iuSky0wwpre0yZhQWU444x7RBJfTKQv69ppmatqRnKrOeda5lIJWUjHJIPOBiFy VZSUW+RM1UUkr8iGzOnGionVXJQrIp0s5LTypPxmG0pUl3fg8j64OYkd/dKUxcc4apeNjUid Ln7suTCvEcJJ7ciNkY19llIp0qrV7jVKdGlF0kqhvS1dNKfTp5CS0qfpiQlxKFdwSMcH1hx1 M6ZKhftvylZvy0WKvLSn71EtN4UUZGN233wYK2o223BqlVirMjQ6DrOXJszydF6OGXEb/UDH fkZ5x7YhdaHSbJW00i7rZ0zYkvCyULR5V7c84EFGWpgsyAlCqhzs95Nj1WfqVvSwlZmoKCpl aOS4U8DP2iYS+pF0LmGwmdCgVAHI7gkQmlqqk5qMmJpayopqFy5KFUC7TUeI5krRzzFS1OqJ 031eXRlkplK3ufaKidqVpA3D8+D+sd3TRvKUTu/cty1q8l5hIUeCPeH2fmd9LcKDglJwfyjD VhaYy90c9b6r1cua9q7p3Q+nFm6HZN9UzPVcb/FTuUU5OCPKCIi9Hsem1OnTrE3Q/kpyWSS4 2k52nsPr/wDaPVJJqxkfJEXNKrh1EuVm07YozszMvdmkYGcEfkB65iVWJ0k64Vm8H7PZsSYk WGR4E1PzTuxhhKuFKSe6zt7Y94zVJRhe7GLJqSoy1JnNRKFb1NbeKaLKhkPKGQpKcJAz78RK dQLIp+oNoT1q1BviYaKUqHdJ9D+sZm9rQVsGd9NNQKhplVBb9VmPl5qWcLDwWrCQoHGB94uu U1zkq81MW9RpyUNbSwVyy5lZSw8v0QVDtz3xzGbURvK4UPgwx1X/ABC9VxdFS6b9ZtBGraqz b6ZZ1bFQMwkoWPKpJ24IUOQQfWPLXmim3W1S7SfDCNo3K7ccGPNdQd6iOjRjaJzK+KHUnnbs YbX5kla/Ke/fvGOZgpdR+7B7+sNo/TQcuRdaUsX6slKiElPrmJd8g7/z/wCsW1dhR4IYpO99 QU1j1zCyU3tTjYQOCRggw6r7RMOTqV0ETAe00QjAKm2EDMSvqGfLdAYClc/MDYkdyCCIxdLf 8YvyM1P02RWneDM26/T30q3FGMpOc8RaunNUTUrCbl0Y37NqgfTjsI+hpZOHfAn0rb+UFYmH l4S15NgOCkgxv34W9g0mYNc1OmZVlc6whqlMPBIy22EhawD/ANSiCftGDqTtQY2jmRtBITsy Tk/eBheVeX+keVN6BfUR8eeVY4iEbKs6xrUbvDp9uGnqYC1ssfNN5TnCm1BYP9I5JouB6rVO 75IS5SuntBvxiCpHnP8ASPUdGzQa+5g1HvuP7VMk06QfLt43BtAI5wU5z+vEVnftYamjKSLO CWR5uefpmOnLgUiCVKSXcFXmXt37uWTjOcHENOml1vab6pUi9GloSJSaSpSDnGwnaQfyMcnq EN1CSJU9rOnlKq0pVaJL1CXJKX0JcCvQoIyD+cTfRGuyNC1Dk52ozgbZLbrZWThOSnj7cjvH hNK9tdXOZSaVRXJJrPM0Gk6eNUi06jLmotziZlt2XP4VbyvJx6k9/vEh1KvVmqS9rsSVWaU3 4jT8022eMgpxk/Q5jr1KsW2kzU5q7VyeVHU+1ymZCKqyVsOpaCgrvnHb3HMZ71NrEuvWacrU o82WlTjDhWBkKSkJz+mO8Z9XOLUbPuXqJqbVmTLUm3qbVJ+o36b+8GUmmGkiUYe4dKRgA/Q5 9II1MsOWuq55a95O5pFLTMuy0tpS8k7FbuP1hs4RkvcXKP3Js7UrMnpuvJRXP98VIBDiVOZQ lODjaO2ef7Qrk0UdVl+BV680pCJLHzrawFny98CHboyTsx2M2Fdi7TYkoxV7jl5pDcrj59se Ee3Hl9OIrDSF1trWOWd+bHgEPp3ngHg+Yn8v6xmqWVWBnqfUiTeTrlozVH22w2GUJrYS8k8b nPF86sfU5OYcNUJOeqFQp09IOoQ2xOtLeWHeHEhXIxG9WawP7YH+4rjov7PqzNJmEPzMqE+O 2pzhIP8AbiE7zcx+2J25pqqINIXT0obaKvKF8kq/MECLQcuRNeap6pWMliiIIfXLHw3kr2hB xwT9IHQxWJm0WEVSZQ08JX/3thWUE49ouftYqpez/BQSUqXU5kqdC0+Irz84OD3hXKuqXPsI SPMVDH15jkafNVHEpK1RF10CYeakWCVY8oiF9TlpvXHaCa5SiU1ClrTNMLQcElKgop+xAx+c eqo+mqmel7DvpLd0pXbblapKuhSXG0qGD7iLFkqgmZbLaiCCPeE6mnaQcXgxP1Z0K37R6kG3 BqBclEYqbQfmGLdmVsF/zchW38QJHYw202q2s6qcFJZeS3MjAfnNxcWP5lE+vvHdoeqmn9jN J5FOj+rdraL3HVbgckVTVQdlizKNIBIUrd6n0EaL0k1VNzaHzeqN1zDEmp8r3vE7W0gHAOT6 Rh1tK0lL5sMg7iWwUSE3NqriH230ujIeQQpKh9DEplFAzgcQobVHtntCqgaM39ZulppNxC9q ZKhCZkBS1pRkbwe/6RD9CaZW9Tr6lHXp5Ehbdt/+0KnUHVhLe1GcoUfQEc+/EIm7rIcUYc64 9YaNr31zVC+LXqJmaW/NssSjq0kFTLSQlJIPb1x9CIvG051pughl7O0IJUQfTEeY6j9Wx0qX BzI+JvOMu3s1swFZUMj7xkpW3ZgEk+uIdSzBFvLF1pqxP7E+o7kxKdqvb+8R8hJES3pD6krc J2n1hTKvFU0lCCeSPtGip7RETqL8Ph5v/Zi2hwkOBpHCfQfWJb1IofetBoNBIUJlKTjulJzy D98Ri6X/ADi/IzVYpsiNkz/izvyDytyVpGQB7DEWZpDMLpVSnKG4g7h520udyD7R9Ftk4CeB 4suUEmqsMuBIU8/5E+uce0dIfhaUByj9PjtSmGylyq1WYmlA/wAOdoA/RMcvqv0TRp8s0+nb sHmGIEnCR+LmPMM3I9xzwYGDlJOYhBi1Ep4q1l1OllOUzEo62R90ERx8nKOujWFVZqqMhM3N vlHIwOCcjPr29Y9J0PMJow6n3C8Ntf7Ki14yUnYCc/Qev94z9cDpFUc8BeMkjPeOxPgTDIZZ TUpNyE84+gFWdhGe5A9f1ivb4k5iUqbypgpSo8bEjASIx1Yb4tFv4NDaafEYotiWNS7SrloO z0zIS6GC+HyPFCeAfpxxEja+KLaBbSoafzUuo8FHjbh9Y8lPoNXfujJGJ6b1XTPFfFFsdrdm xKkraMhO4cc+ueDGg+njqu0A1jtgVaoatUm255JCf2bXHPCcdPuj+YfbkRX7HrJ8lSoN8E01 D1Q0hsK1V3VcGptPckw2pbapZCnC9gcBGB6/WMuzfxMtJVguKtKrq3KI5I5Tzz/aFVuj15PB I6eT5CWviY6O+C4XLerXP/KAwR9Qe8DY+JFoo0UFVGq6lDAyhIyEwr9lal+kb5L+SddO/W1p RrfrXQtIaLNv0uZrzi2WJurKS20FhO4IKu25R4T7mLF6idZqf08qadvNid2uP/K/7sFKwScD cPQZHf6xUOl10tvcjpSTGak9VtozOJZHzHhpRu82diRj0EWDoVdg1ytuoX3ZkwW5aRmVyhWs kL3oGVgCGfsrUJpsF0Je5lXVbrU0ttm+KhYlQrU+1PSMwWnWm21lIWOc5x9e8OVa6trdXZT1 yM1udUyCQyw4VZmFA8+bjAEbdJ03Ub/XwAqckyK2X17PTdzFV22/Ns06YGFTkktRUBjjeD3/ AKxfdqajs3jQET9EuByZlH0hXh+MSkD/AMvaNur0M4tbOC5Rd7oYdUeo6h6SyrQvO8puSamF htvzqKSc9uOwhkpfWPppN01NOlNRnFMKyVy4ztHfPMc6Wj1axYW41OxLdILwouqrE1MWXOfN tSyvDWtPIB9iYnshYtxicYfckglAWMkK9MxKPT61OaclYXT0s3NSLYk21sS6d2B5RxBNflxP Uh6XUAQtJEduLtJM7SKY0UrrtqXBU9P5l5KV094rbSfKPCWSU4+ncflFr1XWKx7GlEzV2XRJ SCVcJ+ZeSgrPsAe5+gjTqKLqSsiJmZNees/p0vq9GbRtO16pXrnfdTKyy5NgYSpRAAJJz+WI oiyuoCu3FfNQs696QhgyUwuXSWu42qKSD9QR2jbQThBQYqdr3J1PUREzNeK3/CDgtxL+ovq4 s/RbQGg9Nln22zdl1XL4MiKY2AtlKnVdnMe/Yj09cQnVxcmn8BQZofTbSGj6RaaU2nU2mt09 KGAt2QYcUptlavMpKM87QScD2hqkdUac/cSraobvzEyhQK05PkB94x38xOQxYJBrJan+LtPF ys4wHlbclI/iHqP0jIXV7aFetT4b9fVphUZinppNWRUKqllW1yelSvw3Q4QM7U7myPTg+5jL JYGReTmJZzj83qbTm3FKWr5kElaid3POY25RmW26EVBzBKDnn3Eec6l9Y6NH2nLz4lT6BqO2 nYAAlQxnjOYy0ZlJCmwnn3zDKK9CD7jhZR8SqkhHGO5MTHH/AEiI3ktEImFI+YIx39YVyTZV MthGB2yY1TzG4iPwdO/h8uJTpo260oALZHc88KMT7Xsh6mMpWPKHkqI55wDGLpdlrV+Rmq+m yt7bmHkXSztIAcPBzx6RZa6g9Qrqpk8y3tQ9+5Wv0Gf/ALx9GWbnAtgn2nb7VOuWsVarsocl WmgZZtXbxCPMr8gP1MdWukSxTp70+2xbbrYS+JFDz+0d3HBvV/VX9I4vV5WgkaKCsy0kKTs2 gce8DQsZ2pRke8edaN3cHxx5PX3gW4FJz/QxRBNUEpdlS0vsoY5jkB1ASgt6rz1q+CUGn1GY QoE+Y4eXjn7Yj0XQ/wCtfgw6nkYbhn107TxHiuApdQoDP8Qikg+iccnZtasJTuwY7lRGeI6a Q0VybtuZrfy4CHJhTYeWeBgegiJas0eUZmy5JFTgKfM8vtiM0lgPuVLUphpM0cq8pGBjtAU1 JjwStflSE9ye0KaBtk0Jof8ADr1o1ot4XHNVSk2/T3UpU0qquKLz4VykpbSOxHPMTKsdIuqv TJJocrjNPqEss4RWZLC0AfUEZSYBQswkrCHqeqVZpWjFNkZ4gofSA26Cc4PH6xl2XRNTMwmU aCnHFnASnuYGpll/1EspujVWewmfr0lKzC8bZFxZUsk+5HAiO3hbdZsyprpVZlVsvo/gWe49 DCoonA1N1VbOxxl91t9tYWhbKiFpUDkFJHOc9sR01qVF1u6q+i2nUbV63ZdjUelYRuCgVz8u kBTS3wn8D+3AV3BwCcHMBKPquF2KvsmxLslHpu0rht19moSrO5EoR5iNuSftgHmNW/DklJaQ 6YETakBtVSqE5MFKc8efYM/XyQe25TV1Ywf1MOyUl1h3tNSLxXLMzKG1rJ7ubBkj6dokd6pm K7a9r16h0pxilVOSSllhed/jNHY6cexPOY001YU1ZmoOky3NMLD0ukJm5NLriq793KdkRNMy HjolVYwSR+JIwc5iuelyq1TSanXrb9fVPuzVrzokkyK2ilbo8Q+cg/h8m0/nBxi23cm1NWIJ 13ar0K+6RR5amZS7LzAUtt3jgg8fXnEUdRanPIYLRaSjPAUBiDtYFq2DoN8NG5qVMaVTMnLt pS9LTim3ewKjgEffiNZyE4ysBXGB7mMleOWOprA6NqbmG/KRj7xDtZNXrP0etdVXuWoIQpw7 GJYH95ML9EIHqYzU4Oc1EY8GGdeeqvVKcua3KJbumFVoNdusqmWUFsCYdlkLKTjOeMng/WIP ZVZp2turdxaga/Wdd1Xti120yyzKeY097BxuPZPbv9Y6l/gVm5Gen+qStu39RdR7atmfbm5m 4VTEpXakkql5aUQogqUeSdqecn1xEr09stF4yd9awW4+w5TbYrymX5jcQ5NeM6SHEj1BJz9I tNRyySVy0bMN23667QbBozlSmm5dbikJIyhOMZJ++MRFPh6aHu6zdQ9X1J1Ftx80mzpgraqD 2QhU4knKQT/IOcemRCNRLDCijW14ahVesawT1z03Vq3mbdYpBlk29OvYf+ZDhw6lP8QI4h40 ZndP9S6Q7MyNepYuGWV4c45IYCC4BngHnGIx3207IYuSwGKVXmKQZWsLQ8DkB1nsRFIdWj1o 6e9KOp7VzhtVNmKDMMFtYGFOOjY2nn1K1A/lGV5uMjycVdNGvE1YpSC4T4bo3N/zEDn+sbdl ClVsLc2qI8MngnnjtHmuofXOjR9hyt+Ii78xqgWVfwg45+sZmfDbe7CfN2h9NWggpcj1ZJbQ 8dqefeJT4q/aBlyQhj6Nz5QrBx65hZJJQp5sLXtA9QeY1vMRSOl/w+H0TOmjQQBtSzxj794s XXBqbXR20pxkvJG4EnA5+kY+mr+NX5G6n6bIAqSTT36fONqx5wVZ/rFn1STM7ZCZ5lsLcRhx Kzycj6R9GguTgNjvIXS5L6fzcyiQ8aYmWElABwEqScn9QCPzjs3oxWJWv6Y0GsyhAamaew6g A8YLaTj+scPrCwh9FktTnuIMRtzt3flHANiYZuBxg4x3jzdnsf0iuCmET60Jlj5ucH8o5Jdf z0panUrWrXeIbE7UtyTt7+KlCs/qTHd6J75r7f8AUx6jkqzWaookrel6XJq2obRjbnH1ipJ1 12TtSZqCfrg4/wDXMd+aMyY+6LzlXmLQalZPe40oqJaPYbjyfvBesU1LPUMUiQ2rmCnK9gyr j0hEkMuZ/qjUwiZUhTONpzzwRHlMVIGclxUWQ4wt5tLySraCgqAUMntx6wt4IvcdLtRLO6qJ jwZjTOs0qn0NDympZUglK3lIA2N4Kj22beMcw3Uu6dX5O2qpZettPl6qmoS6pGXdmpf5d0Oc bVbO2QRnIHaK5CZnnrouSUbp9Is+XPhOsnDgGfLge0UtoLT/APEOsVBt/wCWU+qcmvCSlBwp RIJ7447d4VUIlk6oac9Knw066lAomkk5VJ915Eq9POCamFNvqGSFOHA45ORwI58dfWmdz6bX 9S5C7JFMs41LvybPmyqYQxMuIQs4/wCgox9AITFv+okooqXR22pOs3o1Wa4FmlURaKhOJb/G tttaTtHtkgDMdI+nqldV3UtcM7rLpteNIsSjvPlcs3NSRmnHP5RtJCSkDGfWI7XbZceAzUS5 taNO+pqlWjr0iUnXq9TX5Vi9aRKpYbYQELAU63yBySPzi2Oimi1Wg9LFrPuNbpWdZffZeSc7 0qeXjJ9wMZ+uYJWsizD/AFr27S6L1PT4lm1E1OVTMOqBwAvJGcfb+wh16ZLot1iry1rXVMpQ uTWqZpbz6/3anCnzNnPABHI+saoiuTYOkXUpcumknVZ2+5BhugN4EiyjAW24Rgpx6kmIpprc Nu68agagXTT5UNPN1QMzUsQAtBS2lKSQO+SlQyfaJCCjJyC7JGV/iNWxLWhVKUphrw/Fe7jI IwCYg9n0SVrkhLiUfWtS0gBGdy1q9gO5OYZb1C2a96EpD/Y9S621dUyZR2qvNvNyrxwpASkj JHoTnmNd2XczFXk0vSz6VoUO6VZhNaFh1PixLpOeS2n8QAx7xgn4ilxXbqd1PWtpBZAdXWXm 0GjZz4bS1LIemCPXakd/pj1hNGNpOQUuA/WTRCu3d1/0GzGtV5qWnpGzDU251SQTLvpKgpCf ZK1Ng+8Qrp7sS85joO1s1KN+KYl6y/OraaWjBdXLjCVlWfVW4fUcw7ddZQHcjtqaaar0al6S 6eC7Q5L3VuUmnsgILbC0blqUr+XA/XEIKXfUoK9VLXt1lUhJrdLT0lLEht1SD3UPU8Z5gkwX kk9ja03ho1cLgt+6xR5arAS8zP8Ah+IttJOEkfniIdZ/VdV9E9JNUNB6dOTy5m45n56TuBh0 tvSq1ncvuOQoEjn/ACjNXsxsURbXur6fAWJc1n12sLmHpVtc9MzLisuuKTkhB9RmE2idzIlr ruemtzlyu1ItKelDTXXAtnycqOOO3MZ78jErmz/hmfELN32lSNCtRKXVpupSYW0Ku8hSkFsK wAtRHceuYQfG0uCYo/TNIJtZ4rkKtXWETqs7kqHhuLQM445RxGeStcZDk5X6Mb53VqmNK5X4 hJUT2jbrb6Ra7yUEAeErP6f04jzPUPrm+j7Tk98QJ/xNV1pChhKMbB6cmM9OABKlFWRGiHsQ UuWOtoh5M0HZdWQPSJR85N/8sf0/0ipLJCKuIUJtWRx64MKJRTZcCUt+uc+saOwqPJ0d+H7M r/2dMoaBCQ3genrmLe1CL1Qk2GmUlTqnRhsclXuIT0ilOtroxgrtsmuqwoUJTqOyRHK/Z9SV baHRJq8ZK8hsEE4idWLJVidt6Wp87JOJSoYKVY4EfWF0TXQzKmzxkOu9Oq3Uay/yHWxRatML NKclXAS0tCBxwSDj84686F3tYNsaS25ba7rkUqkabLsELeGcpaSDn9I871zpmqpKKlB/4Olp OoaWtFuFRP8AuTQan2Hgf/mun8+zyYENTrDH/wDlUjz/APzkx5p6LUf8D/wb1qqP/Ev8hh1I sdKQf8VyAzzkvpgw6i2SpvKbokT9nkwP6St/wP8AwE9TSv7l/kSTOoFnzSvCRcslz6+MBHM7 4i9Ekq/1kOVaQZE3LNysnMIdZJUkOAKSTkccYGRHd6Jo68qziovj4MWr1dCCTlNf5M966SdW qM6JWSk5h7cM+Rs5EQLU2iVmm2XK0ximzCnVgZShGcn6x6SXTtV/6b/wYP2jpIrNRf5B2RM3 i3bMtRjQpmVQ0gb0lBBP3/WDK7IVhMuqYTT3eBk+Gkk//eM70GpXMH/gauoaWWVUX+SrrgtO 4K5V0N0qgPqdc4CO2T9ScAQ+2NolR3Kmh/VWdlWqc1lTkgw8Vqmsfwbk9gfX6RgqxcHZmyEl NKUcmpKt1Bz7i3kVREyWH1h2SVTllKJdBSMISBxxwPyhnsnqJnr41/oFXvV516m21Kql5YOH cN6ydyyP4ldgCew4hYxlNdaVLrir9VOvIcUh8ePu58gV2z9xFS6f3bcFiXxSrqtbipyU02uX bT5lOL3DCQPXPY/QwE1dF8HU/TnrFuK26zI0x5bUnIzEu24acQAoPKAKgVAd0kkfYRmT4pFs 1HWnWqo6t2DWXq3RaZKsyfgsoJ+SVjcsgDkpKyfNj0hCW1lyyZi0r1Fquj9cnn3KMxNylVlV SM7JTrWQ6ypQJxnsoFIIPvHR7Ru8dJ7Rott12qXfcRkqlTg2xTaZNqal2kOpwlYKe6kn19CI prkpcEy6iZixE9O8ozQG6vU1SqlMN1OcUp9bA27iXHSCT6AfeMDaM9bPUH0d3dPMafXGajb8 xMqW9bNdK35B0k5UW05BbUfdBH1zBbdySKba4F3Uh1V2h1L6osasWFp7NUJ4SoaqFMmHvGba I7qQvHYn35hbp4HnqjTrlvK2EytOz4ko4VFBmnScIKQe6QTnI9sRpjdLIPYv62rep3+KTqLe K1TU5JqC0tglfjKAyFbM4xjBJ94pnR3qlc0J6iLlvYSbkzJVt5xuckwvBWFLCtw9CcpGPzhl 7FLsSDrCuKg9WFuyFb0jnlPVOT3vO0J8bZhSUpKlAHsocHt7RE+kuw2ahIPa8U+rBlikbZWX lpjP76Z2/vF+21AIx9T9IJckaNnVWxLOr2j8tdEhdck3VpSW8Z7fMpStzjPP19oYOlrU2vW/ ciqdNzqpimzXbzbvDOeD9s8RJepEi7NGq/24y7IBC5gN+KAlK1Hjngf3jFU1dIp+v2pnUHqt UWZWY06kjTLXmWVHwpiaU2VJSe58xJzjuUCM6XNhgwa0tz1M190q1S1ZmpukVm57FW7UfDJ8 zqHl4Htyl0H0OBEc/wAL2ta3w0p+7aTqVU/GuKozTCJEvKDG/wCaHlKTx/wz+fAglLBXcjF8 3ivSG6NNrp01v5yYqklTVrQ5Nq3pYWoAHag+gHH6wTbtEmaVen7XfqrE27UszDqmlDCHDgmK RVskkrc5LyVZp1WqFJRUWmp5lXghIWHE7xlOD3z7R915ai6WXTrLfs9ZenjlObepEtKiVDAQ ZRzlSl4HAyMDj0jJXvuHwQ09R/UFQL96atN5Wh6NO09VsOsBdZdbbxOYSpKk5SBgEEd/Ucwd 04a7XDauvdxXnaGkrU2upUFxKqY6nchpBSAXMY5PGYy9nkYkhV0eauz1pWNWZ6clJamSdRqB lDVXEgFkKXkjPp6iLN1Sqa+qPoz1dsGY3ss2M5KVSjPzKVbplEuFpKgT3BDhH3PEKmxkeTnL oY4HNVKcpKVIWD4nIIP2P6xs+Zmyq1HiEcBo8d+8ed6jmubKXtOT/Xu5u1fmAhXG3J5iglqP gnKuPpGin7UE+WP1jt+IlQzg5iSfKq/5gipclxV0ReYUW51eMZgyVO5xOOCTyRGiWIiY+46N /D1WFacoaSrAUxwvnHCu0XZVXSmu0lKGjuVNAlOe/lVG7wfnrFL/ANxw/F7t0is//wBWePpZ cwVHtzz6wZLFaFBTbpx7bo/U79tmfjGdWSeGLaY863OBDayMcjBjRelHT3qZf9lS930Wr4Ym HhLIaDit27/SPOde11Dp9ONSsr3wey8L9J13W5Onp52svknVw9FOrtGl5Z6WvNt5T7iWlJZc V+7J9CYaNR+l3VXSi1pu4rgv+VLTKc+C2+srP5HtzHlNP4k0WpnCkqeZOx6rqPhDqnS6NTUz r4j92VDacxdN03VJ0CVqbgemnUtIUXD+JRwMn84vOmdHWvFWqc3JJu5ppMphK3331JSSRnGR HR6t1TRdLmoVYXdr8HP6F4e6t16h+oo1bK9sthDHSf1CtzFS+XuTLVNT+8CH17jxnKREXrXR prXdFzytImKi2qZmZf5r5h9xQDaM4GTGOh4m6bTk5xja3/Y6FXwJ12taE6uPyxomuhnWNF7o sxuel3plTXjh/wAQhsJzjJMQLqD0Au7RidYk7weZc+ZH7tbStyVY74jvdP8AEek1uohQpLLV zznWvCXUejaOWqrzwnYrUPuM+Rp5QB4/EYKW460sKQoqOeDu7GPS1UlCTfweU6bVr1tTCmpP LXcheqFzS9FrbdMaV52kALUDjBPOP6xH5516pslbaQFKHG33j4Z1Caqamcl8n636bRdDTU6b 7JG8+mr/AMHVifDepWu902HIV+4aClUjONVTctT9U3K/dkH8QPBBA/Bz6GMMStUqFPqbtcmH 9j8284+4GhhKCpROEj0SM4A9hHLpuTvu+Te7di4qBSLY1zsKc/bb7i6hVGUyDs6klRpjLZC1 PHIx+EbQM8lQhTKTmkenikTWnel9KZEm34UvPOy4dmCcYK/FVzuJySRiGsn5JNcOqumT/THQ rCtKx0qvRVRmZqsXQ/uCm0KcPhtoycEqCsH22euYitl3bP2RMpqzE8RNHalKe+4Zz5vQj1wY Qk17gn9iTao9Niuqxi17nr6JK0qjXp4sS9d8FEqxVWmwfGVgjYNpKcrA5+sWVrLpNprZ2kth aTdK94yVwJtdmapzr0nMfNPuTHihbi3Ce+VEkemBxC3K8lYllyWB0kdX3SzLWaenzWK65SVq rjLqZk1MESjqlHapHijICsHHOPoYzTqd01/+KqyX2elfTFlMzaS1pqUoJrxHHEqWQjw3FfjJ SnIB5I5hkE4t7uCpLGDL+k1hVuj64SWnOoNFflGV1ES1Tp8ygpXtQrKkqB9CBj7GLUs6rVHV 7qgptKZbQ1KTdVUliSUrazLM7vKkegSkYEaY82FP4Lc6nr/XolJVC06LXZacqNST8uXpZJAY a9cex9IxdPVWWROu1BqYW45uJzuzzFvBa5JfofqJPWzqVSK8wclmYQVJByFDPY8dj2MaK1is aU0C0+ptq2hUUTVOEyl5xbaylBRML8U49iEqAx9IKJRYaLr6P0UuqU6V0wqM9Ozko2mVq8tP OFuVXgEqUCfN27RFbem2KZXku2hdIDOBllonDQzkZ9xBZV7sH8GudKLxk7x04E3eFWaZYkm1 odfKykqUOU4PpGOL/wBFdTbtkpu5aXdaqhad0X27RvlFIyEPNNqcZeJz2JBGMf3hE5KLyNWS babakX7f+odVuPqUtN2q0W25Z+2qdU5djc0h1tONoz6ZSDnvwYS6UVa1NVuiW5ukmlW09Wbq pdTNSlZVlkqYbaLyHC4XE4CCAFjH0HvAcJKJdgVqJ6dtYOsa16PTdOpqfoFuUlcrVGJenOut szCkBGHAkHJCsn9IrldlWxpzcNZtKl1J6ZdpFUcbl1TKjuUznKMgjg4OCPpBJ5Ltfgl9gydw VjUm26fbNPl52bcnkOtSk0rCHFA5wYh2vUpq9dnUTqtJTFnystONBK51haspaAZQoBGO4CVJ xx3MY67yNghvq9ga/wBxdBshdUymSct6Um0iWlkD962tbqQrI9skQ96R6Q6lruC+a1KajU+n rtyittPTB7Pb0Z8MZ5yOO0YHNIekV9TafKUXpLo3+Ja+pTtcrf7RZlQ3tQsJcABXn0OTFtau Pak2t0x6ia3Tt3orDVcZp1CDcgQ2zJt7jnCB2Tuxn2yIXORaXqMWaCHx9V5R1WAUqVlIPvGt qrMtC1XvKDls544HEcLXO9Y2U+Dkt1uzfzOtE+N2e2QYpV1xScbknBjTD2ot8kjsZKmyVHsY k+5PvC5ckSuRCYaSqZKcgqz3zCtlv5baQRkntntGuftFL3HQX4fM6U2EwlwDJQoFI9RkYi9q 5OLRc1D2IHmnkjPbbwrtG3wd/wCc0v8A3HC8Yf8Ak9f/ANr/AOQal0OpLf8AL6x614Yzsz9Y /VNrYPxdJE30Mtq17r1Hp1Du+r/J098kOTAOCnjj+sb2sGsaV9PtmUezZW82J1L1S8UYWMtJ V6mPmvjT9Tqa0NLThePN/wDJ90/2dLQaDRPV1KiUnhq5JKhqDYFltKmJm+5eaXV6q2622lYU GgSP0AxEN61q5a12afPzdIvCm7WfMptlYU44MdsR4/pelr09bRqypu1//g9b4o1Wm1HTK1ON RXt8lTdJejumt1ykrfdSvVqTqVOmwtUs6sBIQk5B/ONFTGrOnl5LrVs0q+5WSfanG1CZU4Eh xIwTj37ERt6/+q1usnJwxDH9rl+Eqej6f0+nRpVLuWf79xxp/UTpZKTVfn2Lpk3mJdxlhxQc GFeUAke4EAvLU7StdwTi37plxKCkYW5Lu8hJJ4SR6xwYdN1UZ3UHn/4PSPqWkWJVFj7kaav+ zJy+aG7bl7S7LQpS0hqYUCHhuTjcs9lf1PMZw+I5ULSnJ2kMUiuomZwoUpxtpzchrBHb2zn+ ker8NaevR6pS3Qfe/wDqeB/2h6rT1eiz2TTu0ZYRh4eG2Ruj2SMtI1Flc6grQFjKB6+sfUuo ycNLUt8HxXwxR39UoqSxuRROpVYeqFZnapMkB5bylnB4HPA/IQptiumZpyAXTkJEfC6rvNs/ W1FWSRNqTQNQ6jpFUbvlvmlWzS55DcworIZbmFpUU+XsVFOee8V/c12JQwiTYWAp3jefT3hC YZoLp6+btXRet02oeG9/iDw1JaJO9lts5K8+m7sfoIlljdMfUNqVp41qFZGlc9P0d1ajLvpc QlT6ASCpCDyU5GM+piNqPJfc9tvps6q66h+3qf02XAhXjJcL0+0iXQQk4wHFHGDnP5Qyylsy lJ1BVZ9dwZx2dEg7LBW7w3CvYUj3IOYW7N4ZZZ3xFLppMpI6f6V0yZ/3a2JSbliyVcIOW08D 38pjLtHrdXtetprNrVJ2TfWdi32VEHYeD/SBsk8Fh/yNMYm3Jlk43K3EqPKsxtf4bF/25pho fVrqYmkKn67XltOMg5XtaQlCSR3xyYY4b1tKvkifxYrdt6263p/1r2JIJFRXPfsOtJbTlD7a mFlhax/MlSVJCvZX0jK/SfcVrs9SFDn7uK26UwVrfCFc7cdtx7Zg6aaVmKfuIj1ManTF237U HZZ8qy4pCQVZ2pBOP1EVLNza5Rj/AIh3HuIJ8hdx+0zqr0hX5OoB7JQ4Dj3GYvXU67qxWpRE m9PbmplO4MhWdh9AItFW5Gqz6rrBa0q1I06VB8PzoU4g557feF1uTd32VUnLmuSTeQuYWDk5 CcZ9B6d4PlgwTlhGzLc1Eokt0QsVWaor6hXa4JN8scuMNpwtaxj/AKUkH7xCtIpahI+GHdF+ Uy7nJarSVyTdep6ZhzlLwebQ35e/4FLAP1jLUvf+5sjp6mMDN0dzuol6aazjlNr8k9MXJcs2 Eyc0rHjLdl1kr78DKRzjvx6wn0qqV01i6jpL0n0N9FwzDZauSrtKwlhkqwsk4x7DGeSBEI6M k+C8tTbjonTTabGnHR9QzPX3UCPnVy7u51k4/eOukclWR/aMo3m3UWNWJWuTM3N1CdnmN1Um 3s+SYKvMPt9TzEjHFyo05LlEt0nuOp0nXCzpilVQSTiKo2HJwEbmkE8kZ4z6cxHNbK/fMj1e 6kUy3L0CZSoNpWJiaCfEca8PCULwMFQ2YyO+BGTUL1DoQdxLRa/dlH6TLaply6sLbla9VHfC pjY4abaXy4ocDKv+8V/p41Q7mmbvn6/fFQQwtwtNpYdX+9GMcxzpLkftslcZ7rt+p1Wi1JaU r/ZduS7ex1cyEp29ykAnOeDmOgOtbulavhE1WrtWK1R5Cp0FlTMmDktvqKA2vcrlRKkpPPoq FSWCrepHLLQlaDqq3jahaColKDx39I1ZcrrTdpTKkEH917/T0jiaz6xqgrJI5LdZLypzWup7 uNhAAHqIqYjLJQo9/wCIxsjiKB7kgs0obZQkL/i7mJL4p/mELayEsEPmQtiZUVE5zwIHKPeO 4XOxH1jTPgUvcdCPh/uZshhQQlRCVd/XtFy6j17/AA/LIuFLKV/IuofS2okblA9s/nE6Bq3o uowrJXszL1nRR6hop6eTspKxXyeo+dce+WYtVtS1qwEpWc/aHql6q3JOOJbmqTISfqovPFRH 0wI+9f76Ta9NNHw3/wALdJfNVimd1kuS33lzlMoMvUEt42qaeKdx+gxmBOdYt0tLQmftMIWn +aYUSPp9IXLxXGrZyphx/wBm8acdlOrgWO9bVxONhp22EEp/CVzKj/lCSd6zq7NZaetpJJ42 pmVYx+cLj4moxf0h1X/Z7Kovrf8AMcbJ6q7yr1fkbOtG0G3Z+pPJZQFzSkpST6qI9B3JMS7X W56Db9Mkrfp11ioXMxNuLnpynvlUo20UDahJ9VBe7J7Yjm9S66tbF06cbXPRdA8J0+jSdRz3 MYNMNXarRbUr9QmFCd+S8NTbS39oAKsK2juTCGc6zJ6bZLCKC42nGCFPnP29o0aLr8NPSUKk LtHO6t4L/X6l16dTamI19Xk62UbaI6kp4TtmVK49z7Q11jqlmq3NbnqEtakjCUePvKvYDMb/ APeyjSe5UsnJqf7OZ1lslWvEta3r4sKnS9DFv0pyv1+bkBMT8ooKTLyLxJ/dZwN+E4JOfWPr y1goL9QVT7l0kTR2S2EqnKdMeK4y5t5UU45Gecd44Ws8S6rUyl2TxY9j03wh07p1OMIQ9Szf 7lNav2PZFMpjdRtDUSWuETKVLWWG1trY57LCgCDEKtuacp6A1sykgAc9sR5eTvK562GCaC56 mxaz1rMVdxNOmnEvuSSVnY64PwqKexIzwe8NLWlqqvMNVKr1EysqCFeGkZcVz+kAi75LPsPU OYtKqIfkgh9CEBIamRuQsAYwQe4+kXjQ+vjUVDchL0Orm32ZBPhJkaecSzwJ5JR6Y9Me8VOK krMtuzL+0h+I+vTOdRO9Qj87+w6o0oU6rtyxUy84ggKAWO/fH3jIOjdZTq91zSlVk0k06r3q 9UW0Hnc14yngMegCRn/5TGZU9km0G+A3rhrbdS12qFQVOrKFlTqEFWRhSiT/AGEVC1PJUkOq OU+h9YYl6ihJO1lxvIQ6cK78xZHTDqBNyF5SdsTM44JV9ZcbbSTgKxzmHx5KeTYHUjM0i5Oi q9v2vLNqapMq1NoLnfx0upCCB78kfn9Y516Vz9GpNWqFz1ZnxhIyy1JaJKQpRSQM49j/AGgu 4v8AqK5cmnZydcqEzlSnCSTmGmqOeLMgqA29u8UFyxdTp5NPbDqFgKHI+8Xp8P5FLv3qxtO0 r2l252UqbymQ1NE7EOFCtiv1icK5OWzS+s3T3V7W6ubZ0BtW8y27dsk5NvuOALMnsVjKE/8A V6D6Rauv2iunfSPoQ1/ief8A8SVWuTDVPll1YBTxWs5UsAfyjnETf6kvk6fR6KlqoJ/JC9Od ItX9TLXI04t75unyjmxxszCW0Aq5ylJ/yg5jp+1dqD01pDJ2a65NsMofephUEtBKlYBOfLg4 P6GDnOF3c+nvXdPpuUZWx9hBS+nLV22blXZlEseYk6k03874EthI2ZwVhQwO/tH1o6c6u2k/ LXBYVtTss9X5pyR+YkjtMw8nJWhWODjac59RCN0b8lzr9MnG+D6m6e6u0O4KvWKTQp1uqy7q G6g82cLSpeSnJ75PP3hvqehep6q/P0mYsSdVOy7XzU4lIz4KVfxKiNouFPp1R2ikV/N0mWXO ILjICml4CsnIOcQjrNuUaYqz1QmpQKfcSEreWolSh6AmFVY3R2I9H0TVvLQgqtGobzbEm9S2 XEyoKG0KBKUA98QK3pWlWrbU1RqPSZZhmZJK0pQOc9/TvHOqxJLomglh00NshatpTMjNUeZo TK5Wbc8V9pROHTnPP9OItDVXXC9NVtG06L3bPNPW02G0tU9LYQEbMbeRycbRiBVJSWTPV8Od Pk9+wzzS9N7VtW72JmkSQZUT6kk85/0izbqeSm0pjCTnaRtEeb16tWZ896rQhptU6dNWSOS/ VvOomdZKs5ggpd29++Iq4nxEEE8mNK9qOVyyT2bIIXKjcrnPAzD/APs9X8v/AOtAlkRngp6a UUJPPrBspLsobGFkL9QD3h8uBSwzfnw9nc2YlKlHKWzgZ4Bi3NbQ0u05xbqyhO0eX3PEY9A/ 4pfkbqc03+CsrfteUal5dVOUp2aeQFrcUMBOfQRIm7AqbVOVPhrOwZJ/7R9LjhI8u4XETFNq rDZmpQFsp/hPc/lHl2UqZu2gCqy0g2y7Tmwl7YnapYJ/GR9+P0gkybcFfPu+GNhVkj3gKnQ0 zvcQM9+DAydmElgtPpz0h1svSjzt1aQ2bPVF5pC1GYkVJCmmh5Vd/c5TgZMNl4W/fFlvI/xx bk/RS8SEftVhTHi++3cBmFq/IUlgUW1X5KVaVLvlBacBQ6CcgpP1ERW7aaaLXHpVOAgeZCvd J7GGXB24GYuBCtpVk+4MJ2aiKPU5erbQUsOBZ3e0BUeAoRsb36Vvh6dTOtdiyV1UqWo9u0at guorE4svTYaJ4KW04HPpk9uYfNSfhJ9XdpTM09bFZoVyUzduxMOql3yMcnnI/tGN6mlu2XyN UHyYmvxyq2TU52i1CTQhxpZbcwc7SDg4P3ELJPT2ZkdLKFqkJtpyUrz0yw2yk+dpbCwlQV7Z 3Aj6GCvkn4J30o6fJv3UWr1arNlVuWpSJip1R9IBLR2lLCcH+ZwgflDGipfNz6kTaXEoeX+D PKRngCBXBaRNtL+nXXDXVEw7oxpdUK18o4GXnzhpltR9CtX054jQk78IPXiUs/8AbszNU9uf QjxFyMs+SFHH4ckYzAOrCL2tl7W8lcdO8lcF33PMdJWoobVTZpx6VSmpZdRRpkZw4jHIUFck Dj3zEi6C+n6tWvrZd9/+Al1nT35unOTaVBKfmjlnekE55SVFOPQwDxIJ5RW3U6RdGpk0pT4x KpCEk+oirZpgMpUiXXkjjA7QUVkr7jY/JS6T4vjqJzzmJDo7VZGk6nUyoTs5NS0vLu5UuVbL iyDxgJxyYauSr5NIdbOq1HToZ/h23jNBurvNNkzaPDU8hPnJKfTkDiMayqJ+Xt2ozrUv+4mC G3Fnt37QQCIupQS4tCEEKI7QyVdB+aSwsKCj6AxfcuPKClTBl3SFr3Y9PaJv0+6jq061hte/ WnNho9RamiSSMpSoE9oG2AlydB9K73tXqH+KzWtfKNWEOWrQaZ8xLTkwQEyzJZQk7lH8ICio mKj64esJnqd6qqRQ7Zn1Ktu3nizJNJUQlxzPmdI9SccfSApx9Sudroq/i4fk170vUS9Li6YL vo2n1YFPq8zOpblJpTvh+Hwncc+gxu9IuydqVCma9csrMXUmmrl6PLy0xUmXQFsKyslQPuO/ 5wuqndnW1yb1FSy7hpmqZb17MXI9PuTjFPtlxwzi1Al5sKQcn/qITn65MIqs1bvztg1i1WkJ kqjUl1DangqLjC1Zx7knmMrupGJRlcZ9f63QJLp2vHUexmUJn5val5aDtLrjSwkZPuB2+8R/ WXVmrUzpjpl8y7AYqlzy7cpMTbIweB5ue/oYKnlq52elaffVp7vkxW8pHjrWoEgZwCYbpoLe fSpCcqPfMaalmj6nERvNOIdUSRk9hniElRafS0EFXH0jBVWQz2U2FghYwRCuozraaT4baQPQ 5i4xsiT9pB5mYL95SyFgkLOck+0S6/Jrw7MmAlXKkEbie0eU1/12j5J1v+dkcjup5a5jVurv KOcvEkkxXDhd3BSEn8ofHMUcS1myZ2Uwl2k/MqUQQcZh3/8A+mAu7hWuROZcIm1J7Jz3zA2X ihYWkAp941S4FLk3f8OxwrtfaXONhPf7RcetjgNnzzJcGSjIJP1/0jBof5xfkZX9jIVb9fkp alN/KODBQDvxyoe8aZ0O6WrwvvS2n6lSU+HV1iptUqRpIypx4rBUt04HCEAcqPHMfTItJJs8 6lcui4ujVhmtCStC0JZdJotIX85Up55KQ/OFQKSCeMAZB/KMpX/ZL+ml4mTnarTp5VVpU0t2 XkHA4ljhSdqj2yCEn9IJtS4BasjM9SWTNlBP8RhNNTKUMqS4vhPPJxC5hQVzqN8I9/TvpO02 lXeoK70UqevEonaYioNFpkSridyR4hG3JVk9431qJp5oVqfbaEX9b9EqUm6jLXzyEFCgodxn 3Bjkah1qdVSpj0k1ZnMr4m+jGgmkFOptO02simyD87NEbpFITlOOc/QekYy1nuKXrl0o+V27 JOWalAUg87E4yfr/AKR2E27NiLLhEMKitSQRgds5gpVObq0yzS52cLLcw4EKcSeUAnuIXUyi 44Z2z6LOu6xrl0hesLT7Sm4nqhY1FYU5Tg2MzaUpDeWl8JUSRnBwfpEl0U656z1IXLNaZ1bQ O5bZmFMlanpxIWyhs8AqcAACj7d45L0q3uo2PTOZ3Vz0i3nROsx/p9pcwmZNbfTNyc/NL2pU y6rO5RA8u07ge/b6w09Q3T9eHTvMUvRm4auy6qVbcm2EsL3bt5AKinHBOB98Rv8AdlCrZFHT 7KTNsdO+ptzsPP8AzNSflaS6WlEIaQFeIAR2IWATz/LENo85RK/dDFtNoeRMuJG044Lme2fa KDR2C6Bpek6SaBUW171rNOlp1LJcffUpDReUpRVuP1wQMn2i6L71S04tOzXbruS55JimBPM0 p0bFZ7AH1J9I5FanOVbCGJ+k5P621WTqfX9LVLR6pOMyd3TkulqaSnYQ4cIcIBHB+p94DoLq NX9QOry9NDbCqUxSxUqxOMJmphfLyWVEFxQ7KKtpP3MdG3qyLeVggWs9r3VS7vnm67PIcaZm FsNv4ALu04USBx39oredfk2n/k23gXFDPh55x7waRa4G2bfaUtTpT3/EYuf4een7+oXUjJyy pJDlNk2FvTZWMjHG0dvU+vsINIW+T34pGq8je2vjdv0dbKZSjS3glDJwC6TlROPUDAjPUi48 rT+oPK3bFTSMKHb/ANZgmgPkik8kpQXgsjHtDQxLuT04qYbSopTyT7QXctDdOoWl8tj+I5z7 QOWmS06lvspPOfeKtZDFyWhp11B1nT/S+4rVo1QWw7X0oYeLZI3NJUFbSfuBDNoZNzNT1WpM 648S6Xsj6fWLpqzO30R/xkH9zqj009PKtU9O5u65nVOtUVqXmSyWaYcA4AO775PeJFb3SjbF 5muP0nX6tPyMlMfKzTqWwpa1pA3oWTzkEwFSeWrHpq/UnCtNKC5sBpPTlIXXI1l6idQ9SFPp DqJR2YWCvaQkEt7VdhyOIIkOmDVZ65qlZp1andtMkUTslMjJS4FEjYBnyYx6RjqNNlU+q0oN qUOCMU7p11iq8nadr1C/JkputcyqekJhR8KS8EnKyMck7fpDhqL00Xh8/bVoyGr37YotQnVS TXClIk1hKicJz2ynkQuM0ma6XWKNKakoYIlfHRpeNtf4hml3DLIl6I5LBvxQU/NIeXtKgfTb 6iFV6dB962ZSqtWJS/aZUnKVL/MP09g7Xm04zyDz9AYlTUI68fFdJtLZgQTfQncErbLF0Tmq FvS5mZZMy3JTDxQ6oFIVtCT3VzjPbMAmugPVX/Cr9xPVakF9qW+bTTw/5yjGc7iAP6xndRVH gfR8T0q0knBq5Qk3LTkmFMPoShSFFJT65z6wStLi6ctRxxwAeY02weoveJDi6pF+M7lBQSMg K7f+uYlOoSiLQmVLUCVI9fWPH9Q/mWfJOsv+NkcieoqfRPaqVd1Cdv8AvCk/Q4OMxBnXiEhC V8+0Pj7TivkllrzfhUr5RJ/Ec5EL8u/zmBCSuRuZQEzKluE8H9YMbcBa2o7RqlwKXuN2/Dqm WzaiXGcAEFIJ9TF06xPS01Z82neAvZz+sc/Rr+MT+4yt9Nlj6E6AUTqS6D6bVtM5dkXXZr03 KVqScVt8Q+KFtvdskKbWPoNpEbi0z6C7W1F0dtuhu6oXDIt09hO+Xos6ZZDiiPMSUjOT24Mf Rp1/Ip7rXOFGPYsxXRpZFA0CqOhibtrk1KT5y9Nzs645MbeMp8Qndjj3jAPxLtItH+l+0qJb OlhcVVXUvpfcVlSktL2jlXvkHvzzCtNXdZPANWKijBL5Dzm5ajg+0ILhbW5RpplkpytlYAWM 8kf2h83gCGDv902SujmtPSzaFZvKyKeqnCjygTJ1FlKksJSygbSCMDBH5e8LtQdBtBOqphSm Z9qYFDb+Tlpynvq2Sh4OAEkJJGPrHMVWrSm6jykaGk1Yy/qt0i6Yr1Obti6b3mp+hWXTH69W 6xWFqdalWkgpS2nuAonGBHMW/KtSq3d1Rq9vyfgSkzMOOMMrPKUFR25/LEdWM1PsZnhjOcZ8 yADDfUHX2H0zDDyQttYKQeRkHI59oXPh2Inwdw+k/qM03mdN7Gqti6ZTL8zdlGYm33qNLISw w4CW3UOLJB3BaD6HIIMaMuOr0uh26/U5eQal3Fo3EpSBz+UcupTbqLPJpwkZN1F1y0k0q1Da 1b1VoK6jUZOQdQgycuHnkpyDgZ/CCR3jm11T9RVwa8a3VjViakfAM6QzKy4WVCVYRwhHbHb+ 8b3GzAZAKNqtdVvS87a8hXHE0+ruNuTcqD5XnEZCFH6gEj84trpXmKD/ALdrVu66pBpdPlph SXdo4Uo4xu+0C8Mi5sdRKf0c6V6uVJm/JGsvTtPnhufpj7ylMEegCewH0ETipdMujr+la9IZ 62paYpEpMfNsyk0StLTgOQQCewPp2jLOq5TslwGopI57fElvW0dGtXaRbFi2s07WKbR3H1VJ CTuafdfICwE9lBKEgGKL+G9X6xQutyzr4rRfCEzjomFvIUNwcbUFKJ+5HeNSozkm7CfNhfbc 1x1h6J0u5bIo0nYlHnJ65pSam3XphlITLqQ+4FK3KPqPT6CKkp3SXZkhpK9dt2z62LjDziA1 nO9OPKE/pDVQn8E81LFyEaadIeqGptZFOl6Q5LsqOTMOeXj254HHqY1/o/ozZ3Sfo7U65a6G BWK4jwXJ5bniOLSkEEBQ9AT6QzyWsMFyTzc5/wDU/p5Xrc1EmK7WqyzOLqS1zCnG+AnJyBn6 Z/pEdcp7Uvo45OqV/wASaSlS0qynsYpxsLUk7leVR5k/unH0pbxnk44i09JdDrDvbRqYuwah ystWvEX4VNURtW2OASr3JibQ1LBVV7WfO2xWV0yYcClg4yk5zDKmWV5gtsbu2e+IvY7BOVmf BsFjwgycjuon1ic9ObS2tVaNgAlb4HJ+kSmvUju9Cd9XD8nU7R7qEpGlHTjUaDb1dErcszNl 5hCmwoDOPfg8D1iT9NHUFYds2ZXJfUS8/kqrWp9ycW+JdXJUkc4AI7jPtA1dO25beWz1es6Z UtKcFduX+gps7XDSLSKk3XNW9dyK09WKq3Nobmmy34u4BLhxjGBj8+IdJrqR00pF4Xde9Bv2 UnJmepEu3IU9WQGXW9xLZ9MEqGT6YMYqtCaMMukaqTcrci6o9RekFS1EtC53Lxk0MMScz8w2 dw2OONABHbuCDCGU180JeethFAqkjR5eRqKpl6T3/wDDRtXlRHruUrPEZPLmr4AfTNVb2h2o HUFpfqDptONJuiRamxPtteEVjc4hDqVBfqMEJ9YS3peWkdImr81Op+qNLqU7dsgxIMUhvP7h SRtGSR7ckjsR6xnnFpWLh0/U0/Q4MK1YfsjUnR9u3qRqPaMg21ItpdmJ0l2dSpIHLYyOcj1+ kKZauafjTlTt16q0irU75AIYmZZ7E2HNvCVAcY7RVNN9jRpaFWM6a2vDMMXGlCq1MhpwrT4h 83PPMIJhC0yRCcDdwMesdNRwfUL+ghSkuDUFtxW1e1KiU5OM+n9okWqLgTZEy7u58PP/AGjx PUVbUyPk3V3fVz/JyJ1sUHtR6o6duBMrASD9YhylS5WAlGFe4PeNC9qOR3JPbbTwkgSB5T2h 0yr+aF8FkbnHUfNr9Sk4+8eMKClghfHtGlv0gf1G6fh0trVaymmyCMKwD6fWLw1WprSLSnnF OY2pOSTweRwIw6NfxS/IVX6bGTognrtqOsf+zq3p24Ey9wS60vLoswtAZLfnDjoHBbwFJP1U O8dVunDV6U0trL2mlz1NDT8uQlLbiySocYIJ75zH0Z0/NouJw44Y99TFfqt4U9EzRpGdbUyp K23JSZdT4gCgSCEEd8esc1Pica7zuo+oqKQl4MIZCfHlgr8K0px2747wVOCp0kgKhlNLyVLC XFEE/hPofvBcwW0EILgCseUHPKv8/wAoqWUBHDOnfQz1jUqp6I0zT+6npukyFMpjUumYn2Ft ofeHlW3lQAwODn1BHeLqPVpp/pRbs7bdqXXJzQSgO5lBhCVLHbjuYipRkrMZusZa6maZ1JXT oNder0vUJym2zXJtuTqFPcWEuTwAKkK2+qQRGGJjahzwAPOTt57/AGhjabdhPcfrW0vrVxPj 9ozKZGXwCp5xJUrGfRMSa5tD9OZZDBt6u1OoEf8AEdfSloLOeyUDOBj65hTVwkaL6INcLwpV xyGjFMuKWprTQ8JpU9PfLMAA5xzxuHPEbW6j+pu29JtLWKEbslatVnkhDUnT3fHcdVjvlOQB 94zuPrQ+/cxzqZcNzu2PWbzvmXcE3UmVJbl1Ena2f4R9cY/OMkgzlS8SUp8gp1ecICfxAQx8 i27Eduaw7qtmrGWr9Am5F5Hn8ObaU2rHoeRFi6G2/ctbqAbl5R9vCC8hHOFgfxCAauy/udDu ijq+krLpbdl1l91bzR2fLukhSj2xgw+656mtVK9m9TbYkrpkKrLrKZpmVnlmnONp/wCa3+H0 9O8XRoXq3F1am2mzPF4XUjV68p6+ag2265P8biOAkcYH09fzh30q0trV2XE3SrJpDRmmQXEL bSElA992Mx9PtQ0Whi6iwlk+MyqavqHVZx00ndvGS0prTbXCm1SWtifSv5uZSpSEpc3BQA55 +kMjulmpc4465UKcvYzNCV3EjBcPYD6xghr+nKN1Y6tTReIHK12/7jrWrG1ssSizFTmpB+Uk mU+Z3eOQYaLMtLVPUuQ+XoMi7NycqT+E+VsnnH5wca/TnSeoxa5nqvrvnfpYN7rcCW4unm8L mqb1InbL+ZnJZvK0lsEhJP8AaGNXShc6UG316fJCB+9EslpIxz3Ah9PXdOSs7GR6Lr8rTW7P 3Geb6Rn0z7spN6YthaG/EUlbAJwD3PvDtI9NdQRb8tTZPTSWVLLB8FDUqlO4euMCGT1HTZLO 0zUI9dhUaW7/AFI7Xek6T+baplW0za3u52tLZzvxEflulixZypO0yV04klPjKSwho5Tjvx7w 6MenVYXUVawmpq+tUZ7ZOV7h9P6NbYn5ZTjGlSHpdtZ3rDRwPfmC7f0O0rtC5mJ+n2TJszMs rCXFA7kQuej0FeMlTiro6XTPEfWumamlOrJq7XJMqy5R6bWfE8BCpbAIQDwDiHHTeTty6GLk rszIl6Wp0uy0y0pW0NurWSVe5OE45948Xp6SqajY/k+767xlrdPo3VVrpXGTqHuWnaX25alQ oFDE1P1UzT3yZUSlbTSUjB+u5Y/SD+muf091Dol1C/peYl5y1bSmKm+S4Ww5OLViX2gdgCe3 riOb1BbKs4w7M6Oj8V6qrpoSkldoeab08Xu71I2JpJM1+VVJ162v2xNzDm4qQ5tyUjHbkY9f eIjXNL9TZfWu5NP2kyCmKPOS0qyW1nLqnCjce3GN+fyjluWWdGn4rqR90Bz1u0Z1B0212/2Y KkpebYZpCqkuYlHA4VAKIwOPpEEm0eBoLQtTf29JOzVTqqpSakmCd0o0FYClffP5YMYakr5N UfFM5telCamXdpoxbt41e5boQmcoyEilsMkLMxkec/8A29oU9MFZVrI1MTdwNTlNkluobknk gbZkAjec/TMP0nqlYup4r8mDkoXY+dWluSHT/q1OWJKzZmWWmGphuYc4UtC07gf7wtnNM6Oz pNamoU5UXwu4GXH1SwI2sgL2p/Uf5x1+nadayp5bZl6r/tFeg0+/yynq5LSklfrIlVqIUgnC jyMn1x9oUaqT+2x5tP8AM0Rj0xjv948J1qn5WtnD4ZyYdQ/acVq7W3ZOROray5fVTUFAH5lf PPuYiriiVBQPI+sCvage5NbUYfXTwAsYPoYdPkXP5R+sKk8kbsQ6aCW5slR9eY+SEYL2/g+k aW8FG5PhzzLiqGN52p5x5sRoPVthU5a84zgfvU7MK7c+8Y9H/Mr8h1l6GiRdA+u9k9OF3Nrv ygKnJF1tbSpuVSC4ypZ5WU91AJ4xnP3jf2rFoaZ9RenEtqDpndEqioNNByWqcg6CRxwlWPXj se0fRoyeEjg3wZa1T61+qnSazJ+0KhdkopUoktImm5YB0jtg+n58Rhu6KjVNRaxM3JV55bs9 MqLjq315Kiee8Xw7C5u4y23a1Ruy8pOy6eVePNOBvP8AKPU/kI3/AKDWDauiNqNSFFoVMdnF t4dqcxLIcfVn1ClAlP5RceS0rFgXpaLlT6V7fm3WpY1urXJNzEtR1rSl+eYCQ0hSEnuApA57 HeInHSZ8OivTD41T6ipNmmSyViYYoaHQpYSOQXldh/5QTGerX8uL+eEHtu7gOq7Uq19RJtVl UKRZ/wAO0sqZZYQBsdOMFYxx24EYb1u6MZ+QqDN7WUpblOWvxFSyeS2BzGiEWoqLFSV22hip s/LOThVPLKHFcFI4EKJ1TC5dSpZSc/w44OYFkXBA7ukajT5z9oyTxS42rO8HsY010haRXDqN ajOpz0yqaY8TwymXwte76jvxj1hb5GLLHvrL8ew7TVLXMPl36mzspUgsgOqTnBeUn0HtmMst W/Py02fFaVLEICgvftIzz6frAvkkiwZDX1y7JNuy9ebbavCRSPDTOPKDdQl0jgBMwBkgYHCs 8eoic6LX/KUnV5yv0WzWDILCGWKV38NlIwlKc+v94pY5JZWJz1G0zSurqktZdHrnblKm2sfO 0onY8ysDk7R3ST6wx3F11az3Dpz/ALOqxcUm1RH/ANy8yxLjc8j1SVd+0Po7fOjf5MesjJ0J KPwFWpUaZNUZl+jlKmQnyBMaF6Iagwq5qxIOzCG5iZkVJYJVg7u3EfQOt2l068T5X4XXl9Xt PDyXlbMxOUSdtClXdPsPVWWZmVvuF0Ep8h9fY8CFV11e2qvb1KrNEdZT87V2HHcEZBCsE/0j 59KEtyaWP/6fW3KLViJ9Wiqouz5h+mNrSwFDxnPFylQ+iYbejerUmh6VVqeq8+ZVtUykKezg +wxHblHd0hKPO48nQduvScv+EtyQqDU1f9RUhoBCaegIWju7k5yDDHbMxPyN41qZuB5yXlUS iVMOvqBWhOTuP6xxoR9Ml3sj0c5qnacnjIXTtQbUvyenJK1ZlE2/LU9xCXVcFxZ7f1hdZrb1 JbtW36syGZlmUe8RtRyoEAd/1hlalOgnTqcr/swdPUp6hqtTd4sXVmly83P0R9aUuLTMrJdc QNxGxXH/AK+kVLpjYFx0DqAqNaq9EU1JPl7wlr7HI4xGvRV1ChVhJ5ccf5OdrtJKeso1YrCe f8Eyqz910W0Kb/s5ozE0XXnS+hwYSRuV3MZN1Cbm13vOOTMohl5Tp3tpOQlWeRHoPDqp+uSf qad/84PE+LXUWpoqUbRTVhrvy3nJCjsTCplKAlJcJJyTnP8ApHukSZlvS6an3XAk1GeWNic+ ZKOAT+cYOlq+td/ues67NrpyS72JRe05pZKh13VhOw0S2C7SXVL2gTDszgjt7J/PEQayLcu2 ldCGqutV52aFru2qScqxOsn98ZNpwIwkexKv6mPP69t6if5PR6GNtPTT+EWxprM0lfxJbNmU T1Vl/m7JcUzJTudoKGgBtxwEgE4xFPV59xnrpumkSWpru5+42S2mZ9NqUFRI7+U+n0zHLm8s 3If9c9eZiyut+duO9dREPSj9IdYD1MT5VbgQUIT/AClRzEF030z0Ru/oYvzURxVwTlap0/Mq Y+WQfAZ3byke2Mgd4wVDRF5CNJNPJOh6n6VGS0OZqqrklVsuM1VCvBmzg4KvqO3B7iND0zS9 3TfQ+5arVaXJScxT62G5SQkCNkkgpypI+hPp6ERs6f8AUSZi1r2wbKg+I81/iM2RfyUkTFZo wlVLIP71TLnh5z74UP6ROepmliyLKsOxpSVLDUrb7DmwDGSoZzHe6DjVtfk8z4of8F/gy1VZ sKvpPiKJUGykZ7ckf6CPNYZjbY03u4AQe/pxHz/r3/mM/wAnseh/yVL8HJXUR0P3jUVH1fWe e/eI9uT4wQPXjJhHZHS/qJzaKm25Xb24xnPeHnI94RPnIW25A5t8idcbVj8UfABZ8NJwM5zm NbVxP9Rt/wCHS6XaNhePLnHOM8RozUJ1QoD0ukcq94x6T+ZX5HV/YV+W2W5cfLpO7PaJVpL1 Aai6HVczln1YiVdUDMU1Rwy+M5OfZXfmPosXY4HLNB1S4NDep+xrlviQnW6a9SaZ8zM0+pPg vBQQArHbcN/qB2jFDrDaJla5V3gHCSD3EF3uLlhj3oLJNTevhmZoKbblpNxwLB7KwMfkSY19 ZK67dtRpFnUklycqrwZZ3c4JOB/rFRfcY1hGoNb9LrS1C1g0/wClWhrclqtSpWVnJ6sU8f7x JyrJ37UrIwnetCf/AKos7rU1omNP7HasSkTX++z42vFv8SWceY/Qk8frGVJVakE/yE8JmMpm fYqDQ8FskKH4MYx+USCkVMtSQlZlobDx5jwY6CeRVitdZtIdPbik11G35MyNWwSVtctu5PqO wMZ1mnpmRmnqfMOYcZJSoA+ohb5Kduw21yaan6f4LYBAIKhnvF39CfUjSejXU+YuO5W5up2n cFJfC6UyNxTOIGWVpzwnKgUKPsR7Qiom07B0/uVzrveuoPUHrQnVG/ahtmqq+nw5NCypuTlw fK0kewH9cmGTUx9v/FjzFLd3MNkBKh64GIFFv5CrXkfGmlTDqDuBG1Q9O8TS3JqpW/U2pxib W0ttQIdCsKB9Dn7xZXYdruuZFblnJ+uOqXNrI/3ho4C/oQPeIzek3KvW3IUpra0hhxboOMK5 Txk9z/3i72dwZK6GWha7Tuk1PmZ5+VcnpVAH7hsjyDnJ5+pEKrc+JdQKLMmfkram5V5I/wCM y8Co/bH9o9PpvEFOGnWnrRvY8JrfCtWpq3q9NOzY7H4p1Pnaiqdm5CqhwJ2h1cxkj3AxzChH xT7eSwmTap1YCUHd/wATgH3x7940rq+k708GWfROpwWK2X92HzXxR6TXZf8AZlWRV1sngsur 3JP1zCijfEmsqjU9ylyqKqll85U21t257jIMaV1rQ7NmzBjl4f6xvdbfeXHJJpX4rFApzaFs 1yrMqA8Pd3JH5dhH0/8AFTtSoJKJ+6KwEPJ2LIT+Ie0DT13SlLe45/BprdK65Uh5TndfkT2h 8SrS6zqgqq0as1Rp0dlpa5/MesSFr4q9sTVZTX1XpPpfbSQFOoIwCOYbV1nStRN1JrLF0dD1 vRxjRpuyWRWj4rNqVCoMVB3UedCpfnY0yTtP9BC134r9pzMwFO6nPhaQcFTBG3MLUujNpWG2 8QWywyjfFQtGiU9dDa1J8JtzJyGlEjPf0iFz/WXorW6ouqTGoLJKlZW6pChyffiNunr9M0e+ dOVmzl6zRdV6hUpqtG+1ii8eqPRWu234LN9ywmQnutXGPTB9PtB9h9WmiMnp3JWtOXxIy8xL OuO5dJBc3EZOfy7R5rpmppU9VKc3ZZPb9Z0lWvo404K7wfdTHUXohdszSKYrUGnz1JekpViY flSCpjwnFubc/VRH6Q26u9QNKleluytM9O+oaQqVKn51S6lb0ypO6Q2ulSFlXfkEH2yI89rK idWUl8npNNFwpxi/glHTh130aR6qW771UrEhMSVv0JVLlphp3AWjGMAnuSPT6wToLrN0p6vd V1ev/Vi6ZGlsTNRmqgX6i54YKiCEDI+wjmud2aUrhWonUX0wy/U3QJun25IVakU9qYlXphSk qS/uVlC8nA4yeYg9vdTcxaunmp2mdk/IylCrT7gDBfGEggjKAOOCYyVL3HpWZD1a16pTT1jX C1qk3TlyT/hS7km6nxJQFXJBOcdycxofTrUGSTYt+Uq5tXFV12an2Zpt+dmknkAjIB+oH5w/ p89tdbmZNdFui7AuqO+aBc1iaT2e1VJd2ZROlT2Hkq2oW4jIIH4fw/2iyviFVijy+qEhTZGq yTrcpSpdA8F9CwDsHGQcce31Meg6JUjHWtt4yeZ8SUpz0KUV8GPWajLVDURS0lKyOThWfXtA 9eHkosWfUpvCEtqJSr7GPBdZe7X1H9z2XR4bdHTT+Dklekymbrs3MpVjLqjj84ZkHK0qWec5 ELfBtTvIn1mpaNO8R8jOODDviX/mjPLkZyV7PoxOOHeME5EfMblJTuICQe5PeNrQte42t8OF 10SCmkn8JJKieAI0rqGsOW9NzSRuWkbsA9jGHTY1K/IytmBWCKw74extQSB6rEefO71ZKgsk /wAIxxH0NcHn7WCpiZUyohl0pU4Np2nAUn2zBCWEFwpBBHfMGDa7FWiVZbkdYSxtH+9NbQVE +hHpHRP4e9rUuq6uzuolefDVMtCQXOuvvYDbR9FZ9MJSowqTtFjHlotfoHv+m6hp1J637uBa l6zUnmZNbowWpRjhIH3AT29YpjWHVio6m39P3tPvFSptexhsnPhND8KcY+v6wNGPrcv7Fy+C NSLjEuobnFHA5x/rC9dSVNpDcqtK0tjHfnMak7MURuvzD5bBL21AySD6xmu9pqWTfMyw2vZ4 6t2D6j3gW8lMZHFLk5xbSkgoByjnuIOkZyVmKSr5zfiWVubbByU5PMBJZLjhH0nXXGp0VubU SpvhCSe0DlTM3FU3XUlKPEy4oHnH1hZd8EmsymuMpK3HEIbUsJDiuRnMPNxycxLTLbC1JPic BTZ4icFMb5dqZYQZWdSQSN7ZV2UIZrrmUtIQ/MN+RzyKGPwHHrFMKXBXV7SFSetypUulup3T jZbG79cZ/KM5rRNSs47LBW0pJCknPBEIm7MkI3WTrDoF8KXoo1A0I0r1L1AcmKZMV2ky8/VZ l24EstzrjiHvEbSM5bCChsnj+LHeHtv4L3RI5b8w4zc1UXNOVxCZYIraA4uVLrYEuhv0KkrV +9wScjiChqW+WC9OpZPKt8ErpGdNbUXropyUTbaQ4zVmlsUUBKD4SyTlbjm48+mO0eV34JPS DZ1Bu+7HrjvavSdvUd2qy8rSKgz4roS6rylRSRwlJHcD1z2EG61uCeSmV/Qfh/8Aw07m1GsL TWXqGp8tM3rZC70S+idl1JYaShaiwoY3BeWikEcZIireuboI0P6ael3T7XjTWo3nPTd/ttTS RXnELlpRpxClJQkJH4yAOcn8oKNZtpNcjKVC8ypulLpQtvqL6p7N6fK1ds3TZKsIcdqk5Jth x9sIbUvwmgeN6sBIz6mNe0f4GGlFz0dVZt7VrUGnpdqCUsydapqG3JWX3NpU29n/AOPhalAd u0P81xdiavTJVGvgMuj4BluUaj1yeoevtd+ZlykU5qdkUKQsYOVLwQVHIHAwOTFa6vfCQoum XV/pZ01Sus9URIaiSk1NzFZnJIOuyXy6wlYS2g9lZ4JPH1iSrGdUtq2kgm/gvaasVep0Brqp rSaoxc7FsNSE5QSoh15rxUHykE+QH25x94PvL4DN0USkVeq0jqJbSmnhKmv2jTlJSR/FvIOQ fXy59ILzlMr9M4u43V/4DeosvWpuUtDWmXqUnLbCueXIrabKSlRKtp5xlIHfPOfSIH1DfCF1 B6f+nGvdQVV1fpM5L0NKlqpnhqbcmACjPhrVgKPnzhIPAhO9JXY/Y20UhK9KNz1K2dL5pV1N N1bVGaKZGlvIIMtLFYSh5fqd+FEAegjRU38CrqOlZucptz6oWnRXJTxAx+01uZfKVrA8qUkp G1G4n6iM1SzYc1Zlcal/DD1Q0+v3TjTSk6zWvcdc1O8JcjLUyYU2mUYXnD7hUM7OMZxyYdJ/ 4O3UfMTMy9Zt727cVPk31y6qxTnlLl96Ekqys8AgpI+4jK4psYpbEkMOu3wsepTQZpt647qt +ffVVJOjlFInCsomJknw0q9hwck/WGKW+Gt1KVWg6j3Uqu0aUpOmk+um1aamZ7YXHkoKiGwe FJO0gHPcGM8uR7kpAbC+GB1iap6S2zqtZtDlZmj3QofKeNOpQtkb9pccycJT+eeR7wLUj4a3 WdovpvXtUbyl5GTt2hL8N6dTVG1/MKxlPhpSSVZB9cHEZ5NRlcpJS5M0uai3OzMIcRX5rxGT lKi6o4MCOqV4PuFExXppWe5Lyj/nBRqOCe1heTCeJI0X0V12fqzcy9OzCnVBWEqdUSR+Z9It rX+dW1p1Pubsnwl4z9jHna7cqrbN9NKKsjkzdD2+sTCgoK/eqyU/eECXUqfbQocj0jX2AXuZ NKHMbJRCOSO4Ahx+ZH/JP6xmlyNjaxEa0GxNuJYTxnvHjLe1gJUoRt7Cu5sz4ebwNNWy2sDJ yee/EaUvoolrXmnckKKCAR3xGDT/AMz/AHGTV4MqCZqLDaSt1zAUeT7wKQqDcw3uYzkduY+h ReLHBfcVOqUpCVgjb7QWHilJJyMDg+/vDED3YTpfPsJ1so6dij4iynck4xwf1jofNVqZ0a+G LqZfVKmvAqF1VBFEbmN2ChCyhpZ/+lS//q+8KnwMWSW1X/8AQB0c6d6HS5XLTM7TWq3VEAYU S/8AvA2oHkcKHHsBFPMzyVvLnVJ/GcJBGMDEFBq10DIJrt1SlNprjpR5sbUn2J4/vDrRXkfJ IKk7fIMYPr6wdwUriO4XpdmTdmAEuowcfU4xGRdQq0ua1GmnXHt6EqCQB6Y9oq5BQtQmEN1J Ck7QdpSpWIIoFdQxWnkOtpUkJKdh5ByO8C2VLB7PSzqWtzp2Nq7ZgFjTa25ucdYmil0gJSVH t9IG5SeCaWq7MTTIYW4d6QSAON3MG1y7J9mdRTQsFKDkA/wmLLZ83ePz9XlUzikNhlIQhP8A nDfXW26pPzMo24Sl3JQj1+8BLgLkibNGmVszLUxNNJeazhtRwVfYesZ11IpjtvXnNya2gCVb 8pPBzzCKo2AWzqlejMszKIuOcDcuNraC8opQPYDPEGyusV7yrgdlbknkkJ25Ewvj7HPHYdva E7FfgZew4jXTUVxL63bzqpM3tU+ROOjxin8JVzyR6ZziF9J6k9YqcVfJakV5KVILSkJqL21a T3BG7BH0IxDIwwVewmb151SZqkvVEXzUvHlZcyjDynlbm2TnLaT6J5PHbmHWS1z1BvaRplgX xqPVnLclnUbZN+YW61KAdi2hRwnH0xGiEVe5p0ahKqt5YdlV+zLG6npOvWRqRNobYZ3pqzTp ZeYcwOUrHIi+XNeK2S/8lr1cTzanBNOuP1p3aX8/8YAn8YwOfpGlRi+T2el6foa8XOaTd2Ht 603HPVD9sMa83HMvJlyshysOLC1gf9R78nke8QbSfWrUm7J5Gq9c1irbdxUGaeap1YVPlMxT mirJQ2s5IBKR+YzEcYvDI+k6F1UtqtYmM7qne85VJ65JDXSvzc67NIqSnzPb1KmkgpD2SBlW 0kZ78wqqXVdq5QV/MTmvtwzSm5NxwJdnkvDyj8JBGPU8ERVl2Br9H0MINqP+oh0/6zOqfVK3 3buuLqNrjc06+pLCErab2ITkfg24PHckcxHte9TLj1ilTbmq+rNdr8pT5cql5Z6bAY86khad iQE5O0E/aAcUrF0eh6N0o1Lcie66vMf4ttbVuYuV9M/aapeQpbko2hKJNCU7UBIz3Ayc/nFn THXN1LT1Cq0w7rXMzjM4tckpdRlGXFtoKtxKFkZHJ7j3MKqU48lVfD+k2trsZTuPrm1foWuN t6ot1GWmKtYbQkKTMOsjayy2slCSlPBAJP5GLMV8bTqrS8/OS0zRZJuZWXXpGmU9LEs6sggl TY4Oc4JPMc6o2meLlCCm1YOqfxvuoGvszJuTTLT6oLm3mn3Q/SnAnxGyShwfvMhYyfNmEt9/ Gb1UvnT259OqnpBYrEjeBUqpGlyDkst9ZCgVn94QVYUeSIzybky9sb3GzS74y+u2kli0TTi3 6BQX6VbjQakJWelisM4wc8HBVx3IME68fGK1D1/0Vq+j1+6Y0EMVdYUZyTK0LbUkYCwnsDj7 wicL5DSUUYqmXEF1ak91HtAJZxZcKCeT6QLwgoGqehdpK6ZMugf/ABBn6Yi2OpV3/wDRvUXC 9j90oj68RwKmahsXBykuPwFVZ5TY25Wo5HrzCGnndNgbMjPrG/hALuWBSJeWEq34fbb39cws +Wa/5ioz2yGiH1BP++ub0ADPBgsJSUZBwr6mNfYWbA+HXUGEyzqOAptW7cftGk74qDT9AnCC VZaOAB3jn0MV7/cdUXoKdq0q++y220hSlKPlwDjEHU6l1aUlxiVc3ckAAkqj38ZLB592uLEi rvkpl5VSlDjgHiD52kz8m2Hai4cqGA3nkQ1NCm8n2g1CeuDqJpDQYWWpYrcUEg8YScjtx6x0 C6lZCjTPTF06aGzAak5e+7gTctWGcFMsklJcKe5BCvX+SEzqLcl9w1JJBvUpfbGoWqU9NyP/ ALu47+6Q2cJbYR5Gkgeg2pHH3iHutoVKltGAvkpEGna1gXIitxuJqT0tIKAKd4OD2ODmJi5L zjlObMsve2EgDaeMRN2SXyNVXkly0ordlbRHmQO5/wC8ZBvOlTibuqK2mHOH1eU8kDMRvBV8 iu15j5yXdp0w5tK0+Xnsf9YSp/3CqDx21FSDyPUwLZUw667kmqgtSUN7AU4Q2n+EQ22POhE/ 8mlI8U5VtzyfyiXKXBOKWarLr+YlHy2c5CQcR9U3HPHLq1ArIyok+sH2Zd8DNIz8w/X0EsnY yck54zD1KTqX6sZpvAUFdwewhd8BJjHqKw4pK3kq8NXihYUkxWWtdnMVSpSNZcSpKn5cBe31 PvCqjwMg7Irx2xUKmfCRMqSjPeCv8EFheEzWAk+vrBqKCuGiyFPeR6dKU9zkQa3YvgBK2Zoe Y4GRiDjEFyyGix3wFeG+k49+xgv/AANObv8A3gA57J7GGqOLhQnZnv8Ag2cZV4jU2CTwoEnm FbNGuFTWGJlW4cFKVGGjY6icH6Weot+4lYmP2stKgCMBwwH9g3PKoC2p5bZUe6VkZireoF6m oniTPmJS82VZaqrp2knhwjEFTdPu6bRtmKi4RnsHDgiI0Njq6sk4ykwHgXPINGXkag8hP8rb hTn9IE3MXu2yVvT8wUK9N5PMA+BsddWirRk7Hiqpf7iPlFVSa248oU4SkH7ekemsajMSxlFV maLWc+H4p259wPeFSGR6lqZJpzYwzdArC1KccYLjiySTnMELolWaYwqVUT7ntGOpG7ZlUrti F6Qqsvh1bJIPBI7QFyk1FwBTbSxu7ACMu28hiYUqjT5eJWwf6wmmqLOrQd8or2HPMVKGC2xP M0ifThQll5Hp3jz9lzLSg6popV7HuYTOGGHT5NW9DTIYt15xxlQUXjk+n6RPeqqd8LS6qFP/ ACVc5xng+kebl9Ro3co5W1d5tc6txs/iUeAYBJbmplspSBk5JzG7sLjwTmguOJlQ54XlPG4Q 4eOr3/rGd8hJkKqrqlTykbT394C2rcAceYenvGlgLk1n0Bv+AHAfLlXaNQyu2brTMg60lTTr yAoEcEbhHLbtUdhtd2pP8GwTpLp43Qpf5a1JIjbwfDGR9uIKl9NLF2BDdtSmBn8TY5/pBvUV L8s8e273FDGmenSHErXaUgrvjY0BzDhK6H2tV5dc9KafSrrTfmU/4AIT9ziNVCdapdRbI1KV hTKaIUaiPs16n6ZNseMnY3MtsYLuc+UH1OPSJLcum1crFSpE7dtqvOmly6ZWnmabyWEcnYjj gZJOB7xqjDUL5DSkgMzpU/TkqnqhZjiN5xlTXKj6R4jS16dmDS5eznvH2hwy/h4WlJ7E/SGJ 6i/cuW8Ic0tQipGWVYalPNDcpsNZ2j3PoIUU7Tl5EshuXtd3wZhRCUeGfP8AQe8Fu1Cxki3A qxpYKaWm6jZrjKnOzTqMLOeAMe8RiodO1oSEwueuDThhC3zv8R1jbuJ+sZ671MVe7EtT5Z5J dOFgVMKn6VpTKuDP/FlpYkJ+gMAmemGzjNlB0fJWtIWoIlfME/X/ALwCnqpZuwrSsEjpp07d fXLDStpb2ApSEy5JTnjJAEFN9LenktUUOf7JGm5nGd/y2VKAI5yBwIvzNVa92S87Cg9PWnuE zjtht7VnAcDXC/piBT3THYSA21P6boSp0ZCVNHKh74iv1Or233MF7hAvpm0waUp8WG2U52rW pBwFex9uIRJ6a9H0OqP+EpdO/vsHP6wmWv1NP+plKpKLsIqp0waNVJtTNQs9hflAIJI3iK86 jenPSaiaN1q4qdbLTMxS5Qqac3cIA7Q/S9Qr1KqUpDoTbfJz6cSozBbcVjByeYUSNLmazU2K VIM+K6+4hpptPdalEAD9THtIo1tl7THwzuuiUkEz070xXEiVUpCEzCEpUCpZASMZzzn1iMr6 POo8TtwyDWjNdmXLVnGqfVW5VjcZGYdIDbS/Zasjj6iDi4dmC7jzVug/rBtoMtXP013ZIGbm hJS6X5T/AIzxzhCSCck7Tx9IY6Z0r9RM5OTknTtDrmmHqdNfITLcvJqcLUwU7gzgZ85BBxDE 4tYZV2nYJuzpe6h7Kpszcl56H3VRabJpBmKhU5FTTDJJwApZ7HJAx7w10fSXVC4KTLV6g6dV iekJ2a+QYnZKVUtt6Y2lXgpIHK8DOBzB4Lv3CnNJNVGXZlDmm1dxKTKZKYPySwGX1DKWlcfj P8vePappZqZR2fmK/p3X6e2VpaT85IONqWtRwlIGMkk9gItx9QO7Igq1m3Xaf7m5LUqVNUsc fPy6mSr7AiE1Kta4arIuT9NoM5My6DhUxLsLWhs+ylAYB+8U0sjIS+RNL0ybemFy7Em4tf8A IhJUr9AMwW1SJlW7wpeYWnICgGV+UntxiFNLgJS9IAU10vOSzbSlPMjzthJJb+/GAfoeYKnJ IupSEYV4mduznJ+kLkiRlgTTFLelTsWjDoGfDJ82PfEJ1yD6hhYAJONpPf6QipEbGSsEOUh1 0EJZwR3T7QnekvlkbVHOOAScRlUPUMuFN095wB1TZSkdlekAWwPDIcbB5g9twgsyrG47hn6j 0gmYpksqYSpHmA9CcwmvG0RlJ5NBdHSQmmTKSlIw6TjOOMQ8dYU4hGmNRDayAGTn9DmPIS+o zoR4OYFR4nVq4KQowGXSXJ5AbXx9TG1cC0rE2pNQeapyJInAHc+sKPHP/NMKGrBGauFGdcUl B75PpBDKylwHPEPfAo1b0ELQucWl5WEJOck941zJS0saqw6woEqcRgE4x5ge8cn/APKw9Q/3 TNozkyWKHLbFHlPGT6D/ALQkYe3K3F059Ce4iNZPIsPlQ14u0EjjJJJi7tBXqdMaaLk6nlSZ 6bdlsduCO2Y7XSLKo7j6PJLK3MUqen7XkJABTctVSwGk5I3paWMfcQruwzLErmbrjc+U1thL YSOZdCnANh+uCf1juO12OsG6p1GUfsquMSU4qaeZcabUwkbvl17kkDjn1BhSG1pui5XJKfRK TKWmAH3PwtDzY7xSzNk/qAszdPp1+Tk3UihbKKS2689jg+dQz+kHTFIpslcdqMyrgUw2ibWj 0yCE/wBswbSsXhoSXNJ1lxu3HXhK1edbqSt7oVtSUBKzge5Axx9IjevrkxM2D80tWxhMyApp 1OHAeRgH2jDrcUpCqvtYydNF2Vl24TZyZ7xJMMvTCGQkHaQnJOYkGlV61a6JG5KzcNfTLrYd 8BubIHkSFYH0/WM2jqNqK/JVN8D5TlhOrM9Lso2BFIaUp1Ccb1FZOR6HjEeW63WGdSqnU68X 1ybNNw05NNBBx4gKvuOB+kbbXaGd0HzFHoVLqtpSEggOSzs9MPtlR3YJaWsflntDNSbgv6s3 lS1XFabbVPaqbjbNQcQAtWEnAx6j6wqd72XAMsOyEWpVGp1t6S19FNqyZtE1VfFUttI/cKJI 2DHt2ijn1I3+RaRtByo9ifpHB6lZVLIy1I+oTPblMqWr8eBlWYrTqrdT/wCHe8HVtHaJApOT 7kZMK0X1o/kumvUcwpyZCJhYC/XnBiQaSIXUdULdl0rCS5U5YBW7G396nnP07x9BXBuaO0nx L6hqfQNK5nWnS2voTKWxMyNRnZ+Sr4Uidl2nElbCZQKwcnHmxnAIhX1Q3rZlp1OxRY08y3N6 4ag0ir1MoeBDzbSELJWQcBICEDnjMZ4xhKz/APvyOsyWazW/rLNdVGmlaoU3VGLTVcahP+LV 0rYmHSw54SkMg5SArOSePMIrfr01vc016Jrx6h+muuu0q4Jm5ZZtU9ILAc+cl5j5dw+oJ2pI PuMZhi2SaSBaKF+MD1Iaw0XTDS/TNvUFx6j3zZjFSr1PXtIm5jxEELVgcK9cZ7xZfw0pZ+Z6 KtEGXkpU+7qPNutBRGQoMuAke3l4/WDaSpJ2+f8AqVZsvi6qRYldoVAu7TyVbMrc2ochMzRK cpem2HSwvAPG7yY/KIwvqfs7Ujr0oHTlQL4mqoKBM1FyqUWpSbaGZGdl2SWfBUeSreYp5yvv /wBiOJmv4u72pFU6NNMbq13oPyt7O3NUEuNuNBt5UokL2DA/hKQ2c9s/eL56K9Lbxofw16Hp 3TLUpFTrFapc3MS9OWgfLvKmioIU8vHK0bs/QiLjZwSvi7Bsr8HMXQ7VW9OiXqXemaTSKVP1 ylTS6Q+xUWUzTIWXPDc27hgnuM946n3vq5WF/Eh0x6UZqwLXft+oUFFzzDiqWyt9TxYeO0K2 +VGU9vfESvh/2ff4JCOMkLqtTqugWjVjWVoB0aUTUdq85qtTFblESaNwPiuFK1v7TjBzkZ7J AEOitE9J7S6Y6DrtZ+hNAqd3W5ZzqaRQXpdDjKQ553HC2R51hX8R9oFJq92WkvgZbWlNNNPu hazdSkaJ6dTldn6Q5MOylwUZTz0+6pS1FLezlKj254GIgNl9Q+iVX+HfX+r+pdFOnQn6BVmK IzTmKaCkhawkrOeSrGcD3IhdRuObhqCa4JnqXod07VXpFq50w6Q7fkX5Whrn5iRU2uUqVOUp Jc8VS1nLm0HKU55/pGY/g4aAabaiyGp2qV1aMU2+6vQGGmqVQqsCZfzKGVH0BIzz9IB3V8hW 4NOSehfRlJdcVP6Z5joztt+cuy3m66/MqW4RIOJQrc20kkhIJTgn6do5q9fOpWjeoOqbv+xn R2QsqQpSnZBVPkHCtLxQ4U+Ion+IkGBUnew1RVrmf1vqSoe0Bdmm0KCh+L6QmvL0tDaZoTpJ ATbrswpSUkO8q/LvB/WM82nSypq43Fg9jwfpHkJv95/c3xWDmbOKSqaOVnknj3jyRUEVADbw DwmN3YHuTmVl2Pk0O7O45xHvhy/8ioTcMjdcdccm1ha8c9swiZG1SiVHEaewruau6BkomZpx rP48DGe+I1w681Sszz6ctsKSsjPYZGT+kcrburNIOst1Noup7rn0KTT2WZq4XgtgeZOzJX6Q FHXFoWlOVXE6QTwFoxgf6xufTdT/AMJ5Z0ZLAYjrk0D8NObkfSD6FHP6d4WyfxBdGKbLJlJf UOZbYbWHG2E5G1Xvgc/lD6XT9XB4iFGMojhL/ER0nZ+Xdb1DmW3GXi822kEFKz3UPYmFLPxE tHE+I1M325tdmRMHxATlxJyFffIEO/T6y/DGWk1cOHxCNHX3J0p1ImAufx80lCVYfIGBn37f 0g6b+InpHV0TP7Q1Hdd+cAS+l1tY8QD6+uIPyNY1ZJgvcngMd+IRpbOMONzOpDy0zLHyriec ON/y+2IPY+IZpZiVe/2mHdIIU0zkkltBABA5+g/SAdPWN8Mpb+QDHxBdIpBmVlZbVNaESzxm GmUlSQhwjG7+p/WA134hOkdyhAr+pKlJSrssKwD6HtyYqdHWSjsaYMlOSsJKB116KW9PGpUH UtuWfKVI3MnnaRgwtluuzRaQo03SJXU5KZSoIBeawT4uP7c+sIp0NVDG1lKM0LaV8RPTWSnG XU6xBLrDSWEKVklTYVkJPHv7w61X4ilh1ha1TmsHmdl1Sy++HEKIJB447e8MqLW3skxnrsJZ fr50zTJyFOb1YQE0pP8Au25RCkYGOCe8OdQ+IHYlRm5WrTmsUsZmSX4jHJSMkYyR2/pAt6tY cWA94gc60tKahRpqjq1UkTJz8wqacZCuFuE5z27esM8x1K6JO5Q3qHTgQAcFZBGfYesYa9DU VMyiwJRlJhC+ojR5aU7NQaeU/hIDw/r6+sQrqJ1t0qq+hdxUimXtJTT7suAmWbdyVHPaG6TS 1o1U3F8hwpyvwc5Z11kPLJwdxyFJMDknd042mXWUuBQ2lJxg/ePdxydHT0/MqxRpXT/QNmp2 1LVi+bnnFh5AUqXcmVlsD0CgTgwdqXo1NUa11V2zrom3EShLyWFPLIAHqkk/T0jRGlG1z6Lq PDVCGmUk/UK9OtLKjdlhyFwzWo9cS4/+92fOOYQr3BzA7s0JugW3MydvXzPzCVq8VcnMPrU0 6rOc7c4ySM5xniGKhHkCr4Uoyo7qbzYYbV0kuPWi3W6hfF6Tz6qatUq2w84VhlKf4U57Yx2i aUnSnUO2abLUu2tb69JSck54zDMpMONoll4wVISkgJVj+IcwUqUbEh4Toqmpt5ZH7LXrtUrj n7QomuFfk5ChT3zJfZnF4+ZwCHUJ7BZyDuHMOsxpZf8ASbod1KtzVisM3OpXjKq3jkzDjhOS srPdRPcnvC1RTjczR8LKrQlUUrMre9b56g+oS+W7Q1Jv+rV6bkVFJmqrMKdLYHGeeB+kXjbt ydYlkWPL2RZnVNXpGmyoyzTGCG2k8fh7bgOfT3zFRoKSMWg8Mz1FKVSTt2Rme46HqMnVpQm2 nn60ZgPF1PmKl53b8/fmLwuTVXq7te62epyu6sPG7pGU+SRVTgzDbAG3wwceVOFY4gZUVJXZ joeHa86U6k8KI56I9YPXdUtN5qx7I1imaXbk886VMONpIK1nc5tJGUhROeD3z7wtqnUN1taY v0+96Tq6uYmbfp6qdLFuUSQ1Kq/E3s7EfQgwvyErs1LwxOOl/UN5texHKT8YHrTte3VWNRb4 psvTi04yGP2Y0VICySrC8ApyVE8ciIzp3rB1F3joa/oBa7kpK2dM1QVl2WU35VzQXv3bjyfN 6QjyVJuxzOm9Kn1Co6UC4NTeuj4g8/otMaW1+56PM0oSfybz8pJpRNvtBJGxbvdQAJ7/ANYp DpM6hOpDTSzLm030VEvKy9yFBqM1MIVuUlOClIUCCBx6QP6fbeJ0H4brx1S03z3LXqHVn1m0 PXaX6n32qLMXTT6KmiNOtS52iWTuwNhOCrzHJjFOoNXnqvdE/UqjLBiYmX3HnG0cAKWoqPH3 JhVSn5Rl6p0qp01pT7kfJYSFJWrJIyBmEZdSG8heSfWMNaV0zmQNJ9JKyLPKwpGVOkFOec47 wk613tullQwoqHhnn34jyz+obkc2HyDN+JtyIOpYWqqp2jP3jZLgFE4ps0GmPCWM8cCD/mWv 5ISGRSr/ALyeW8rgH0zCclGwbVYHvGrsKNSfD/cQuoOKaVjzDH0jW94rKLfmVkYPhq8qe/bv GCC/iP7jZ+wy9PrmW55SnHCrngE/3hM5NTIKlZ3bR79o97FXscCdt1gTEw+CCVn375gRnXFP +GTg5znPEPdmJfIe646lW4qHI5MDl31YRhxRGOeeRFpYLD2pp5JJS4rzDnntAmZpba9jylEH vn1MDYtoOXMOuAhBKQO3PEB+Ym29q0kgp9cxbRLHy3XnXApThGBnvAXpx9QK1Oqz2zuipIqI QubdA8Njur8RgCFvBI8V44Hp35gUsBPIcl9/aXA+Tn0zBrU2600Wzux7A4irYJ2Cm5uZcJy4 rdnsTBnz77YCPEKwD2JimihNMVAImEuIeUDnjHp9o+VVngpXhuLIV9TEcU0WuLHztRm0oUEO nYR+HMJVT1QdaLb0wsIV3G6BSwWlYIOxKt55I7GBU9XhTqVpT50HcMDOccw2ODZo5Wrwf3NZ 2TqFZWpdmMUGtqXKKLSULbdKkble6TBeoFFvu17GdYs+4jMUxhBC5VR3LCPUBXPHMbY+0+xV 06um8ym+3BJNLZR6q6LSUhKTPgKfl1IDiMjZnjI+sK7CtedsChzP+JrmcnE7i4X3zjwwB2GY NfJojFxipt4sINFZtibtOeek1/u5meedSoHtuV3hg1AsWftm26ndNO1Qqe5htTqZZbuUkgZx EnZq9zFrk/0qqRlayK70T1S1Ncm5mkWzTm5wzikrdffPAPbJV9ouGgbNOKLN1m/rqLzz2Xlb 1ABHslAx/wB+Ipe0z9M1FSWj86vhEQ0IrMldGoFy3a3LAJfXhop9E4AH9o+oupdyzPUHMWy/ Pqckxlss547d+IpYSsHRrONOiocSbGrX+5ZqwdTJCv0JoFx5jBDhHOVDH9ImerlScn9D36i+ sKdelQpZPuYC90xPnOVLURfCIBo7q9ck7brdl2nbAW/LJ8NMy2TtQSPxKPvFmv1qZtPTxxeo FZQ9ObCS4RjeT6YiP2jqepdTQupPCsZBrE6xM1V1ba8IW6SPfGY1BYL6rT0SlqvTU/vG5VSw s+qveER7s4Hhup5Ma1REGtrqmk5akTMtdLTsxMbsILQHIwcxLdE6jTkWJN3HT5MhLzq3yjOC c8/oIFyuj0nTupw13qSylkBpPqjWr/XOiuSzTIbUQjws4SnnvmM7a4mSRqRUm5RAbT4uCM9+ Ix6p3Vzg+KZurpKc3zchE06hK/CGMkcHPaEyiF/7vuAPcmOZWeGeGgaY6TmQLLRs/GpZP2EN XXMoSukVQSgk/u8k5/KPM81TauDnC9hM0Uq7ewg6jLcaqKecpPaN0uClyS+Vd8wAHp7wp3K/ l/8A1oVYK5HKycTZGPKD3zCJxwJT5+x7YOYf2Fmn+gN0M1IqUv8AjBCAe8a5rswp+lTQSOPC VgE/SOZTf8T/AHHTXoMx1ZxSptSiOQc/aEXzLiiU7R9RH0Kn7Ueeq4kXT0pdHGofVx+2E6a1 SmNP0IIcnGp13aW217sOkd/Dykgq7A4HrFpVj4TesNu22/dEzfluTTcpJOT821LLcU5JtoaS 7tXxjeW1hYSDkiNEbMXZvIK6PhKa92pp/XdSp+6aCKfQGXHpqVSpanyGykLUDjbgFaPXPmhl 0j+GFrXqzpTb2sNFvG25OmXUpSae1PKdDjm0qCidqSAAW157njtETXAW18kjnvhIdRtPrDtv y9et2eLSnEmYknV+CEoaae3FSgOCh5BHHvALm+Et1DWu8lg3PbFTQp1iXL1OmlLbbedmDLpb K8cq8UbTxwYFNEtcPT8IvqmRSpKqNTVtOt1F0stttzLiCghC15UpSccpaWR77TCmn/CC6hKu ujIo+qum84uuSrk7KNStUWvxZdHdwKCCFJzxngZBHpBNq9iOLIXpt8PLVfWHVS8dKrIui3Xp mxWUuVWemZotS6SolKUtnBKySMcccjmJZRfg+dVtapNOqNMmbWclqxgMvCeWQ2CgrG/yZBIS TgexinYBJkSsX4cOrt/69V/p6s+7rcmapa8oibqVSeeWiTaCyEoSlRTlRUo7QMd4kMl8Ijqd epcnXZisWixKTz4lhMT1RUyllxS1NpSslPlKloKQO5PEL3WQau1Y+m/hAdVzF0vWnJVS0Zh9 icVT5l5FRV4Eq+lsOKbK9vJCVAnA4jylfCK6pavRU1uWuawVsftBdKLKq4G3VTSc5aGU43YS TjOcDOIrfG2GS3axUHUp033v0u387plqHNU9dSZaS6sU57xmylWSlQXgAg4PaKxW8F5S25g4 7wTyCFLJ2o45T3J9Y+U/+EoSD7xTyRPAFx4tpUDkH+gggPHJcWDj2iuwxLB4VpcIT4n2we0K 7fmRIVyXnH0hQZcCin3EWvg16KpGlqISl8mtKcnTLVSzpcIm2W8BKtrSwlbSh3HHaDb6vWzr BsdVBl6kw84ZYttMhe5XPHmI/wA42RlFRPsVXU6aGmdZS5QVaV1SlF0HYmJerNMzaJTCNqxk H/WKCufWK+6q0qnVC4phba+MbuIqUvg8n17qdWlOnSpSw0Xp09VinS2jaPFn223Wg4VAr83q QYztcmoNxT1UmJJVYfW28pSSlayQQSe8VN4ROuaypTo0YQfKyaA6XKVRqbpw1UEutpmJt9wK UT5lYxxCq+NDqffsy5O1i8JzKiVeAXPIkDsMe0NsnE9J+lhX6dCF7YIjoHUabYmo9UspyZbV vPhsu54Vg/8AaJxT9JqfTtTJjUj9qFJdbwGEjhPuomBugNBGlW08JJ+xspvqPvKmVzUdiQpj 6VolQltLmc5Oef7RaOryivQRUq0pId8BsICT3PfBMLvhmPR1I14amS4uO+k9pS1vaeSrNJlG m5iZZDxcx+In3+kQbUfR6+rsZfqtVvBLiGwohhAIAA57RJ+1m/qGglX0ap03ZJFe2707Va57 ZduxNWaaQ0CfDV3UBFz2eW7u0YRQaU+C4uXU19j2z+sKT7HP6T0z9NCVNv3IglB6X6NI0B96 8p4omm8q8RlflAHOImmkkrT6Np+qTcdR8q24slazwU+kLlg6nT+nUunStF8rI42dP2PU0vIt X5XIOVrZGMmMq68KaTqZUsIyA5u25jJqHhHE8WOMtNDZxchCgtaQvaTuP6QUlDqFKXjcR7xz qqujwMeTUPS4gpsiXUU7d2cq94jfXysNaVzbi3ONnmAPfniPMP6qN0eDnU86FTByDxntB9HR unk4cOPcekbnkFcklXNOtOpI7e8GftF33ECENVb3JeW3ngHuTCJ1Da2k8k+xhoKNNdBjg/bO wjB9PpGvK4fEpEwhkDlpQ3flHLpu2p/uNqfTMv1uaxUX8ryCo8g8d4JlBkqO/APqY+gUnhHn qqyax+GVpRrjfjl+VvQy5JSTmJ+notGf+YaUosNTyVrDwxgDb4Pc5Az25jY9OtrrVp2mVvTB vWxJr5iQUifpLtJWFVYCnBtDbygclapdvjw+Mo5h6TeURe1DZrpM9ZdF0Jvysapax2Y3QXxP SdQpNNpi/FLzqmVBCFbsJKFNoSM9xuyD6Vb09VLqimnOmPT2wLzt1tn9hz1XokpOS6lyymiJ ol19GQPEAWoJxwTjvAWXDCXBblfnerl2wL9vG4+ozT6kUWvzElSp6uTFNe2yj0iltpRbAJAL nhJSsH24EEaka79T1k9WNo9N8tUNOavU7uZW8KPIyLrUrKTXjCe+cWoEq8QFO8IOQQSIjSi7 XJy+BQ/qf1xMdU1B6SXKnY85Vv2Qa/KVF2VXLyhbRLvBxQSO4dbmRhJ4CkcY5EF6SaHdaOhN bs666ndun5TYVkzNNVLz7L6m1SkzMrc3OhJG15KkkcHAAgsTeAc9hJofoh1JaFa5zeolrVjS mam9VZd18tzDbxYkGGQlzuk4XkPAlBBSr7iHSlW/8RKszlH1LpOpNmNt0Bhy25K3mEPIl0Hx HJQ1E8cEKcOPxDgRc4/IK+CHaEaBdWPS7qBqLrLbOsVi1aZm5OXFXrlUl3FtzOHA9lsHAySg jJxjmFFqX71kdZPS/Lah0iqWJJW25cku1TpSZS98w9Oy08XsEAAYX4uCCo9sjmEt5swofBP9 OtP+tqkakXDOW9M6aXC3P1yYvDxkLfUlTs0z4SmmlDA8pYUnCseoOYpXQa6epzqToNyawWTT dPzIW1qU9c9YkZ2ZcYTLufKKbS0EjBQhW5RQR/FkHML78ktngI63OjPqc6mNQBrDdS7QkEsy 0vTXGqK6otMr+YQwloqwCpwLeG8kDGYw9rRpfV9F9SKzpjcSmlT9CmlyU0WjlPiIOFYPryI0 p3shcsMia/w7Arjv3hP/ALxvIVwnGcgxH3KPkthZ2KcUM+0FLQlshBUohPoTAvgYngKcQ0XP FBI9wPSD2nwpQUlW4xSZO6YrYqU/IK8WWmnGwo5/dLIgS6vU5xe96bccPfBUTmGxZolXqOnt vgOlazU22DKtTrqEere7gj7QBTiXmi6pZ47ZhqyAqspq8nweouCt0yV+Xlqi8lHslZAhumKg 8+rxt5yeyvWBkM86c0tz4Hal3fcVOlxJytWmGR+LyuEAH7Qe3qNdssn/APeScWr1K3SYm6xp j1PVQW2M3YbU3RUmp8VJUy4l7duDhWd2ffMPy9bL+mZQSK7kmPDHHKjk/nFSeC6fVNTQhKnT lZMjk/NLfe+cdf3L7lRJzmHie1VvKo0QUKp1p92XGAltSuAIFytgKh1LUaeDjTlZPkcabrzq DTWG5WWuV9LLCQlCM8ACAzPUBqfMhyUcr7rjTicEdsD2hbm2nc6X+8mulF03LAkktY7/AKTT l0STrK2pZ3/4Y/1gm1NY7sseYP7FqZSkHPhq8yfftCXUaZKPX9XTqKpfjAvufqMve65d2nz1 RCEOggpaG3H6QCia+3fSLWXbcrMsmW2lISpPmGRjvAOq2Pl4j1Tm5vurCbT/AFluKxmphqnq aImOdyxnERq6au9ctXmK5NgeK+TvUIVNuVrmPV9VqayhGjPiI1FpLi9rTnHriAqY7YOce0Jn C8TmQfqNKdL4As9krVvT5lbQf8ognxBKkEacOsJURu7gdo8m/qr8nQisGAFD94pwA5JPEKqG 0r5sIKsAmNj4AJUppKgGUJz25+sffs5f8kCGMtxqzOqTk9+RCRvcMKySR2EO7Ark0p0JLLlY UMZVnBOY17V2lijOpDoytpWfpxHNj/Mf3G1PpmX6wgy026MD8RAPp3ghC1JKC3lKR3+ke7pP COFJXZsn4WNRuJxm8aRZXUELKflW2q9OJbpfzS5hmUQrKiSQNgDpBT65BzxGqpmldR7adK7f pPV+47O1yZk521qU5QmvDKmpNYQFnJJC2lqCh2JIJh7V1e4PCRHL2lL8pGhertJubq4lKrK0 aqPorrBt0NuuTz251KEOqVgJJbISoDggCGfoyvjWq5rP0usyy+oTTanGlSLsrTJKZofzVXkJ VCHEqbdVwM4WrGCCePUwK55CSwSXVLpF6k+pXT5qz7g6jqTTKQbimWW5FikCUl5t5c0hpxxR Kx4h8RsKCMbhuMQbXC3JjRTqWnupW6+rWkr1Gshhp2Xt+YpKW0PLTK+CA2EqOPLn8R79uIjS BzfA+6RU/WrXKtWb1qUvqwozl312QetOXlW6Cnw0Fpnc+jYVYK0ISFKwMH0EPN366dTdl9Vk hoVXdcbWmpa8qKjFxz9BK2XZZalPp2MA8qPiEJB9OIYscFZJbV651Z21RbqmnNaLFL2icwpu YpTVu+Gh0LSyyZgqSeDsWkhDePwK4zD03/4tqlfNG0zd6ybaacrck7c1PS5bOGHm25hTz7qg k4QgKQRhXdPpnmFSknm5EhjVeOod92vTa6nq3tGdoOqU3/h+mSaLVcHzbzCVIUhpO7OE7zlS sj6xR+iFk6mymtyugKyOq2j0Q6W1yZuSVqLtNU81WZtGHHwUpOFIa8PPOPUDMKcr8siTLV1i 116q9IdE6p1UW5rJZ01Q6e1JzS6FS6SZdtUo47MJbPJJKHluuHIOQSPaIhoZ0I9TNg2xc9mW vqhQ6PTtV5aSdm6o/ILcCAlKZ9JaAIzjO1XHPb2irZtcJruW/Sqr1hXbIN3fbd56d1CRZmnZ H9mfsV1LM5MfMthyfJCspcDyEeU5/DnEZX6tOjjU/UXrGtHRu867bEpc19ycxUFVmnS7jLEy oKcW484gkqCiQQc4zjgAQ9elipJvsMyvhE1xdCpNTpHUnaFWNcpU3WpNmUQtK3ZaWSourGfQ KSU/eMjmzrjn5IT1No85NSy87H2mSUqH+sEpJ5AkmeCzLubCd9q1BJA7lpXH9IBNWZdmzdM2 9Ntg/wAamyAIpsOIlesq7U420Kb57HwzyP0gDVq1wKS4ilTJbPZaWzj+0CnktrIcugXA4SG6 RM45HDZIP9I8epNXl2m99NfST28hBV/SGxZbeLHkvSqwtW1yQfyr0KFZ/tA3pOZSnw/l1pUk 5KcHMOugYe1hUzLzgG5yWcBxnBSeIb1qSvk8c+npCmwos8DjZB3Pnn3MeeN5wEKBx6xLlrg8 bWAtRcVuKo0joP8AC+6ouobSFOtVlUygsW84tbQm6rU0S6lqSQCEpPJ5I7epiSmrZBk2+B4s 34OvWlfDlReoNk05SabUHaYv5qpNMqW83jeEJUcqGFA5HeITb/w7OqK8r8u+xrPsFdRn7GmE ylZaQ8lAk3VHCU5V3J9MQDmm7BbmkJpn4fPVjLyjMzOaP1RCZhDriChG/htew9vXd2HeGDXH pH6gum6VlJ7WfT2ZoKKgoplkzahvc4z+Edhj3hUpJYDjL1CW0OlDqI1HsX/abaGk9ZnaCFLQ mpy7W5tak/iCccnEI5Dpc14q+okzpLQtKK7P3JKSwnJmjyUsp15hkgK3qA7DBB5jPOSuMTxc EvpS18bn/ljpPWErK1tcsKO1SE7lZx2wPeGdGhOrj98DTST07qkxXlNB/wDZUqwpx9LZGd6k gcJxzk8QEZJsJyVg2d6ftZ2Qpl7TysNramTKLT8sryuBO4pIA4OOftCauaNapWzbn7fuKwqt JSKjxNTUspCF/UEjtFrKuUpXIpsTLkTC+ADy2PWBKecADiAMH2gmvQFHEjRnTmtEtZzDgJ3q Ksg8DvFY/EGnUuWI60hY3AjIz9Y8U3ev/c6kcRMJLWStQ3cn6wroK1rnEhSPXuI3tYARNZJC diy7wT2PtBm1P/PhQdiN18Bc4sbcH3hFK70PHJyB7w/sAuTRfRCtaLlw32Kh/eNi1x1BpbpB Aw0rKc/SObH64yp7DLlbf8OoPNfiIWRmE0vN+GFIzz7Ex7eEsI4zWSXaV6v3TpBOVSdtCeTL uVmlzFImioZ3y74AcR9MgDkRash8TTqgoVt0q16ZfZlGqHKJkqfMS7SUuyjaW/DTsX3BCOMj nEFvaJtT5ItePWjrJflBumhXBcZcbvSZl5yqKQNpmHmUlCVn05BOR6k5hk0F6jL86d75RqBY U+w3UENKYAmGkuoKFYyCCCPQc9xiIpu5GrPBYFf+Ij1M3TeNEvSvX+t+boVUcrEqFpygzC3f FK1p7L8w9Yqy+9RLl1Fuucuu6Ks9NTM86p1111ZOVKJOBn054HtBxmC0T3TPrC1n0loVq21Y lbZkpe0Ky9W5Da0CUzDzXhOFWeFBSMjBh1rXXrr5WeoSX6k5q4JRVw0+UTIy4mJVLks0ylO0 ISyeAMD05EHGViSJHO/E/wCqCq0W66VNXu04Lxm/nai6WUh1xWUEI8TG7wwW0kJPHH1hHefx MOpO95+bqVaupnx5q3l2ylcoylky0mtzxFpb2/hKlE5I9DiFys1cBc2I3R+uLWi165YVw0io y7T2nEm5J0RHhgty6VghS9mMbzuOVdz3iL6V9TmpOlerjutdt1UGtuImkKmJkbyoTCCh0kn1 IUeYBWcQorJK7o65tZLt6dJfpgrdUYctaXYRLBnwkh51pDiltoW5jKkoK1YB7Zic0X4tnVVb i6euWuSRdap7TDbUrNyiXmm0NseBtSk9gpA5A4Jwe4ir9wmsByPi1dU0rKiSp9w01mW8ZT/y zcmlKErU4lwqCewO4Z4xEbrXxFdbbg1ztXX+sVCWnK/ass/KSky+nIUh3duCk9v4yM98Qzc2 BNKORDQevPVShyFvU6VblFC2KHP2/JZSQES84pRcP/nyvv8AaIXbfURd1l0WRt2ltteDJqKk FSfNknJyYK6SAnG7H93rV1EmlpZmKfTjjkFLWOfyEJLk6vb2uClOU2r0ySIWMBTTYTgZB9B3 yIGUy4Qsw1PWhdM3LONzVuSKytOzxNgyBjHtBdt9YdeoFJat6XtaQWw0CMLbypWTnvAqSbCc UlgFS+rKo0Rh5qWtSSU4+4t0lY/AVe3Eey/VxOLqkjU5q0Ka65JOqcSpSAd+5O0hQx2hykkB sVhwT1iOLnEJd0+polkghTTbaRnvz294DS+quh0uoz1SRphTnlzpQR4wBDO0Y44hnIMYK+RJ cXUjbFzSM0l/TmQZddbLYdZTtCcjuAPWKYmJhHjrSE53HiKug4qwBTiRgITz7GPGF71j0Snu cxdy7YBoeSFlY/ATjEdC+kP4pnTfo/0j0vpo1E02uScmafNKmxUKe82hpwlYXhW4j1T6Zzn6 QucrJWJGFya2t8XjpIcCZ297LvBifkLgmK1TlU0odb2upSnY5yOwSBnmK4t74rVkacXZrjqV Zdrh+v6l1eXn6SippJlqelsgEnBBK9mcH3EKlNsPZdFm0P4yOhU5YrduXlLVddQRKpCp+WSC fGK9zhx7EHge8Vl1t3xph8R645Cu6K6oylKckk5mpe830U5I4wkN5Udx7ZJ9PtCHPISi1wOe nfX1YPRx06Wz0v06Yk6zXafPumqV2WeLsqllaQCWduUqJ5BP2iX0Trb6BLA1pu7X2kavXBUq helPYkZynMU5Ur8uGm0JCEO5/CNvOOSfvGacm2HGm+Bruj4nekrti6sW9a9/Ll5q6avJvUN+ ZZJXLSwRsmOceUlJx9Yk1H6q+hKyOpSq9V7PUtNvzd00aXpKqTTZFxp+UDculBSHFDHmKeSD jiFqbjLIcqbtZEzkfiR9HEwmapNc1TlHkTbhnETE02VOocU0lKSTgnOEAGKn67OtPQfUzpHq +n9u67Sdz1CpIk0y9DlmFj9i+AoqPmKAApeQOPQesN33aKVNp5OY78wtx7JGUqPI9oWMFvwy 2hQyew9Y139DLS9RoDQQn/B0vuVxgpG5XbB5MUh1/VTdSlSSSojIyrMeJjnUP8nUS9Jjpzdx tUAR9YW27t+fB2cE946ErWFx5J3Ky6CUo3ZT/aFPyLHvCgyFXbNFqoktJwCeRmG9qacSrJVj d6GHikaE6Jp5SLpQhCu5wT7xsi5pjwqU8EHBLZGfyjn2tWGy9hlq5pwIqjrjfGVklWe/MNgq Kw7lSgoH1zxHrVP0o5TQJdQQEZcUc+nMAE94iVfML+oPtBb0SwJuaUZYrSTj0MCRPpCvPxn1 zA7yOIdLVHblKyCDwAIPbqAcUGgcH2hkZ5AtkPlasUeVKORwTAnqogLwtPfvDN6TJKOAJnEL TtZHGO5MFCb2q5OeM4gXL0spRyCdnwoJAO4Hun2glmYKxsUTkZwMwMZYIoghNsoGxSyV++e0 GNzIeUCF59CkRN2ArBpmm0qJB/KAh4Zwk4OMkEwSkLmrgi8sN7mljPqI+XOFaQpR3HGPtFuV yWuwt10NIHm5xyYIXM4a/dkkD0MA5FpWZ8h3ayFIX35xHjUw2HSrfzFRfqZdsBrswXUHOMn3 gSFo2BQTknjMPTwC0HNrSUKcBye3JhL8wrKglfOex9IbGRVg4voCvDQs8jmApdZ5yMqT35gW 1YiR47MJ5UFD6g+kEF9op2hZP/SIrdkNo+S+gJKF5wPT6wF6c86Ub+PUA94pyIlY9NQUFFDa yPpkwTMTRWsIKu47EwtuwaQncmy0Ejfgj3MeoqTrbgw+cn2MZpSCSyJ5ypOuzAecfJI7HPaC 3p5SlDxDxn3hMnm45ICqrK3435I7HPaB/tKYDPleXg+yjiF3DR8azNM4T4iiv0JJ4jxyrTD4 IcdWSPcwakC1kOZn1MDa25kqGMmFMvOLbUCrHb8YMaFNbGAl6kX/AKEVAtWqz/FhKs4PHeKW 6+JgOUtDnlwojGO5jyMF/ENnS4iZDSrxAAvygekOltoQqeSFDCY6E+BUeSayu5DO5tYKPYnt A/mU/wAqf1MJ3WDGWtUdEzMB5XOew9YKVbaPCCw0Sn2EOIolydIDaZG72ULawd3I9xGtbgqT s1KiRYcClvApSQee0YJy21bhNYsVrP8ASdfM+45MqqMojcQUtqXzgwme6N9Q8Bt6rSA2jcQH MnHv9o6y6jG17GP9M33Ez3SPf6ZpLbU5KLz6rd2gf94PT0c6jvvDdVKbtA7Nuk5/pEj1Wk+z J+nfyKG+ji/0pDP7Zp4IOAjecGBv9GOojQSh6oSCh3Kkuf6RS6rT+GW9M7cgx0Y6iFGxiblX Fo/hQvsPvBn/AIQNTZMhwuySlI4KQ5DI9Tpp8APTSWbnp6QNTUICjMyiSobiN/8AaDGOjDU1 51CVTUtuVxt3+uYkuq073SZT0rsGnom1f3qZablDgZVl0/X6fSPEdFGsEwoy8mzKb21bVZcO 0H74i31SkllFx00k7hzvQ9rW1MplvlpIqVyD4uMj9IVM9Bmu020p6XZkPLjd4j4T39vUxUeq Ul2BWndxG50Ka3tOKQZaRO04KfFI/rjvBL/R/q9TX0S83JyW9XCUtPZP07xX7WohrSysJ3Ok fV9SkqTJyaRk5KnsQ80ToY12uBr5iRozCmyMhaXd2f05H5wceq0QZaObD5roC6hpFDrjdtMv BoHclCycf0xCGc6KNeae2pictlLbgGdu/wB+eD7wX7VoMFaWadxG90SdQC5fxJa2d/HmBc/D CGW6Qdcppz5dm1yvA5IX2iS6lQXcr9NO5450edQUoXEKsZRQ2MqcS4kgfSCn+k3XJgBz/Bbq gB2SYJdR0977ifp6lng8HSnrxMyq5hiwpkhH4xkeWEU308az09A+dsGd2kbgUgEke8aIdQ07 VtwEtPP4Pnen/WCWlg+bGndp9Up/ygr/AGBarvZb/wADz+71w2eIJdQ06fuKenn8AFaG6rsJ UhFjVFePRLff9YAzohq1NILjViVIjHdDBJME9dQtfcD5M12Ar0U1Rl1BmZsOpNkJ3BKmT29z Dc9pPqPLq3qsyfO7uPCPEFHV0XxJBqlJ9hFMWHeISpKbbnt47p8JX+kJG7buFK1odoM0FN91 ltXH9Ii1NK/uRPLkuwncpFfBKnaRNAJ7EtqH+UFPUSvo/eKpUxtIzkpMR1YtYZexphb8jUVj YunuhQGdqkEH7wndlKmkFxMo4nHfKTCN6sXGORO4xNq2rQ0v7YPMEOCeCsrl1JH8pBhMpDkh M9822rBRtz7wJqYcUNqSpOeOe0Ancux8h1SHChat2exzBSph4KKArbnsItyyDIVyzzyiC8nd x3EKm3ylWVcJPuYZv9JSWUX5olOLatRlKkEhaDjH8XMUx1yzjr0i22pG0hXH+keepr98b37T KykzBUQtGP8AOHe2E7nt6uSPSNs+BaViXScygeRSuCMEGFG+X/5kKdiMTPTTHzSkKSDCv5pt RygAcdhDGx9sEy0dvSQtOsisTStgR3GcRc9K6ibRyahOVUB5P4UpHCYx1KblK6K5dh2b6nLU LaXJm5Fj0IUSYMa6j7HDgUK7vSe/mMLUJLDLVNg09Slko/eJuM9+UFRhzluo2wFlPj3IE7hn BVAeVNANZyHDqXsWWdLsvX0rPuVdoFL9S9iuOEu3IlAJ/CDyYkaUy7ClzqXsFToblrlA2/Xk R6vqSshSfERcm8DundDNsk+C3FtWFMv1HWIpxAXc4cKuACsjbBzfUVZTL/7y6gkJP4gs4P5x NkiSg7DinqTsplwTLV3ngfhS5j84Uy/UhY7kuHHrva55xvMA4yZW12FjHUbYr7ZJvJskdgp2 Pl9S9qttbGr5Rx7OH+8RReWDsaPXupS1p1hLb14IJIwE78YhC/rRZc6+h167WiR7OQpwlnAx RsF/7brVlXxLs3MhTP4hleRn1h0pPUdQqVl6QvLwuNpSHCPy+0FHF0FOLSH1rqhkjLJbOoCU JVzgOYJ+kDa6ppKaKEvXzvwcDLuQPrzFq4qzDJ/qLp/yqgi9GStXr4w9YKtvXiRkmy5/ihou L4z4oxiLnEuzBVHXeWW0tbl5tEEY2pc/F7Qnpeu80wwFovJrIGMqcHP5QHEi3FrkENe1oJU3 eqNx4PhuYH9IMRro9UQkP3SyoNjakFwE4hlssHaz6Y1tn07ZaVuVGBwEbwU/fEDkNZ6vJTKp tNfaS6k5KsjELX1LF2Ypf6gJ9DZW5VJVRWr8aiM5+8P1rdT9wW9Kn5Oaprm4g/vUhePpiD5R SiDrvVjcta8YPppYLiAlSUJAOPt9ojc31A1N1CZd9qQKGwDjYkBf394GSsVawTNa8OvTLbxo 1NCU/hSlpIB+8J6zrVJ1B8D/AA3SGVOEgbWwkH7/AFhlnYlsjcvUlpe19yhU0JR+FRQDk/8A rEF/7TJFKlPTdq0tR5OC0CM/pCnNhWwEnVO3X3FZs+mLVjlRbH9DiCXLzsUoC5iwqesn8WUA hUMp1G0U45PWrz0sa/8AeNPZHyjG4NjIhG/XNI5vLw02lFLPHiBsf/eGKUrXuFKKGx2T0fn3 vGe08lxngqSPX3gpyxNF5xSFO2klLSDz4Q5+2IGFWafIDhF9hzl7L6dXHCqcsDewjuUpH6x8 ixuk2qTG5ux3QEZysnG0w3zZp8kdJSW4MOmXSfNKKmrWeZA4J3Hv/nBP+x3pAmSUfs+cSsDk DKU5+nvFvU1V3A2RuRe5JKhWTUlStmvrVTOzaXO6PpmKB6s1GsSbCASrCs4H94qn7xqV4mdp 6hupBBRnHfEHW034UyW0oxgRplkpxJCmTeeeHITj9IP/AGc5/OIWwT2almOVhsZ948ShIYGB Dhr4ClE5Az6/5x8rIfQMnn6wPyAuQanXC9tKzgg8R4h5xPZwjA9DANDwMmtTs/laifzhc8hJ WlR79u8SPJnkGLG0AJJH5wUlaysZUf1gn7iAmXHFPJJWfX1hSXHEpUAsj8/rEYxcnrjjgdbw s9vePn33hhIdVg9+YpckkfPvOgZDqu+O8JDNzXzCkfMrwM4G4xbWCdxMZ6cRMZTNOD7KMGLq U+lfE46P/mMV2LTdmfTFUqCXApM44CBwQqPZKq1LesfPO9/5jBJYKuORqlRCEkTzv/1GChU6 js3fPO5I/mMSyJFtgna3V1YQak9hPYbzxBorNWaaS43UngfcLPtCrEXuBOVqrLIQqpPEY7bz B8pcVdbG1FXmAAf5zBJLITbufOXDXN5Aqz/PcbzHjdw11K9iavMAbfRwwNkApNvIJVxV4HcK vMZx/wAwwcbpuNr/AIVbmU89w4YNJBpux6i67kTLKmRW5neT+Lec+kGU68rqMupRuCaJx6uG KjCLbdh9N5Ppm97uXMJCrhmiAOB4hhVKX1eDTwSi45oAp7BwxJwilhC7gJe+bv8AmB/+Y5v3 /wCIYVu39eaX29tyTQ5/nhcoRayilyKf9oF6OLUldyzRGM/jhOdQL0M20Dck1wP54aoRSwgp oXS9/Xl+L/Eczkc/i/7Qc3qDekwhHj3JMq+6oQ6UL8ESVxVL33d7aVbK/MD8/wDtCiXvi7Uq 3CvP9vf/ALQiMIpuwbigaL1upSSDXHzuPPPf+kKXr6u5lltTVefSScZBH+kaIwjYXZNDjJXp dBlt5rTpOO/H+kODV53RuazWnf6f6QhJWB2q46M3NXnJVSl1R3JPPPeFbNXqKSoJmiPyEEvc Xb0WBpr1WVMsNGdVtWrChxz/AEj52pTyHCETKhk+kW+GLkkmNVRq9Sfd8N2cUUnORnvFT6qv uzjKkTThWEq4Cj2hsUtyLhwVZPpSrJKRDfbrTRn3soH4Yd2KkPqwG1JCBiPfFX/NAMCx/9k= --------------030103020509010104020000-- From ajs@anvilwalrusden.com Tue Apr 30 11: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 1BCB721F9C72 for ; Tue, 30 Apr 2013 11:59:22 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dla3REMO3+BO for ; Tue, 30 Apr 2013 11:59:16 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0E05021F9AC6 for ; Tue, 30 Apr 2013 11:59:14 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3B58C8A036 for ; Tue, 30 Apr 2013 18:59:13 +0000 (UTC) Date: Tue, 30 Apr 2013 14:59:11 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130430185911.GI3583@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Messages on obsoleting SPF RRTYPE, merits of TXT, etc. 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, 30 Apr 2013 18:59:22 -0000 Moderator hat on. Dear colleagues, There has been an enormous number of messages lately discussing the planned deprecation of the SPF RRTYPE and whether TXT is an appropriate thing to use and if it is whether the SPF use of it is ok. Many people have posted many messages on these related topics, and the chairs (in their moderator role) believe that all the arguments that are likely to be made already have been. If you are tempted to say more, we ask that you identify the specific point that you think has not been addressed and talk only about that. Other arguments have been made clearly, we believe, and do not need additional repetition. Best regards, Andrew (for the chairs) -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Tue Apr 30 12:23: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 0E0E321F9949 for ; Tue, 30 Apr 2013 12:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQOACQNmebRA for ; Tue, 30 Apr 2013 12:23:32 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9A921F9AB3 for ; Tue, 30 Apr 2013 12:23:28 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3UJNCLO016733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Apr 2013 12:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367349804; bh=Zvk5YCu3kxJzSfYp63EtHevdv9OcII2vrtA6ZLcTxOs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DZbgd1DK/XylNJ24mJGe69RIvoZcTQTavfxJYPdWqUa8kEYRgqCyXevz0Egbnz7Gx alx9tqERf29kF9uv+QyLRe70i8KLe/D56hMgpnSJ0BNpdazP4K7GYCxywQ1ISQVrIL ES9qVP9Epdk7XOnv4K2pkMEDoGySEn11C4L4Pzv0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367349804; i=@elandsys.com; bh=Zvk5YCu3kxJzSfYp63EtHevdv9OcII2vrtA6ZLcTxOs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pGZX6lsG27YpoTC9uhZrm5p2QOg7n3SXKXryTuCO+v7XEfKU45L+q2E9SpxvHlR6Y bFSgwdZcYPb79RlnoJEnOU8VRK+hEb2ribIsSRFz36bkgvY1mVzaV8hSBWWZJg6Jd1 KhGcXlZCUaj/Gb7iMjZ+gSCHMo5NK8EgHFLzLuyY= Message-Id: <6.2.5.6.2.20130430111045.0a7ebc30@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 30 Apr 2013 11:32:45 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <6.2.5.6.2.20130429024006.0a9a7e18@elandnews.com> <6.2.5.6.2.20130430070019.0d6c3158@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 30 Apr 2013 19:23:41 -0000 Hi Murray, At 10:57 30-04-2013, Murray S. Kucherawy wrote: >How are we tracking the issues that have resolved in the direction >of adjustments to the document before requesting publication? It >seems like there's a large number of small changes that need to be >either adopted or discussed further. I'm sure I've lost track of >some (maybe most) of them; we should do what we can to help Scott here. That's a good question. I am tracking the issues raised in my review locally. I will also be tracking the directorate/review teams reviews locally. I am ok with going with what Scott finds easier to do his work. Note that I consider your review as not addressed. There has only been one comment about the AppsDir review ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03633.html ). There hasn't been any comments (excluding one question) about the Gen-ART review ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03647.html ). I forwarded the SecDir review a few minutes ago. The discussion has been mostly centered on a specific issue. The other issues which the working group will also have to address are not receiving any attention. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Tue Apr 30 12:23: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 DFABA21F9A2E for ; Tue, 30 Apr 2013 12:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1uwOUrzGyEo for ; Tue, 30 Apr 2013 12:23:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D5B21F9B2F for ; Tue, 30 Apr 2013 12:23:31 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3UJNCLQ016733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Apr 2013 12:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367349809; bh=+0lFd3GfW6LgjJjojEVf/F0iihy+r6krDPOs1OoPCNA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QL/HFukEDY4Ig/E9ZO7RkJ+gHafZNvAx+bw0p9ffyvQdl7usQY46cEKcP6ix20wGG 2Gszk34DffQktFTvQhUo18AbPLp1bETtE/OQt/Vcm+EdyAtTlhng0zRJlezrPaLsW2 pF42zMXmBACZywYM+a4yS7Uy7/i2Kd5MLJ757iKI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367349809; i=@elandsys.com; bh=+0lFd3GfW6LgjJjojEVf/F0iihy+r6krDPOs1OoPCNA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=g+hG7fcnWmDX4Fb3rUXx0T1qWoi10iDK1XzNv4PXzBU1vmkYV+OZbvZU6Mv0SF0W8 IeVbAhKbR1Z7BDHESXgrw5MG0bJAnt+UTIY+J9OAh2Yp4Tvq2qzKQfODQ+1Zk/s36E I6fZHlqJvdMFCX1IIB8XDX9JbUFf1/YZjxtuWXC8= Message-Id: <6.2.5.6.2.20130430113344.0a7eaf60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 30 Apr 2013 11:40:05 -0700 To: John Levine From: S Moonesamy In-Reply-To: <20130430001101.8968.qmail@joyce.lan> References: <20130430001101.8968.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, superuser@gmail.com Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 30 Apr 2013 19:23:45 -0000 Hi John, At 17:11 29-04-2013, John Levine wrote: >It could just have a TXT record (presumably v=spf1 -all) and no A or MX. >I agree that taking "valid" out is the easiest approach. I suggested some text for this. >Not that I'm aware of. That looks to me like an optimization to do in >the DNS cache, not in the client. Thanks for pointing this out. >Now, now, what Microsoft does isn't by definition a best practice (or >worst, for that matter.) :-) Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Tue Apr 30 12:23: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 ABE8721F9949 for ; Tue, 30 Apr 2013 12:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.26 X-Spam-Level: X-Spam-Status: No, score=-103.26 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HT0Bbc+HQz+u for ; Tue, 30 Apr 2013 12:23:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B4D21F99F0 for ; Tue, 30 Apr 2013 12:23:41 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3UJNCLU016733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Apr 2013 12:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367349816; bh=NqY8RBb/G9nUkVf52wNxDaV8OK6+VZUzAp5jF3R7KZI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UwMA+BnlTrrbK0V2slXHceo0AULbid/og05qFi1/2trMmYEC/2sdlmLJAWY8st2eE lpcb5qeO//jxC7zEmvqJmktz/Be0lR6YIOlbTEMlkJ9aOzH7SkHx4vC6TsghFUCzXJ raq2CKHEc2QBsTA5YuG9sj/0ihk/PfERCeYd8c/I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367349816; i=@elandsys.com; bh=NqY8RBb/G9nUkVf52wNxDaV8OK6+VZUzAp5jF3R7KZI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DWOaf+l17Rr0RefAspcnBsVfBCuoss+/fCiDrQJGl3sVOTagyUZNQBsqjn6xECflP d30LP1lm1rrEBQMa54wFUsj4WQ5E/GGpvORCxd3CDfSWPy2B9sUXuWk/QMiZfbJXsZ 2EvbxQ3aA0DggsUcL+Ngq+Hj5iqJ4bE1fPJDLTzA= Message-Id: <6.2.5.6.2.20130430114641.0a96c6d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 30 Apr 2013 12:22:21 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <517E9280.6040102@tana.it> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <517E9280.6040102@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 30 Apr 2013 19:23:55 -0000 Hi Alessandro, At 08:32 29-04-2013, Alessandro Vesely wrote: >I add a few lines, in case consensus needs to be gauged. Thanks. I'll comment below. >+1, sanitizing input is part of any protocol. I gather that it is part of any implementation. >"What is a Fully Qualified Domain Name?" is the title of Section 5.2 >of RFC 1594. That's not the usual reference. I am not getting into details to avoid side-discussions. >Just mentioning that they they are synonyms, e.g. in the 1st paragraph >of the introduction, might be handier to readers who are not familiar >with the term. There is already a reference to RFC 5598. >-1, Section 2.4 is the proper place to say that. Sections 2.1 and 2.2 >should be just definitions. They are garbled and it's they who >deserve corrections. I noticed some slight document inconsistencies. My preference is not to go over them at this stage to avoid reopening other issues. >How about defining the concept of (private or standard) "extension"? That might be outside the scope. >+1 for "semantically equivalent". I suggest going with that. >Leave off "single string" (Section 3.3 title is "Multiple Strings in a >Single DNS record"). We could reuse "string of octects" from RFC >1035, e.g.: > > The SPF record is a variable length string of octets encoded in > a DSN TXT record. I suggest going for simple. :-) >"SHOULD minimize" conflicts with one intended use, namely > > v=spf1 redirect=_spf.example.com > >Exemplified in Section 6.1, that use does not attain the minimum. I don't recall this being raised as an issue previously. Let me know if this is not addressed. >Should we say "is described along with its interpretation in Section >4.5"? How about changing the title of Section 4.5 to "Record Format"? That affects the paragraphs in that section. > The size of the byte has historically been hardware dependent and > no definitive standards existed that mandated the size. If I recall correctly there is some other reason too. I'll avoid the side-discussion. >Would it be better to s/do something/behave in a way/? That's a bit vague. >+1, Section 2.4 can refer to Section 4.1. However, Section 2.4 needs >to mention how the parameter should be set in each of the checks. Can the working group please review this? >IMHO the reference is fine. The term "email domain" lacks a formal >definition, and is used improperly in Section 4.3 since HELO needs not Yes. That's why I preferred to avoid it. >be an email domain in some sense. I'd s/fully qualified email >domains/fully-qualified domain names/. Yes. >Fully agree with Murray. However, it is not layer-wise clear whether >any A-label conversion is to be carried out as initial processing >within check_host(). I leave it to the implementers to comment. >This is a protocol change, marked as such in Appendix C, 2nd bullet. Ok. >+1, since we collected those limits. I propose to replace the second >sentence in that bullet with something like: > > This is where to apply the rule of Section 4.6.4 to ignore records > other than the first 10. I commented about the table in the review. >I'd rather import IPv6address and IPv4address from >http://tools.ietf.org/html/rfc3986#section-3.2.2 I don't know about this one. >+1, something like "implementers are advised to make it clear..." I would have to say no. :-) >The "LDH rule" is explained in the Informational RFC. It is the >Letter-Digit-Hyphen convention defined in RFC 952 and later modified >by RFC 1123 [http://www.icann.org/en/node/1145376] :-) >It doesn't mean there's a BCP. s/best/good/? I commented about this in one of my messages. >See http://www.ietf.org/mail-archive/web/spfbis/current/msg02276.html Thanks for the reference. Sorry for being terse. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Tue Apr 30 12:24: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 A657D21F9AB3 for ; Tue, 30 Apr 2013 12:24:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s4VQu8nseLa for ; Tue, 30 Apr 2013 12:24:50 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDCB21F9949 for ; Tue, 30 Apr 2013 12:24:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3UJNCLS016733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Apr 2013 12:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367349812; bh=5UIqOX8qo5lnu8OKGRM2sNCwT1K0pPTc/4EoImrOWaw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=j4MQ238qmkzXfMieLxhl/m6xAzjkZh+8dCehcUJZDgWzbKeX/8QZvznht7u5x2eY5 ia6/m5ImJU6TotHiMvpqpj1iuhmAtLqNxDYEjwpUlS32kQXvus/ysxZEXVe4VY6J4f KCybuJcr0lhPwx+NExlIYl+DSr37480CgMYLaATw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367349812; i=@elandsys.com; bh=5UIqOX8qo5lnu8OKGRM2sNCwT1K0pPTc/4EoImrOWaw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=j30rBEM2SVrvaXawQzfhAMM4JNbsr5Jgq4RXpoLf8yud/o3Yk9DqcnAB7jRXbVT05 rsoy8JBuNkRSHbKiCpcy/nzSoafDq778CwV+FxB/8Cag7D0+Ir+Q50slX4Af8cblTt D8qXm+AJoVLY5t2iaW4D4xC7WQvkdBxeQfP0J8gk= Message-Id: <6.2.5.6.2.20130430114300.069432c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 30 Apr 2013 11:46:23 -0700 To: Stuart Gathman From: S Moonesamy In-Reply-To: <517E8E53.6000504@gathman.org> References: <20130428183338.97350.qmail@joyce.lan> <20130429024917.A69473323956@drugs.dv.isc.org> <517E8E53.6000504@gathman.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE 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, 30 Apr 2013 19:24:50 -0000 Hi Stuart, At 08:14 29-04-2013, Stuart Gathman wrote: >Dear WG, please note that publishing SPF *only* (as Mark mentions) >solves the problem also - as client libraries have had a long time to >check both records (and pyspf support both types very early). Most >libraries do check TXT first, to avoid the TIMEOUT problem. But >recording domains that TIMEOUT on SPF queries solves the problem on the >client end and allows checking SPF first. Please note that I am not ignoring your comments. If you find that I missed anything please email me or raise it on the mailing list. Thanks, S. Moonesamy (as document shepherd) From spf2@kitterman.com Tue Apr 30 16:27: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 3A53821F8491 for ; Tue, 30 Apr 2013 16:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+rWOv41msKh for ; Tue, 30 Apr 2013 16:26:58 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 782D221F848A for ; Tue, 30 Apr 2013 16:26:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5C72F20E410C; Tue, 30 Apr 2013 19:26:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367364417; bh=Do7ZbDJ98y9C1yxwl0rRNhP6Rd1I+CHRLnyZOjVZ4bA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LgQtcK4w0ngABYSpexBUw4S7lm4vHK6iWYkUuT2Pefs31NcTE4HwblSlbvrfxAWD/ IuF3T3wCEhU7YjoaY+TI8gyDdKsX/PeCsaMd7UebEnMIob8388hxrRF1zIMCmN7D13 B6vqMM7OYlJV3nV31HtwsPVlxG2wyfI1k36EwoGE= 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 4416120E40FC; Tue, 30 Apr 2013 19:26:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 30 Apr 2013 19:26:54 -0400 Message-ID: <3198772.42M6YQxPyW@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130430111045.0a7ebc30@elandnews.com> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <6.2.5.6.2.20130430111045.0a7ebc30@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] Document shepherd review of draft-ietf-spfbis-4408bis-14 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, 30 Apr 2013 23:27:14 -0000 On Tuesday, April 30, 2013 11:32:45 AM S Moonesamy wrote: > Hi Murray, > > At 10:57 30-04-2013, Murray S. Kucherawy wrote: > >How are we tracking the issues that have resolved in the direction > >of adjustments to the document before requesting publication? It > >seems like there's a large number of small changes that need to be > >either adopted or discussed further. I'm sure I've lost track of > >some (maybe most) of them; we should do what we can to help Scott here. > > That's a good question. I am tracking the issues raised in my review > locally. I will also be tracking the directorate/review teams > reviews locally. I am ok with going with what Scott finds easier to > do his work. > > Note that I consider your review as not addressed. > > There has only been one comment about the AppsDir review ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03633.html > ). There hasn't been any comments (excluding one question) about the > Gen-ART review ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03647.html > ). I forwarded the SecDir review a few minutes ago. Those, msk's review, and yours are outstanding. In other cases where there's been on list discussion that led me to think a change was merited, I've mentioned it. Scott K From sm@elandsys.com Tue Apr 30 17:44: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 B68E121F87B7 for ; Tue, 30 Apr 2013 17:44:03 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+5hN1b5h+SM for ; Tue, 30 Apr 2013 17:44:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E3021F85DC for ; Tue, 30 Apr 2013 17:44:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r410hnCw016341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Apr 2013 17:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367369040; bh=xsEHpG3mG150mswspkZCnocPtpkb4Xp3HhejM2Hld/E=; h=Date:To:From:Subject:In-Reply-To:References; b=txO3W8kYnC1JVfJFkIjFokf/7gjmX2KxoLEOxslCDtFHEHmtitGf0ujgni2QZd2/z Rt+plmyVCaeMjTUeTFJ5/OyFFoykIsno0LzCuld18aMn75SIPIP+j3wWN7t7jyd0JG fCD0Z2foIEoK7YvRaEuz0N6b0vrXpP6i+VpuQCj4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367369040; i=@elandsys.com; bh=xsEHpG3mG150mswspkZCnocPtpkb4Xp3HhejM2Hld/E=; h=Date:To:From:Subject:In-Reply-To:References; b=201B535PpVzKw0QldrbZhD89GCZBQXLh3Hv6EZ6o2HHayY4949xAMdfiQ7hOFHfSd 256gqdlt9L7W9LK7udaXRsVbS9fCQ86X3+t4ZgdG3e/gF4zMKwSUmdwNeiu83Nu/3E YmKDCjHA+5HQ/OI9eE3A51mkv3POb4IQQgQhRToA= Message-Id: <6.2.5.6.2.20130430172422.0d6ca9c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 30 Apr 2013 17:43:35 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <3198772.42M6YQxPyW@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <6.2.5.6.2.20130430111045.0a7ebc30@elandnews.com> <3198772.42M6YQxPyW@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 00:44:03 -0000 Hi Scott, At 16:26 30-04-2013, Scott Kitterman wrote: >Those, msk's review, and yours are outstanding. In other cases where there's >been on list discussion that led me to think a change was merited, I've >mentioned it. I am not sure I understood the above correctly. My reading of the quoted text (excluding the first sentence) is that you would comment on the AppsDir, SecDir and Gen-ART reviews if a change was merited. I don't see any messages from you in the SPFBIS mailing list archive. I presume in your opinion that no change is merited. There are 74 pages in draft-ietf-spfbis-4408bis-14. The reviewers from AppsDir, SecDir and Gen-ART have taken the time to read these 74 pages and comment about the draft. There are some questions in the Gen-ART review. I also see minor issues listed in the AppsDir review. As there wasn't any response I consider that these reviews have not been addressed. There are also some comments received during the WGLC which are outstanding. Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Tue Apr 30 18:05: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 D78A721F888C for ; Tue, 30 Apr 2013 18:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tv-AI+ceIGeQ for ; Tue, 30 Apr 2013 18:05:23 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B47321F884F for ; Tue, 30 Apr 2013 18:05:23 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 56D2DD0408A; Tue, 30 Apr 2013 20:05:22 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367370322; bh=nzyBXEYS75eYi0oDrZ71peMIAq58VLmCcGvYXkp0p3g=; h=In-Reply-To:References:Subject:From:Date:To:From; b=IdVCQPLdPW3DrcMH4Q/dFwKvIX1WTx/HG9+I/3XY/zU8CMbO8ukKRTsOBVBTjQRD9 r34VbUf1W6ImmwbxsUsCKe4qxzO9X+2rQ/WLDhvu8xE/bgOFMlr4bF47MZeEt0plDt 6vCjniUPfrLV289jvYqWHgAgo/Aa3yuwOczTdiUQ= 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 E8D3ED04084; Tue, 30 Apr 2013 20:05:21 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130430172422.0d6ca9c8@resistor.net> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <6.2.5.6.2.20130430111045.0a7ebc30@elandnews.com> <3198772.42M6YQxPyW@scott-latitude-e6320> <6.2.5.6.2.20130430172422.0d6ca9c8@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 30 Apr 2013 21:05:19 -0400 To: S Moonesamy ,spfbis@ietf.org Message-ID: <7d677814-3b49-4a87-bfe3-d36c6f14378e@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 01:05:24 -0000 No. What I meant was that I would reply to each of those and indicate if I thought change was warranted. I haven't done this yet. In some cases there was follow-on commentary about one of the reviews. If it makes sense I'll try to comment on each issue in only one place. For avoidance of doubt, I didn't read anything in the stack of messages about removing type SPF that caused me to consider changes needed. Scott K S Moonesamy wrote: >Hi Scott, >At 16:26 30-04-2013, Scott Kitterman wrote: >>Those, msk's review, and yours are outstanding. In other cases where >there's >>been on list discussion that led me to think a change was merited, >I've >>mentioned it. > >I am not sure I understood the above correctly. My reading of the >quoted text (excluding the first sentence) is that you would comment >on the AppsDir, SecDir and Gen-ART reviews if a change was >merited. I don't see any messages from you in the SPFBIS mailing >list archive. I presume in your opinion that no change is merited. > >There are 74 pages in draft-ietf-spfbis-4408bis-14. The reviewers >from AppsDir, SecDir and Gen-ART have taken the time to read these 74 >pages and comment about the draft. There are some questions in the >Gen-ART review. I also see minor issues listed in the AppsDir >review. As there wasn't any response I consider that these reviews >have not been addressed. > >There are also some comments received during the WGLC which are >outstanding. > >Regards, >S. Moonesamy (as document shepherd) > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From marka@isc.org Tue Apr 30 18:05: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 E5D7521F888C; Tue, 30 Apr 2013 18:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbPOCqlgEdJC; Tue, 30 Apr 2013 18:05:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB6121F884F; Tue, 30 Apr 2013 18:05:57 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 675C1C942D; Wed, 1 May 2013 01:05:45 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367370357; bh=CKJVm/TxwpWQINbuo4dWkOhzTWD+9sLRJqqDa5PtJgk=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Xxpcth9e55jX85PPjzZQ/YBkJ/7upd3knOSJJUGdhLDUn7RuUCci1ocPVjyaacitB k96BfH+MI2RqaNw39AxZ4Tj10/Q9cXr3rQlLtxK+NH2GjGKAXy+k1vWfG6W2uCt7xA ROI3i66NZtXi9a2t+sQpmmLgSy4lUfZdDMat9Y74= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 1 May 2013 01:05:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:9565:f4f6:719e:3954]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D6239216C40; Wed, 1 May 2013 01:05:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id DE040336241D; Wed, 1 May 2013 11:04:55 +1000 (EST) To: Alessandro Vesely From: Mark Andrews References: <20130425013317.36729.qmail@joyce.lan> <4272263.gKzvRQiTlr@scott-latitude-e6320> <517C8994.2080102@gathman.org> <1457820.oICsLp4n8g@scott-latitude-e6320> <20130428195221.GA27654@besserwisser.org> <8D23D4052ABE7A4490E77B1A012B630775165072@mbx-01.win.nominum.com> <517DAB89.8000409@gathman.org> <8D23D4052ABE7A4490E77B1A012B63077516524E@mbx-01.win.nominum.com> <517E90A6.6090108@gathman.org> <8D23D4052ABE7A4490E77B1A012B630775166B76@mbx-01.win.nominum.com> <517EE00D.8050401@dcrocker.net> <517EE2E3.3010003@isdg.net> <20130429230742.3D2833339511@drugs.dv.isc.org> <517FF144.5040600@tana.it> In-reply-to: Your message of "Tue, 30 Apr 2013 18:28:52 +0200." <517FF144.5040600@tana.it> Date: Wed, 01 May 2013 11:04:52 +1000 Message-Id: <20130501010455.DE040336241D@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "" , ietf@ietf.org Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 01:05:58 -0000 In message <517FF144.5040600@tana.it>, Alessandro Vesely writes: > On Tue 30/Apr/2013 01:07:42 +0200 Mark Andrews wrote: > > > > The really annoying thing is that SPF is techically superior > > to TXT is lots of ways. > > > > 1. It uniquely identifies the roll of the record. > > > > 2. As SPF records are singletons you don't need to identify > > and remove the old record when updating. You can just > > remove all SPF record and add the replacement. > > > > For TXT you need to lookup the existing RRset, extract > > the v=spf1 record from it. You then need to create a > > UPDATE message to delete just that record as well as add > > the new TXT record. You then have to hope that no one > > else is performing a simultanious update as you may get > > two TXT v=spf1 records in the RRset. > > That's true, except that one has TXT records anyway. nsupdate update del example.com SPF update add example.com 3600 SPF v=spf1 .... send txt=`dig +short example.com TXT | \ sed -n -e '/^"v=spf1 /s/^/update del example.com TXT /p' \ -e '/^"v=spf1"$/^/update del example.com TXT /p'` nsupdate << EOF $txt update add example.com 3600 TXT v=spf1 .... send EOF But that doesn't work for 'example.com TXT "v" "=" "s" "p" "f" "1"' which is a perfectly legal SPF record. sed -n -e '/^"v=spf1 /s/^/update del example.com TXT /p' \ -e '/^"v" "=spf1 /s/^/update del example.com TXT /p' \ -e '/^"v" "=" "spf1 /s/^/update del example.com TXT /p' \ -e '/^"v" "=" "s" "pf1 /s/^/update del example.com TXT /p' \ -e '/^"v" "=" "s" "p" "f1 /s/^/update del example.com TXT /p' \ -e '/^"v" "=" "s" "p" "f" "1 /s/^/update del example.com TXT /p' \ -e '/^"v" "=" "s" "p" "f" "1" " /s/^/update del example.com TXT /p' \ -e '/^"v=spf1"$/^/update del example.com TXT /p'` And keep going because the delete needs the rdata to be a perfect match to identify the record to be removed. I'm sure I could come up with a more compact way of identifying a spf record but it wouldn't be needed if people published type SPF. > > The complains about using SPF is that there are broken >p > firewalls and some servers drop queries for it, some registars > > don't support it. > > Nits, as explained below. The basic fact that killed the SPF type is > the ability to use TXT as a replacement. There must be an analogous > of Gresham's law: "Bad types drive out good ones." > > > For firewalls, fix/replace the firewall if you intend to > > deploy SPF and it doesn't support it. It is total !@##@# > > that firewall are incapable of handling new DNS record > > types. New records we exected to occur from the very > > beginning and have been coming out regularly ever since the > > DNS was invented. Firewall vendors that are incapable of > > handling new DNS types are incompetent and do not deserve > > repeat business. > > > > For servers than drop SPF queries they really are at the > > noise level. When you identify one you complain to the > > owners of it. Yes, that does work. We needed to do that > > for AAAA records. > > > > For registrars, change registrar to one that does. > > While it's too late for SPF, we can learn this lesson. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Tue Apr 30 18:39: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 D7FDB21F884F for ; Tue, 30 Apr 2013 18:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=0.928, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd+KpWXP+StK for ; Tue, 30 Apr 2013 18:39:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id C6ED921F8825 for ; Tue, 30 Apr 2013 18:39:03 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id F0ACAC94B4; Wed, 1 May 2013 01:38:57 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1367372343; bh=p7Jkt9ONfxD7RXXerWo7QkubHQLAmdzwBlG2tAqOYOM=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=dndicZsrnceIS7wbKi8+EuSJFwFsn4BQ72brKfId6PZ5nBPKq7mB1NMwCSX7hOKj7 yYChzye6fyhsAwjZesp16zdgGjNMY4+Vj+tHgrgvZMrSldVN106QwRR7Icjr4BXnOD /8lZEzhJmbiLkBydx5n2+2FF0K3dOMVwh5rla+sY= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 1 May 2013 01:38:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 93C8F216C40; Wed, 1 May 2013 01:38:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6A71033629F9; Wed, 1 May 2013 11:38:46 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <6.2.5.6.2.20130429024006.0a9a7e18@elandnews.com> <6.2.5.6.2.20130430070019.0d6c3158@elandnews.com> In-reply-to: Your message of "Tue, 30 Apr 2013 10:57:05 -0700." Date: Wed, 01 May 2013 11:38:46 +1000 Message-Id: <20130501013846.6A71033629F9@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "spfbis@ietf.org" , S Moonesamy Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 01:39:05 -0000 In message , "Murray S. Kucherawy" writes: > > "When the result of macro expansion is used in a domain name query, if > >> the expanded domain name exceeds 253 characters (the maximum length > >> of a domain name), the left side is truncated to fit, by removing > >> successive domain labels (and their following dots) until the total > >> length does not exceed 253 characters." > >> > >> Where is it specified that the maximum length of a domain name is 253 > >> characters? > >> > >> > >> RFC1035 says it's 255. > >> > >> > >> ...which is to say I agree that I don't understand why it says 253 there. > >> > > > > Hmm, there's is another angle to this. I'll skip that discussion. 255 is the maximum WIRE length of a domain name. 253 is the maximum LDH domain name (no trailing period). 254 is the maximum LDH domain name (with trailing period). 1007 is the maxumum RFC 1035 presentation format (no trailing period). 3*63*4 + 3 + 62*4 If you need a buffer to hold all potential a nul terminated domains as a string you need 1009 bytes. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sm@elandsys.com Tue Apr 30 21:51: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 D817321F8B07 for ; Tue, 30 Apr 2013 21:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EvO+4qXe2RT for ; Tue, 30 Apr 2013 21:50:16 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF31221F8A80 for ; Tue, 30 Apr 2013 21:50:06 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.156.184]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r414nmOa011341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Apr 2013 21:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367383799; bh=zSy61YNhC8fNH2j0z5Xr6RUgw5XD8uU3kbrGVnPpqZk=; h=Date:To:From:Subject; b=s7WGQ0Kro0bXvJ7pNw9gO4DXumEKtPVf/MRJMgElulxJ48YLOQu7H6uE4EUC6r19H OWJXaNC0aO/d/AGPr8G8OVZRopPoHKZj9ttZWE438ec0gPA2F4OtwGI36VmrPrAdrN PgPGFDwATrCb1LbUwrbSvqClR/w4siCX4pnMNH+w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367383799; i=@elandsys.com; bh=zSy61YNhC8fNH2j0z5Xr6RUgw5XD8uU3kbrGVnPpqZk=; h=Date:To:From:Subject; b=G/9dG6GfcL2jMgNwfij1xhEcZiZZhqJg4b8QVS05TmZfLf60d4hUezwiIPokli/xe ptlxb4LB8r8kMYLddy7gVVtxlo9aKqvB5pQnxvuRp8XPspK1mrgrRT0XEUQ8eBJVqU NYvF60rUerH5rbQ3A95JSGFPyJJ61xGegYEhW2/Q= Message-Id: <6.2.5.6.2.20130430214922.0ce20be8@elandsys.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 30 Apr 2013 21:49:38 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 04:51:25 -0000 Hi Scott, At 18:05 30-04-2013, Scott Kitterman wrote: >No. What I meant was that I would reply to each of those and >indicate if I thought change was warranted. I haven't done this >yet. In some cases there was follow-on commentary about one of the >reviews. If it makes sense I'll try to comment on each issue in >only one place. Thanks. Could you please keep the directorate/review team comments separate from the other comments as I have to address them individually? >For avoidance of doubt, I didn't read anything in the stack of >messages about removing type SPF that caused me to consider changes needed. Noted. Regards, S. Moonesamy (as document shepherd)