From prvs=869786398=fmartin@linkedin.com Wed Jun 12 17:12: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 7FC9611E80F3 for ; Wed, 12 Jun 2013 17:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 w0RZXyCWKrfJ for ; Wed, 12 Jun 2013 17:12:00 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7A74721F944C for ; Wed, 12 Jun 2013 17:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1371082320; x=1402618320; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=YOayX0vAtDGV+q/vtZOy8Ls+RYHgRUkHa6Q6Yvp/avY=; b=nl/WHTRJw08tGBdh6tvw91D1P9AmF7fa9sRiE5NcJjD65qmNi5PMiy6/ hfxMXWoI/nyZ1Zm6JMrSIM9sK5ZjUACyR62L6/YaNj57IG+ZzT18xmaFH /Tg4fEayxRowXqzTgrB/5NypqC/KfEs3R1CZ3xIuwWpgIaIoC7OWQ9n5O 8=; X-IronPort-AV: E=Sophos;i="4.87,855,1363158000"; d="scan'208";a="50618591" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Wed, 12 Jun 2013 17:11:44 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 17:11:43 -0700 From: Franck Martin To: "spfbis@ietf.org" Thread-Topic: host bits in SPF Thread-Index: AQHOZ8qV2TQjNP1t1UGww4LimSkNzQ== Date: Thu, 13 Jun 2013 00:11:43 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE53247345@ESV4-MBX01.linkedin.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [spfbis] host bits in SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 Jun 2013 00:12:04 -0000 Could SPFbis, indicates the issue with CIDR notation Considering host A, network B and net mask C in the SPF record the CIDR notation should be strict A&C =3D=3D B While the spf check should use A&C =3D=3D B&C 207.68.169.173/30 is not valid in an SPF record but 207.68.169.172/30 is va= lid while the SPF library should not choke if it finds the first one in an SPF = record.= From sm@elandsys.com Wed Jun 12 20:00: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 6326421F8FB3 for ; Wed, 12 Jun 2013 20:00: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 sWMDoROahDTA for ; Wed, 12 Jun 2013 20:00:08 -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 90B8921F8C4B for ; Wed, 12 Jun 2013 20:00:06 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.233.32]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r5D2xsL8000241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jun 2013 20:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1371092406; bh=QKL0hkscUGIG/t7utJ+VVSxa//CsMq+mU09rXSPkr4s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=n8vjORdpL+X3FPI+iyDoUG1RF3Enzax7cbI7OzlsP8MZu5+Jcz6A/BcH9qPLbXcC4 l/ZamJbkmaM5N+Rlr8jZ1J562vPepPeHXgRMBEI7TeP9IYs5uTapAoJ+Wx7fvSqf2Q S4RgxLD6v1LBnR/lDU2g/YaFscFEZgUrMzVlL/Dw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1371092406; i=@elandsys.com; bh=QKL0hkscUGIG/t7utJ+VVSxa//CsMq+mU09rXSPkr4s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jqEobJHJeOPNxGTP2RCpxHiTI835imt9xdOVSiLk869A3Sq4z0/JFSQ+kvP+Y5Puj ezwuw5quO11KTmq5m4OW1gzcVj+dplqUptlC9qpID58vg6f08U9Pj/JOQZIF2YjcYC NjTRr+83IFges9wF+F27Nq7J9VJTAn4XNrCN9rKY= Message-Id: <6.2.5.6.2.20130612175114.06401e78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 12 Jun 2013 18:10:45 -0700 To: Franck Martin From: S Moonesamy In-Reply-To: <77426B543150464AA3F30DF1A91365DE53247345@ESV4-MBX01.linked in.biz> References: <77426B543150464AA3F30DF1A91365DE53247345@ESV4-MBX01.linkedin.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] host bits in SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 Jun 2013 03:00:11 -0000 Hi Franck, At 17:11 12-06-2013, Franck Martin wrote: >Could SPFbis, indicates the issue with CIDR notation > >Considering host A, network B and net mask C > >in the SPF record the CIDR notation should be strict A&C == B > >While the spf check should use A&C == B&C > >207.68.169.173/30 is not valid in an SPF record but 207.68.169.172/30 is valid > >while the SPF library should not choke if it finds the first one in >an SPF record. This is an individual comment. The prefix length is to identify an IP address block. The above example did not take the network part into account. Some people usually do sanity checks as they don't trust input. Regards, S. Moonesamy From spf2@kitterman.com Wed Jun 12 20:59:18 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586D521E8056 for ; Wed, 12 Jun 2013 20:59: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 8VTMIiotXgUl for ; Wed, 12 Jun 2013 20:59:07 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 183BD21E804D for ; Wed, 12 Jun 2013 20:59:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4496020E40D2; Wed, 12 Jun 2013 23:58:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1371095945; bh=v9oF/7qvG+eBhJ0vqfUa88UMHeBmxFz82K0l2SRRGRI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YQhC91TUgXnJ51fsc0JDDGifwyWrY0eJBZoAEorK3RqP+y+1sNxYwNyJ6b0Y70jzq uNsiKqx6f/JMW2s4aC+YlZkXxQWFotl6mZqBZLK+Ggh7pAGrPWF0FYdPa/gYnZ2N8O rdmvfO025ed9X277T7NAnyYkDfFsntLmrcG/js5Y= 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 2762D20E40C6; Wed, 12 Jun 2013 23:58:53 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 12 Jun 2013 23:58:53 -0400 Message-ID: <1936392.m4cci22yG2@scott-latitude-e6320> User-Agent: KMail/4.10.3 (Linux/3.8.0-23-generic; KDE/4.10.3; i686; ; ) In-Reply-To: <6.2.5.6.2.20130612175114.06401e78@resistor.net> References: <77426B543150464AA3F30DF1A91365DE53247345@ESV4-MBX01.linkedin.biz> <6.2.5.6.2.20130612175114.06401e78@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] host bits in SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 Jun 2013 03:59:18 -0000 On Wednesday, June 12, 2013 06:10:45 PM S Moonesamy wrote: > Hi Franck, > > At 17:11 12-06-2013, Franck Martin wrote: > >Could SPFbis, indicates the issue with CIDR notation > >Considering host A, network B and net mask C > >in the SPF record the CIDR notation should be strict A&C == B > >While the spf check should use A&C == B&C > >207.68.169.173/30 is not valid in an SPF record but 207.68.169.172/30 is > >valid > > > >while the SPF library should not choke if it finds the first one in > >an SPF record. > > This is an individual comment. The prefix length is to identify an > IP address block. The above example did not take the network part > into account. Some people usually do sanity checks as they don't trust > input. It is not a particularly rare error for SPF record publishers to publish CIDR ranges that don't correctly start at the network boundary. I think publishers SHOULD NOT do that, but they do. Verifiers SHOULD ignore the host bits that are set so that (from the example above), ip4:207.68.169.173/30 SHOULD be treated the same as ip4:207.68.169.172/30 (even though it SHOULD NOT be published that way). This is an area where it's, in my opinion, safe to apply Postel's Law and still be liberal about what we receive. Most SPF implementations that I'm aware of already treat CIDR blocks with host bits set this way, but not all. For consistency, it might make sense to specify correct behavior more explicitly. This came up in a discussion on another list. Scott K From superuser@gmail.com Wed Jun 12 22: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 B193921F8BC0 for ; Wed, 12 Jun 2013 22:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 ct9Iz-iiKL6i for ; Wed, 12 Jun 2013 22:44:55 -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 027EF21F8B35 for ; Wed, 12 Jun 2013 22:44:51 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so1170461wiw.5 for ; Wed, 12 Jun 2013 22:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WQY4F5rRgWZGcFLZ3zFrWwiF9BcqAZDpNP3zYV+6dXw=; b=VoR/2m+XUIK7hvrCnDlUV70czozHS2HdteM2SGIfARI1nDTOdMcwHDL5rKQPDkMq/h E4x35BB38+cAM0HmDcV/pwKY3ZOrTZZahKf5HPyHMtEEN+Urs8A360j1UMhqHM8n8LBZ Kw6gQ1+brqcJYFyNhrUsZkL5bYM5vjqMUSsFgtaspwd3WBlioXI/TRCkQAzmRjGnZkst 6R+4Qw/kD+amuN3Sp84N7ySieAnwMJ1A9xQTsEWh2SZZ0HI2Lm28jjyetMazlp6FhmDL v+1j9IAhh0/euoekK5vAP2g5uutkockiz2YmLMIeQnSUdIrrfzLEt4E7wHOFlUlSCTNJ Qxbw== MIME-Version: 1.0 X-Received: by 10.194.157.2 with SMTP id wi2mr14008768wjb.77.1371102291073; Wed, 12 Jun 2013 22:44:51 -0700 (PDT) Received: by 10.180.74.203 with HTTP; Wed, 12 Jun 2013 22:44:50 -0700 (PDT) In-Reply-To: <1936392.m4cci22yG2@scott-latitude-e6320> References: <77426B543150464AA3F30DF1A91365DE53247345@ESV4-MBX01.linkedin.biz> <6.2.5.6.2.20130612175114.06401e78@resistor.net> <1936392.m4cci22yG2@scott-latitude-e6320> Date: Wed, 12 Jun 2013 22:44:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e0122f54002a39004df02a14a Cc: "spfbis@ietf.org" Subject: Re: [spfbis] host bits in SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 Jun 2013 05:44:55 -0000 --089e0122f54002a39004df02a14a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 12, 2013 at 8:58 PM, Scott Kitterman wrote: > > At 17:11 12-06-2013, Franck Martin wrote: > > >Could SPFbis, indicates the issue with CIDR notation > > >Considering host A, network B and net mask C > > >in the SPF record the CIDR notation should be strict A&C == B > > >While the spf check should use A&C == B&C > > >207.68.169.173/30 is not valid in an SPF record but 207.68.169.172/30is > > >valid > > > > > >while the SPF library should not choke if it finds the first one in > > >an SPF record. > > > > This is an individual comment. The prefix length is to identify an > > IP address block. The above example did not take the network part > > into account. Some people usually do sanity checks as they don't trust > > input. > > It is not a particularly rare error for SPF record publishers to publish > CIDR > ranges that don't correctly start at the network boundary. I think > publishers > SHOULD NOT do that, but they do. Verifiers SHOULD ignore the host bits > that > are set so that (from the example above), ip4:207.68.169.173/30 SHOULD be > treated the same as ip4:207.68.169.172/30 (even though it SHOULD NOT be > published that way). > RFC4408bis as written explicitly ignores any host bits set beyond the CIDR prefix: The is compared to the given network. If CIDR prefix length high-order bits match, the mechanism matches. That looks like the test is (client_addr & mask == policy_addr & mask), which is perfectly valid to me. The spec doesn't put any correctness requirements on the publisher, but it does mean the protocol as defined is deterministic. I don't think needs to be changed. -MSK --089e0122f54002a39004df02a14a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 12, 2013 at 8:58 PM, Scott Kitterman <spf2@k= itterman.com> wrote:
> At= 17:11 12-06-2013, Franck Martin wrote:
> >Could SPFbis, indicates the issue with CIDR notation
> >Considering host A, network B and net mask C
> >in the SPF record the CIDR notation should be strict A&C =3D= =3D B
> >While the spf check should use A&C =3D=3D B&C
> >207.68.169.= 173/30 is not valid in an SPF record but 207.68.169.172/30 is
> >valid
> >
> >while the SPF library should not choke if it finds the first one i= n
> >an SPF record.
>
> This is an individual comment. =A0The prefix length is to identify an<= br> > IP address block. =A0The above example did not take the network part > into account. =A0Some people usually do sanity checks as they don'= t trust
> input.

It is not a particularly rare error for SPF record publishers to publ= ish CIDR
ranges that don't correctly start at the network boundary. =A0I think p= ublishers
SHOULD NOT do that, but they do. =A0Verifiers SHOULD ignore the host bits t= hat
are set so that (from the example above), ip4:207.68.169.173/30 SHOULD be
treated the same as ip4:207.68.169.172/30 (even though it SHOULD NOT be
published that way).

RFC4408bis as writ= ten explicitly ignores any host bits set beyond the CIDR prefix:
   The <ip> is compared to the given network.  If CIDR prefi=
x length
   high-order bits match, the mechanism matches.
That looks like the test is (client_addr & mask =3D=3D policy_add= r & mask), which is perfectly valid to me.

The spec doesn't = put any correctness requirements on the publisher, but it does mean the pro= tocol as defined is deterministic.=A0 I don't think needs to be changed= .

-MSK
--089e0122f54002a39004df02a14a-- From d.stussy@yahoo.com Thu Jun 20 22:40: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 5E1C211E80F6 for ; Thu, 20 Jun 2013 22:40:47 -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 ydQxkNyOKqlh for ; Thu, 20 Jun 2013 22:40:42 -0700 (PDT) Received: from nm9.access.bullet.mail.sp2.yahoo.com (nm9.access.bullet.mail.sp2.yahoo.com [98.139.44.136]) by ietfa.amsl.com (Postfix) with ESMTP id 03D4211E80F1 for ; Thu, 20 Jun 2013 22:40:42 -0700 (PDT) Received: from [98.139.44.107] by nm9.access.bullet.mail.sp2.yahoo.com with NNFMP; 21 Jun 2013 05:40:41 -0000 Received: from [98.139.44.85] by tm12.access.bullet.mail.sp2.yahoo.com with NNFMP; 21 Jun 2013 05:40:41 -0000 Received: from [127.0.0.1] by omp1022.access.mail.sp2.yahoo.com with NNFMP; 21 Jun 2013 05:40:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 913314.29507.bm@omp1022.access.mail.sp2.yahoo.com Received: (qmail 99166 invoked by uid 60001); 21 Jun 2013 05:40:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1371793241; bh=nSa2Lpu/QgGVJVbQY2kou2aY/ulUke8F9tfqXsofUbo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yQ54Gvkjth2q496ap0y7BjCqy2ER49fjnZubMMzQNNjH3Mvfo5XFkNE5uic6xDYReNFUmH+FJEfJbE6w6IPrZ5jDyjDDZxvkiuAbBm5fDuH+0ieLg0oLDdNj+9YHdfyRrsaYHdTSYCGlD8rlSocpe4MOpx3JearINn5MHo6DHJY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=k5mPHTDLC7XET3oM0MXipxIEwOCYZ+1+ZaJmd/EwWCQ6+ygEMy5pz7owlTWtTy4JJq2IOnJ+aF1ULdMmZ0Hx2m3UuwMVZHwMI9hbT+J1jwGaFwiNQ6cd/GcL6iQ99HUbTDlsxyDPJtRvyuouV8HPhSh3Gb6fHvo0Pf4MUrZad74=; X-YMail-OSG: M_ofEDEVM1ku5rDXKOoQL..cVEPQUnjZNC0T0iPKQSNtjAl iwEn3IPV6wrqvsHegpW.nfpprHx1VVW45OfWiIjRc5B83ADY6msDozJjxLxG CBbk9GzPMl4Fip4zTGVJ0HtcQq3rzzMs3UHyNa.Db4CmLJhQu8EdfXvdnhWB JQrVlVGZ.fKp6H6IDUCC3Arg_Jd4POmSrKGs7I14ESOQvmRJmlKqfrzqabi2 asZ8Io7BGaEMtsfAPw80NYQPTSKmU69VNFNb2D.pT_GH_CDWjuag_SjggY_z JqmcZoMnX9yLIZUcH21Ml3bjAaN3kkn9JDR.6fd7OBBzziwOiRK4gmAXNHw3 pJapj6hS0UxUhdFTNPLqAA29bFxBCyVGBkqmoPsn.2ZONnhs3KA4krtqpNxk e.ncZaRLONmT_fLlICxHp.ED2p0yyBS5u1urcwdO3jSFWVmypLiEU8qDFgd4 RnZmcRjf5d.GoYcm_QARsvC4_hKdHDOuPrkISPiVZVOzXaTBupe25BMTX829 k0rufiCfLL.W5tWxqDz6WZ5EO7I7nQSswU_5MVbr4YTkNxKxcCIcPUCSEFl4 _tRDuZNfugs8Cf6.bkrmTDy86OTKoKY0wtJzSrDifI0e9Bgd_NmVAOL6XM6z 7Q7BqUNP_kegy.T9o9wywOeS8Zwa1wwmmqtpPr9d_DaezkYNzOJAziALq6ff D8vh_VYXSuaGmu9XlUp6eck7hfLOqL83jJ3wogMsT5gG8DIS0ce1c9DB4YD8 - Received: from [71.105.105.145] by web84506.mail.ne1.yahoo.com via HTTP; Thu, 20 Jun 2013 22:40:41 PDT X-Rocket-MIMEInfo: 002.001, T0suICBUZWNobmljYWxseSwgSSBkb24ndCBiZWxvbmcgdG8gdGhlIG1haWxpbmcgbGlzdCwgYnV0IG1heWJlIGl0IHdpbGwgbGV0IG1lIHBvc3QgaXQuDQoNCi0tLSBPbiBUaHUsIDYvMjAvMTMsIFNjb3R0IEtpdHRlcm1hbiA8c2NvdHRAa2l0dGVybWFuLmNvbT4gd3JvdGU6DQo.IFRoZSBwdWJsaWMgZGlzY3Vzc2lvbiBsaXN0IGZvciB0aGlzIGRyYWZ0IGlzIHNwZmJpc0BpZXRmLm9yZy7CoA0KPiBJZiB5b3Ugc2VudCB5b3VyIGNvbW1lbnRzIHRoZXJlLCBpdCdzIG1vcmUgbGlrZWx5IHRvIGdldCBhIHJldmkBMAEBAQE- X-Mailer: YahooMailClassic/16.0.3 YahooMailWebService/0.8.148.554 Message-ID: <1371793241.92610.YahooMailClassic@web84506.mail.ne1.yahoo.com> Date: Thu, 20 Jun 2013 22:40:41 -0700 (PDT) From: d.stussy@yahoo.com To: Scott Kitterman In-Reply-To: <1498253.k6mPMg0Tbh@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 20 Jun 2013 22:45:23 -0700 Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF Draft 15. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 21 Jun 2013 05:40:47 -0000 OK. Technically, I don't belong to the mailing list, but maybe it will let= me post it. --- On Thu, 6/20/13, Scott Kitterman wrote: > The public discussion list for this draft is spfbis@ietf.org.=A0 > If you sent your comments there, it's more likely to get a review of > your comments. >=20 > Scott K >=20 > On Thursday, June 20, 2013 06:34:52 PM you wrote: > > Re - URL: http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/?i= nclude_text=3D1 > >=20 > > Comments (also posted to Usenet ->=A0news:comp.mail.misc): > >=20 > > Section 3.1:=A0 I would strongly DISAGREE with this and suggest that it= is use > > of TXT-RRs for SPF records that should be deprecated.=A0 The TXT-RR was > > conceived to convey HUMAN-READABLE information. SPF information is > > intended as machine readable (i.e. to be automatically processed as > > needed).=A0 The SPF-RR should be kept to prevent pollution of the TXT-R= R with > > non-human-readable information.=A0 See also the RP resource record for = an > > additional use of the TXT-RR. > >=20 > > I do agree that it is past time that the transitional use of both types= of > > resource records should cease.=A0 At the time of publication of the doc= ument > > as an RFC, there will be some parties that both resource record types i= n > > use.=A0 Although you state that such practice should be discontinued, y= ou > > should include a specific "sunset date" where checking for both types > > should also cease. > >=20 > > DomainKeys doesn't suffer this pollution effect because it defines spec= ific > > DNS labels for its use of the TXT-RR, while SPF requires that its label > > match that of any subdomain in a given zone that is used as a mail sour= ce > > in mailbox addresses (or outbound server names for the "HELO" SMTP > > parameter).=A0 This usage may overlap with human-readable usages. > >=20 > >=20 > > Section 8.2:=A0 Treating a "neutral" result the same as "none" may not = be > > appropriate in all contexts.=A0 In fact, in my personal SpamAssassin sc= oring > > functions, I assign the results DIFFERENT scores.=A0 Therefore, I must > > disagree with your comments about harshness.=A0 Neutral is an explicit > > expression while none is the absence of such.=A0 They are not the same. > >=20 > >=20 > > Section 8.4:=A0 I disagree with the use of enhanced status code "5.7.1"= , > > finding that "5.7.7" ("Message integrity failure") is a better response= .=20 > > "5.7.1" should be used for rejections per local policy, not remote poli= cy. > >=20 > >=20 > > Section 8.7:=A0 I disagree with the use of enhanced status code "5.5.2"= (SMTP > > "syntax error"), finding that "5.7.8" ("Invalid authentication > > credentials") is a better response.=A0 The problem is not with the SMTP > > transaction itself but with message source authentication. > >=20 > >=20 > > Section 9.1 (and 13.2):=A0 I also disagree with the inclusion of sectio= n 9.1 > > ("Received-SPF" header) in favor of ONLY the "Authentication-Results" > > header described in RFC 5451 and referenced in section 9.2.=A0 Note als= o that > > RFC 5451 introduced an additional result:=A0 "Policy"=A0 (cf. my next > > paragraph). > >=20 > >=20 > > Additional (new section 11.8?):=A0 In section 5.5, you indicate that us= e of > > the "ptr" mechanism is discouraged.=A0 However, you then fail to addres= s > > certain other potentially malicious constructs as "+all" or an equivale= nt > > combination (e.g.) of "ip4:0.0.0.0/1 ip4:128.0.0.0/1"; in fact, any > > mechanism that has a CIDR mask of less than "/8" (IPv4, or "/12" for IP= v6). > >=A0 I reject these (CIDRs less than 8, including "+all") with "5.7.9" > > ("Mechanism too weak").=A0 You use this example in appendix section B.1 > >=20 > > It appears as if you have not read the Wikipedia discussion about SPF a= t > > http://en.wikipedia.org/wiki/Talk:Sender_Policy_Framework.=A0 Maybe you > > should review it.