From sm@elandsys.com Thu Oct 4 16:37:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A0921F8669 for ; Thu, 4 Oct 2012 16:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-8EIWQ5KUDf for ; Thu, 4 Oct 2012 16:37:36 -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 3102E21F8668 for ; Thu, 4 Oct 2012 16:37:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.24]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q94NbLjg024312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Oct 2012 16:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349393854; bh=2gM/PzyOSe0ZfqE/KTl7S7jk/SRwm2nT9OBd+dKtdrc=; h=Date:To:From:Subject:Cc; b=uVa9dbmEcOq7A2q+Xh8FXubfb/XlEFhSu2WpSF1/OU5pn8T8yASbOlxveLsBTinfO o/zbvKCcuB0AH0yDtmxDnwCA0hbWr3g+CRQQdyQK5buq61gdj2XMGIauMh/nYEbucK MViRK7ZT/WLoZu21cdvxCHr8YU2pciyE2n8EG/00= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1349393854; i=@elandsys.com; bh=2gM/PzyOSe0ZfqE/KTl7S7jk/SRwm2nT9OBd+dKtdrc=; h=Date:To:From:Subject:Cc; b=oGQeGFhutWf5IrsW9bngJ4a9g2yu0X64nKB50cOS4EvI+W3S4uL4wUv6DUhhdn7T0 o38L3UIPGO/IzhB4ElZwOstL7L/pPk3iyKvOogSuu12nGzrfGfaaHTYxTLJlxcDGLN eS4K+dQ/2FdPBJb30+AUhTHAFJU8k3QOmLxOtHc0= Message-Id: <6.2.5.6.2.20121004163257.09d8f2c8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 04 Oct 2012 16:34:47 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Requested session has been scheduled for IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Oct 2012 23:37:36 -0000 Hello, The WG session at IETF 85 is scheduled as follows: spfbis Session 1 (1:30:00) Wednesday, Afternoon Session I 1300-1430 Room Name: Room 209 Regards, S. Moonesamy From spf2@kitterman.com Thu Oct 4 22:46:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F93121F85C3 for ; Thu, 4 Oct 2012 22:46:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoivGrzPsiUR for ; Thu, 4 Oct 2012 22:46:05 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 85DE921F85C4 for ; Thu, 4 Oct 2012 22:45:55 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7027920E4104; Fri, 5 Oct 2012 01:45:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1349415954; bh=GIB7Ge5jWnJXmdV4IaG7NDOFbaVcwkLJ+EKriAQGwv8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VV5a5qBXHPbahoKvCvYek9CCE09vgUxJqay/7fVwGajOOo+k3fCzOYug2tFBRb+gP 0f/0bXECHNCFyssRrJ2p9ZzcbT4y3miSm+AjyPgFSF7CTJYYaFfcVrN2Miw+jWjFBi XnePwYeIS4OqZkcatpU5V1m7QwxubAPiatjhf2Kw= 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 4F81620E4085; Fri, 5 Oct 2012 01:45:53 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 05 Oct 2012 01:45:53 -0400 Message-ID: <2534134.LqkoMrYyBR@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20121004163257.09d8f2c8@elandnews.com> References: <6.2.5.6.2.20121004163257.09d8f2c8@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] Requested session has been scheduled for IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Oct 2012 05:46:06 -0000 On Thursday, October 04, 2012 04:34:47 PM S Moonesamy wrote: > Hello, > > The WG session at IETF 85 is scheduled as follows: > > spfbis Session 1 (1:30:00) > Wednesday, Afternoon Session I 1300-1430 > Room Name: Room 209 It would be nice, for those of us who don't go to or pay close attention to the IETF meeting schedules, you could mention the date. Scott K From sm@elandsys.com Fri Oct 5 00:11:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B9121F861C for ; Fri, 5 Oct 2012 00:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xceShy-7uzaj for ; Fri, 5 Oct 2012 00:11:43 -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 E582C21F85E7 for ; Fri, 5 Oct 2012 00:11:42 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.236.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q957BSw7000007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 00:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349421100; bh=OmegAE1LSpfiZ+Nntyko5XY0wegRMw3nTVLHTz7Y7pc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fsq+EvdItqJ4iSQYTOS7C07m4NTHNQ0maUIxKGfY3wd5cr+48R9jvn7NP8o7LIxEm L2VOrr3rA/eFVUMomIuEgtUitD+GENz/nAwHvBgunMmhXz8oTphblme4rFk1QiYRS5 rjDEEaPcqYv4HrrA+8gMWPI0yuq19UFgVXYMBiwE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1349421100; i=@elandsys.com; bh=OmegAE1LSpfiZ+Nntyko5XY0wegRMw3nTVLHTz7Y7pc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DfQkIWJ+zUG7IlQanVj0EOlpWbK2+gJcN9N9YWdRL80L9H3rh+rsSbM4YswMIPHSl TC55lRyXbULQqkJgfCIuuqCF3ekYLmcie6TpxJrltNJ+sihYyBvik3WJ/3Xc4ZmsZv apqWYKyDvESSc9gLp6fvdChoenOo2i1cvSEqP5XE= Message-Id: <6.2.5.6.2.20121005000653.0bab8410@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 05 Oct 2012 00:09:17 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <2534134.LqkoMrYyBR@scott-latitude-e6320> References: <6.2.5.6.2.20121004163257.09d8f2c8@elandnews.com> <2534134.LqkoMrYyBR@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Requested session has been scheduled for IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Oct 2012 07:11:43 -0000 Hi Scott, At 22:45 04-10-2012, Scott Kitterman wrote: >It would be nice, for those of us who don't go to or pay close attention to >the IETF meeting schedules, you could mention the date. It's on November 7, 2012. Please note that IETF agendas are subject to change, up to and during the meeting ( https://datatracker.ietf.org/meeting/85/agenda.html ). Regards, S. Moonesamy From spf2@kitterman.com Fri Oct 5 05:01:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BF521F86E4 for ; Fri, 5 Oct 2012 05:01: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIil9SoFek+H for ; Fri, 5 Oct 2012 05:01:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B97A421F8498 for ; Fri, 5 Oct 2012 05:01:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9FFBA20E4104; Fri, 5 Oct 2012 08:01:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1349438492; bh=xIsIJN7CEDz14g6lYpcST1CFV9PNk8NP6BJESawrnsM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DCnsp0Qz1yI0f3nqs8o/hhGmDTWqcAXP8IG8hUOo2qPc9zeguxozJg6a9V9ulPu+e cZYvmfCKF7kRgqyBcul0+OaUVBQMNXtP+qQCdIeZD1iq2xrRKqMZgAJW5YTxv48UqO OWrI/43syJ0cb9krV+foRrwy7F6ZV/52OrONlEk4= 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 78DFD20E408E; Fri, 5 Oct 2012 08:01:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 05 Oct 2012 08:01:31 -0400 Message-ID: <7757790.fyoOxyZYIh@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20121005000653.0bab8410@resistor.net> References: <6.2.5.6.2.20121004163257.09d8f2c8@elandnews.com> <2534134.LqkoMrYyBR@scott-latitude-e6320> <6.2.5.6.2.20121005000653.0bab8410@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] Requested session has been scheduled for IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Oct 2012 12:01:35 -0000 On Friday, October 05, 2012 12:09:17 AM S Moonesamy wrote: > Hi Scott, > > At 22:45 04-10-2012, Scott Kitterman wrote: > >It would be nice, for those of us who don't go to or pay close attention to > >the IETF meeting schedules, you could mention the date. > > It's on November 7, 2012. Please note that IETF agendas are subject > to change, up to and during the meeting ( > https://datatracker.ietf.org/meeting/85/agenda.html ). Thanks. Unfortunately I won't be able to attend (not even remotely). I do anticipate having time next week to start working on the draft again. Scott K From sm@elandsys.com Fri Oct 5 05:52:04 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA6B21F86F3 for ; Fri, 5 Oct 2012 05:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSy2cGZfdylW for ; Fri, 5 Oct 2012 05:52: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 49D3F21F86EE for ; Fri, 5 Oct 2012 05:52:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.236.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q95CphQa000532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Oct 2012 05:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349441520; bh=C2NpE+xpSGTexZckrKoudbewH+M8DBUU8yrYi3szGCc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Ymz7zB8wZ1fS7vNedIQA1aIzhTtifyBP3fIKpU70EjU4Hd53aNVrseUb/DGR5ZYv9 PRK2Y9RB4REHQlPB/I2ABgmWNBPVXJzKPrr4uCctoZSBF4vWEixYgt1joZ+1zk4Cvt 2z26uqxkGQ2NyybPs99S5oduWIqa2s952feBXCbA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1349441520; i=@elandsys.com; bh=C2NpE+xpSGTexZckrKoudbewH+M8DBUU8yrYi3szGCc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Hp85UQaGQVjeEnH5f/RQHfYmm0PO0budh0V4OVPApUtCba1jnYs/KcxJfBbfa4v76 Y87WEOkPC7sEv7PN32ZvkzxPWDGVFuAn8SKJgxV1gwnMpqkoO2y5Xrgx2M2+7Y+REU bAZy4FLu1mQBLg17KG4kPxXjHuQR+2XFYYAg6m7I= Message-Id: <6.2.5.6.2.20121005053309.0b3e7f90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 05 Oct 2012 05:45:27 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <7757790.fyoOxyZYIh@scott-latitude-e6320> References: <6.2.5.6.2.20121004163257.09d8f2c8@elandnews.com> <2534134.LqkoMrYyBR@scott-latitude-e6320> <6.2.5.6.2.20121005000653.0bab8410@resistor.net> <7757790.fyoOxyZYIh@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Requested session has been scheduled for IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Oct 2012 12:52:04 -0000 Hi Scott, At 05:01 05-10-2012, Scott Kitterman wrote: >anticipate having time next week to start working on the draft again. Please note that the cut-off date for submitting a revision of a draft is October 22, 2012. If you plan to submit a revision of the draft I suggest doing it before the cut-off date. Regards, S. Moonesamy From Internet-Drafts@ietf.org Tue Oct 23 14:44:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939EC11E8101; Tue, 23 Oct 2012 14: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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnrO--R-ANTE; Tue, 23 Oct 2012 14:44:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6870211E8102; Tue, 23 Oct 2012 14:44:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121023214402.6038.94597.idtracker@ietfa.amsl.com> Date: Tue, 23 Oct 2012 14:44:02 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D ACTION:draft-ietf-spfbis-4408bis-08.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, 23 Oct 2012 21:44:03 -0000 --NextPart 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) : D. Kitterman Filename : draft-ietf-spfbis-4408bis Pages : 66 Date : Oct. 23, 2012 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-spfbis-4408bis-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-spfbis-4408bis"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-10-23144359.I-D@ietf.org> --NextPart-- From spf2@kitterman.com Tue Oct 23 15:22:34 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F7511E80E2 for ; Tue, 23 Oct 2012 15:22:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMoR1CJ-vMtz for ; Tue, 23 Oct 2012 15:22:33 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFCE1F0C9C for ; Tue, 23 Oct 2012 15:22:33 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id C6321D04089; Tue, 23 Oct 2012 17:22:31 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1351030951; bh=VOUZhYF/V4oyVznMRaxJaADuigUWOUy/VnLVmn37Gvo=; h=In-Reply-To:References:Subject:From:Date:To:From; b=hEF4dL7J4Qe7Gwle1bB+I8elHIdLNI+9vEKyhgyvR7S1T73AOuCIKgAn0ZQl+UDnP r+STVrS/GvWyF6zbTCy76yjD5EjHg1zKkbunLFbbXlqpMYDOcozrpGIhuXbaX2FQgO m1fr6fIPH/vBEwmjsEbdjSFISIP0hZJrighEr2rQ= Received: from [IPV6:2600:1003:b003:9033:5e2:39a2:5d24:6ee4] (unknown [IPv6:2600:1003:b003:9033:5e2:39a2:5d24:6ee4]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6A0DDD0401E; Tue, 23 Oct 2012 17:22:31 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <20121023214402.6038.94597.idtracker@ietfa.amsl.com> References: <20121023214402.6038.94597.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 23 Oct 2012 18:22:29 -0400 To: spfbis@ietf.org Message-ID: <28ab430d-c7a8-4b57-9d8d-d33112d65b3a@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D ACTION:draft-ietf-spfbis-4408bis-08.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, 23 Oct 2012 22:22:34 -0000 This is a relatively minor update to get us going again. I reviewed the 2119 words that I added and backed a number of them out and resolved the empty label issue in favor of documenting it could be either no match or permerror since there are implementations that do both and I don't see any chance of a strong consensus emerging that one is significantly better tag n the other. Scott K P.S. Sorry for the late update. I got confused about which timezone was relevant for the posting deadline. 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) : D. Kitterman > Filename : draft-ietf-spfbis-4408bis > Pages : 66 > Date : Oct. 23, 2012 > >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. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-spfbis-4408bis-08.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > >------------------------------------------------------------------------ > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From ajs@anvilwalrusden.com Wed Oct 24 07:47:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA3D21F8A9F for ; Wed, 24 Oct 2012 07:47:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub4hblBdotmH for ; Wed, 24 Oct 2012 07:47:45 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C0E8221F8818 for ; Wed, 24 Oct 2012 07:47:45 -0700 (PDT) Received: from mx1.yitter.info (dhcp-222-230.meetings.nanog.org [199.187.222.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B5CBA8A031 for ; Wed, 24 Oct 2012 14:47:40 +0000 (UTC) Date: Wed, 24 Oct 2012 10:47:11 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20121024144710.GC52972@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] Draft agenda up X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Oct 2012 14:47:46 -0000 Dear colleagues, I just uploaded a proposed agenda for our meeting in Atlanta. The point of having a face to face meeting is to try to hash out the different points that were made during the "proposed reorganization" discussion. The discussion on list was not going anywhere, we felt; that's the ideal sort of topic for which a face to face meeting is appropriate. If you have other items for the agenda, please send such requests to the chairs. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Wed Oct 24 09:42:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B7121F8C8D for ; Wed, 24 Oct 2012 09:42:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0flHNfP5GtJ for ; Wed, 24 Oct 2012 09:42:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 89FC821F8C81 for ; Wed, 24 Oct 2012 09:42:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A233C20E4104; Wed, 24 Oct 2012 12:42:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1351096971; bh=AM+PkV+Su6/VhIi30YrVFUl8q0Ksx4ymMUN+e08cdVw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bWvMTVdf5PJDLnY1oIuMR6Zdf0vz+Nv3lD7Tbj41YwuPT4UspZpoUu9kE7a/aZQ2/ YPAy3PQjcc3rVGZm7jLY/XTiqEs5X81sMYzC6uHFGJ8nXdW+zSrRhjBb9x4/2s7CIH +1vDZlhF9iDiajgEUsrD4RRKHklsIqNd6lYf1lts= 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 7722820E4097; Wed, 24 Oct 2012 12:42:50 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 24 Oct 2012 12:42:50 -0400 Message-ID: <1989111.EuOVcBmg6E@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-17-generic; KDE/4.9.2; i686; ; ) In-Reply-To: <20121024144710.GC52972@mx1.yitter.info> References: <20121024144710.GC52972@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] Draft agenda up X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Oct 2012 16:42:53 -0000 On Wednesday, October 24, 2012 10:47:11 AM Andrew Sullivan wrote: > Dear colleagues, > > I just uploaded a proposed agenda for our meeting in Atlanta. > > The point of having a face to face meeting is to try to hash out the > different points that were made during the "proposed reorganization" > discussion. The discussion on list was not going anywhere, we felt; > that's the ideal sort of topic for which a face to face meeting is > appropriate. > > If you have other items for the agenda, please send such requests to > the chairs. It will be a somewhat one sided discussion, since I'm not available to participate (even remotely). Scott K From barryleiba@gmail.com Wed Oct 24 14:34:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8157B21F8BD4 for ; Wed, 24 Oct 2012 14:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.095 X-Spam-Level: X-Spam-Status: No, score=-103.095 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Q7f7FYctOlf for ; Wed, 24 Oct 2012 14:34:55 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8E2221F8BC2 for ; Wed, 24 Oct 2012 14:34:54 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1156582vcb.31 for ; Wed, 24 Oct 2012 14:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=f8xIUPiS5f0fgis6krAFWqlkS4ikq8jZEwj52ZHKt64=; b=oSqezqhC6C9g3jr98Xysx5zcCO6wDFk35qjkRwFpo/Gh9WsN589DsS1pMDOLnoFgwO gBxExRvhaWwkb88XoI2hsBgYei7zhh4g1KBD2JdkF3NVbA8xSaL9/Lxwu9EcUY48javi 4C63qazg/VHNcI3k8eogsF2UnwuKI/5zy3ZKxSBdCwQqopjCaynkKQp0xoBG28kvqC5C 1r+Zbil2Sz9mKT5La8SJURIzJieINy507dS3hkLwMf7Usalv3puubR3GVbw+cjcvbbGt SyyugP7eQ1xRiY2tZUm3nCLnZJ4twszJ1gkMZAaHCY4ie1GFtscODbFgKlkASBDL+1Au s0ww== MIME-Version: 1.0 Received: by 10.52.65.51 with SMTP id u19mr23353266vds.3.1351114494454; Wed, 24 Oct 2012 14:34:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Wed, 24 Oct 2012 14:34:54 -0700 (PDT) Date: Wed, 24 Oct 2012 17:34:54 -0400 X-Google-Sender-Auth: Hs9qO_ynXiKzcN_Sb8MWzy5pb5E Message-ID: From: Barry Leiba To: spfbis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Pete Resnick Subject: [spfbis] Move SPFBIS to 17:30 on Thursday X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Oct 2012 21:34:55 -0000 Agenda folks (bcc), I believe there's an open spot in Room 209 at 17:30 on Thursday. We need to move SPFBIS to accommodate a critical remote participant, and that time will work. Will you please move SPFBIS to 17:30 on Thursday? It's OK that the time slot is shorter, and the room size doesn't matter. Thanks, Barry (for vacationing Pete) From ajs@anvilwalrusden.com Thu Oct 25 11:27:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9B621F88A7 for ; Thu, 25 Oct 2012 11:27:32 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANMxvV8Tf+53 for ; Thu, 25 Oct 2012 11:27:31 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2A20721F86F6 for ; Thu, 25 Oct 2012 11:27:30 -0700 (PDT) Received: from mx1.yitter.info (dhcp-222-230.meetings.nanog.org [199.187.222.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 16F638A031 for ; Thu, 25 Oct 2012 18:27:28 +0000 (UTC) Date: Thu, 25 Oct 2012 14:27:03 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20121025182703.GB55929@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] [agenda@ietf.org: spfbis - Requested session has been scheduled for IETF 85] X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Oct 2012 18:27:32 -0000 Dear colleagues, We've been rescheduled. This solves a problem that the current draft editor wasn't previously able to join the meeting. Best, A ----- Forwarded message from "\"IETF Secretariat\"" ----- Date: Thu, 25 Oct 2012 09:12:00 -0700 From: IETF Secretariat To: ajs@anvilwalrusden.com Cc: spfbis-ads@tools.ietf.org, sm+ietf@elandsys.com, ajs@anvilwalrusden.com, wlo@amsl.com Subject: spfbis - Requested session has been scheduled for IETF 85 Dear Andrew Sullivan, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. spfbis Session 1 (1:30:00) Thursday, Afternoon Session III 1730-1830 Room Name: Room 209 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Area Name: Session Requester: Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 35 Conflicts to Avoid: First Priority: appsawg dane eai weirds precis Second Priority: imapmove Special Requests: We'd like Meetecho or WebEx because we almost certainly will have remote participants. --------------------------------------------------------- ----- End forwarded message ----- -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Thu Oct 25 21:53:04 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EFB21F85CF for ; Thu, 25 Oct 2012 21:53:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4XGQ3b1hLVk for ; Thu, 25 Oct 2012 21:53:04 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E4F0121F85C2 for ; Thu, 25 Oct 2012 21:53:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 725A220E4104; Fri, 26 Oct 2012 00:53:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1351227182; bh=9uvkJiVjKsHmzrzGG1aJaYIbNBbHyPioiVvnBZuI4XU=; h=From:To:Subject:Date:From; b=jKZH2CPOe0j1o4LEPUSdO+SGtWkTuj21M6iLhWPYH3/P/t9rgx7wXctiHglH0cUQk setYmDjlWoYCvmxiR26s1XoShpwgtxb2lz25/fpGQqayFGqZEw5LWRlVah+mvAc2ng 2+Oscl3T3+QsgBnj6TMRJDZ8hnN8BMn1dDzfQ4qs= 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 2E0B820E4062; Fri, 26 Oct 2012 00:53:01 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Oct 2012 00:53:01 -0400 Message-ID: <1610807.KLN8qAgPhL@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-17-generic; KDE/4.9.2; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] New (minor) issue: Inconsistency on ip4: address format X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Oct 2012 04:53:04 -0000 The ABNF for an IPv4 address is: ip4-network = qnum "." qnum "." qnum "." qnum (paragraph 5.6 and the collected ABNF). At the beginning of paragraph 5 there is a general statement about how ip4/6 mechanisms with CIDR lengths are processed: If a CIDR prefix length is specified, then only the specified number of high-order bits of and the IP address are compared for equality. Both of these items are unchanged between RFC 4408 and the current WG draft. I just got an email complaining that my SPF record validator was wrong because it calls ip4:198.51.100/24 a syntax error (which it is per the ABNF) because the correspondent claimed that since the low-order bits weren't compared for equality, they didn't need to be provided. I can see the source of their confusion. Is the sentence about only comparing the specified number of high order bits really needed or is that just a note about implementation? If we could just drop it, it would remove this source of confusion. As long as it wouldn't lose something substantive in the processing definition, I think we should do that. Opinions? Scott K From barryleiba.mailing.lists@gmail.com Fri Oct 26 10:43:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EB821F860D for ; Fri, 26 Oct 2012 10:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.14 X-Spam-Level: X-Spam-Status: No, score=-103.14 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPLatBP1NyqS for ; Fri, 26 Oct 2012 10:43:14 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2535721F860B for ; Fri, 26 Oct 2012 10:43:13 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2065376lbo.31 for ; Fri, 26 Oct 2012 10:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TfcvsxkjsI8koMBwfBBop/GXePNYs/dxxig5NA/P2/E=; b=q37/bbAzI56AwBxjYR8EXVl7P8Al/MfseTfLzcoYoImhBjw9GQyLADiTYAsbT/X66V bWCFcfwdMToxMFwfq7K+QvPvSPSgJfNNvNmn850DGRD2xGyqhYR0kVNJ4gv6M6rnqMpf RZ15espNJx6HTFYK2OeuS/iScVBnIlNrAPL7nbLQZDXBX1rd9tA0uhDoVr5n1qJzTL0g kKkyrXIHDw4jq+TmaNQ4P7lur99unj3UcR2u0wFqX0Wa/6e0LdGI5Q8zftqv2hJIERy0 mGD4LZBKAXOfcNVYMCaCNVQoGL3Xg/hvZ4snpLgrKwarnvt/ec43SRwjRq0ITSTRTgF8 JF6Q== MIME-Version: 1.0 Received: by 10.152.105.236 with SMTP id gp12mr21297948lab.35.1351273393167; Fri, 26 Oct 2012 10:43:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.99.131 with HTTP; Fri, 26 Oct 2012 10:43:13 -0700 (PDT) In-Reply-To: <1610807.KLN8qAgPhL@scott-latitude-e6320> References: <1610807.KLN8qAgPhL@scott-latitude-e6320> Date: Fri, 26 Oct 2012 13:43:13 -0400 X-Google-Sender-Auth: eYzjUqcDiGY80wBozkEijOv2N3o Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0407144b981c5004ccf9da61 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New (minor) issue: Inconsistency on ip4: address format X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Oct 2012 17:43:15 -0000 --f46d0407144b981c5004ccf9da61 Content-Type: text/plain; charset=ISO-8859-1 I would prefer to add to the sentence in paragraph 5, making it something like, "...compared for equality. The entire IP address is nevertheless specified, with the non-compared bits set to zero." Barry, participant On Friday, October 26, 2012, Scott Kitterman wrote: > The ABNF for an IPv4 address is: > > ip4-network = qnum "." qnum "." qnum "." qnum > > (paragraph 5.6 and the collected ABNF). > > At the beginning of paragraph 5 there is a general statement about how > ip4/6 > mechanisms with CIDR lengths are processed: > > If a CIDR prefix length is specified, then only the specified number > of high-order bits of and the IP address are compared for > equality. > > Both of these items are unchanged between RFC 4408 and the current WG > draft. > > I just got an email complaining that my SPF record validator was wrong > because > it calls ip4:198.51.100/24 a syntax error (which it is per the ABNF) > because > the correspondent claimed that since the low-order bits weren't compared > for > equality, they didn't need to be provided. > > I can see the source of their confusion. > > Is the sentence about only comparing the specified number of high order > bits > really needed or is that just a note about implementation? If we could > just > drop it, it would remove this source of confusion. As long as it wouldn't > lose something substantive in the processing definition, I think we should > do > that. > > Opinions? > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --f46d0407144b981c5004ccf9da61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would prefer to add to the sentence in paragraph 5, making it something l= ike, "...compared for equality. =A0The entire IP address is neverthele= ss specified, with the non-compared bits set to zero."

Barry, participant

On Friday, October 26, 2012, Sc= ott Kitterman wrote:
The ABNF for an IPv= 4 address is:

ip4-network =A0 =A0 =A0=3D qnum "." qnum "." qnum "= ;." qnum

(paragraph 5.6 and the collected ABNF).

At the beginning of paragraph 5 there is a general statement about how ip4/= 6
mechanisms with CIDR lengths are processed:

=A0 =A0If a CIDR prefix length is specified, then only the specified number=
=A0 =A0of high-order bits of <ip> and the IP address are compared for=
=A0 =A0equality.

Both of these items are unchanged between RFC 4408 and the current WG draft= .

I just got an email complaining that my SPF record validator was wrong beca= use
it calls ip4:198.51.100/24 a syntax error (which it is per the ABNF) becaus= e
the correspondent claimed that since the low-order bits weren't compare= d for
equality, they didn't need to be provided.

I can see the source of their confusion.

Is the sentence about only comparing the specified number of high order bit= s
really needed or is that just a note about implementation? =A0If we could j= ust
drop it, it would remove this source of confusion. =A0As long as it wouldn&= #39;t
lose something substantive in the processing definition, I think we should = do
that.

Opinions?

Scott K
_______________________________________________
spfbis mailing list
spfbis@ietf.org
= https://www.ietf.org/mailman/listinfo/spfbis
--f46d0407144b981c5004ccf9da61-- From spf2@kitterman.com Fri Oct 26 15:16:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57CC21F866D for ; Fri, 26 Oct 2012 15:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DevJ06GNSeN for ; Fri, 26 Oct 2012 15:16:08 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA0F21F865C for ; Fri, 26 Oct 2012 15:16:07 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1C63220E4104; Fri, 26 Oct 2012 18:16:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1351289767; bh=1CcEtQGOD0uGA9WQypm4NisFGZ6aSdSwixSRGQCSt1E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aHt4MdeUgcdvCw57wjcp97EvvUJq2kMmGzJUZTNjIRkdo8JdjsEnMYErTZx0sFuPi cDlpoo4FWpZehN5fw4CdZ7bUQqvc9XV9XMFjWBRMDZsBTTuDWXS++UflrStAyLjQC3 Z8xl23Ls+yOymPTcHoN4YHCilH+gdPuczWQp6zOA= Received: from scott-latitude-e6320.localnet (30.sub-70-192-217.myvzw.com [70.192.217.30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DBF9920E406B; Fri, 26 Oct 2012 18:16:06 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 26 Oct 2012 18:16:05 -0400 Message-ID: <2985381.Qe1a4cgsfy@scott-latitude-e6320> User-Agent: KMail/4.9.2 (Linux/3.5.0-17-generic; KDE/4.9.2; i686; ; ) In-Reply-To: References: <1610807.KLN8qAgPhL@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] New (minor) issue: Inconsistency on ip4: address format X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Oct 2012 22:16:11 -0000 On Friday, October 26, 2012 01:43:13 PM Barry Leiba wrote: > On Friday, October 26, 2012, Scott Kitterman wrote: > > The ABNF for an IPv4 address is: > > > > ip4-network = qnum "." qnum "." qnum "." qnum > > > > (paragraph 5.6 and the collected ABNF). > > > > At the beginning of paragraph 5 there is a general statement about how > > ip4/6 > > > > mechanisms with CIDR lengths are processed: > > If a CIDR prefix length is specified, then only the specified number > > of high-order bits of and the IP address are compared for > > equality. > > > > Both of these items are unchanged between RFC 4408 and the current WG > > draft. > > > > I just got an email complaining that my SPF record validator was wrong > > because > > it calls ip4:198.51.100/24 a syntax error (which it is per the ABNF) > > because > > the correspondent claimed that since the low-order bits weren't compared > > for > > equality, they didn't need to be provided. > > > > I can see the source of their confusion. > > > > Is the sentence about only comparing the specified number of high order > > bits > > really needed or is that just a note about implementation? If we could > > just > > drop it, it would remove this source of confusion. As long as it wouldn't > > lose something substantive in the processing definition, I think we should > > do > > that. > > > > Opinions? > I would prefer to add to the sentence in paragraph 5, making it something > like, "...compared for equality. The entire IP address is nevertheless > specified, with the non-compared bits set to zero." > > Barry, participant Thanks Barry. I like that. For IPv6, there is a different type of definition in the ABNF: ip6-network = ; e.g., 2001:DB8::CD30 As I read that, the "entire IP address" requirement only applies to IPv4. Is that right? Scott K From barryleiba.mailing.lists@gmail.com Fri Oct 26 18:54:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1957021F860A for ; Fri, 26 Oct 2012 18:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.139 X-Spam-Level: X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXexLNU2H5ym for ; Fri, 26 Oct 2012 18:54:02 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5337C21F8607 for ; Fri, 26 Oct 2012 18:54:02 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2259715lbo.31 for ; Fri, 26 Oct 2012 18:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ruCPsspppfeluYcx+viAOXNUFsGuGJ95C5fyh0e3Pok=; b=TDJM7BawuozsuJ8b3r3nCoayWEDJwZpsPUOxHo+uHbFEADsNK8DblykqujIOvPZHTw X41N+7okvwpBS4VTkYe9+jErv6oVGIW4WnF4ycb/bnVX2hDNDRaGFzA4UjNUG6en+pBu V/UyEK9B/F50X/3mqNiJByX0Wfde4ZjYjFOfm00O3WSiijNDXKjx+RlF1y3p2rA5FIWp 5NyPcXToUE1xbt6hqTJ5A7s1BdIWtjbZSxUAhbljSIu+mFb1GPxebPIpWSdgREBKWdQx +xVI0f8dfA2hdXJ2+jAJjFzlng/C38yaIacvDqlZM5Yl6XMu2PBmZt1TtUJsiGCzVoaW c+qw== MIME-Version: 1.0 Received: by 10.112.85.198 with SMTP id j6mr7983284lbz.132.1351302841324; Fri, 26 Oct 2012 18:54:01 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.99.131 with HTTP; Fri, 26 Oct 2012 18:54:01 -0700 (PDT) In-Reply-To: <2985381.Qe1a4cgsfy@scott-latitude-e6320> References: <1610807.KLN8qAgPhL@scott-latitude-e6320> <2985381.Qe1a4cgsfy@scott-latitude-e6320> Date: Fri, 26 Oct 2012 21:54:01 -0400 X-Google-Sender-Auth: r-WTGsfrOIn-YnqHDA5UpZ3zpes Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0401683fd754d704cd00b5b7 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] New (minor) issue: Inconsistency on ip4: address format X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Oct 2012 01:54:03 -0000 --f46d0401683fd754d704cd00b5b7 Content-Type: text/plain; charset=ISO-8859-1 > > For IPv6, there is a different type of definition in the ABNF: > > ip6-network = > ; e.g., 2001:DB8::CD30 > > As I read that, the "entire IP address" requirement only applies to IPv4. > Is > that right? > Yes, that's right. b --f46d0401683fd754d704cd00b5b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For IPv6, there is a different type of defin= ition in the ABNF:

=A0 =A0ip6-network =A0 =A0 =A0=3D <as per [RFC 4291], section 2.2> =A0 =A0 =A0 =A0 =A0 =A0 ; e.g., 2001:DB8::CD30

As I read that, the "entire IP address" requirement only applies = to IPv4. =A0Is
that right?

Yes, that's right.

b=A0
--f46d0401683fd754d704cd00b5b7-- From johnl@iecc.com Fri Oct 26 20:00:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D7C21F86A6 for ; Fri, 26 Oct 2012 20:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.783 X-Spam-Level: X-Spam-Status: No, score=-111.783 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Euot89dOktHp for ; Fri, 26 Oct 2012 20:00: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 C0A3E21F84C9 for ; Fri, 26 Oct 2012 20:00:54 -0700 (PDT) Received: (qmail 91656 invoked from network); 27 Oct 2012 03:00:52 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 27 Oct 2012 03:00: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:vbr-info; s=508b4e64.xn--btvx9d.k1210; i=johnl@user.iecc.com; bh=CLFMF48dhOr410JQqwYaO1CbjQjEJTWMPWHkehPAZFI=; b=tEeszxnAUdEQt9jFdxcARbOhSuABTuFEI60cejKhBfkh4+HtNAO8um2wNsjHSB1Xb/9cgbVEcr/OpwLoUFDCoZohIOtCVGHRXqivUwdnG0zuGYCmweVxWIFkXJbXjwuYLlRarMe5/Sd8pxW4TNkQF15fkFkmYNn4l9Y2bN3e1cw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=508b4e64.xn--btvx9d.k1210; olt=johnl@user.iecc.com; bh=CLFMF48dhOr410JQqwYaO1CbjQjEJTWMPWHkehPAZFI=; b=c5Pc0MAPN+gAucrxjfeSppNVBExzYHE0UpVfBK0Zwavb2iEi/7xJnZ07Len694zMrwe2SjXm+u8+LqlAVeOrK6eRxYLpIf0QKLoEZEorwOLMTCTavviCT/Hyxw85CmDlVdMrplngqO/E7AuEgBNQKCdkPqF75/hE/H3pZ7lYMB4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 27 Oct 2012 03:00:30 -0000 Message-ID: <20121027030030.3352.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <2985381.Qe1a4cgsfy@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] New (minor) issue: Inconsistency on ip4: address format X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Oct 2012 03:00:55 -0000 > ip6-network = > ; e.g., 2001:DB8::CD30 > >As I read that, the "entire IP address" requirement only applies to IPv4. Is >that right? The usual syntax for writing IPv6 addresses uses :: to abbreviate a string of zeros. So the SPF record for my outgoing mail includes this: ip6:2001:470:1f07:1126::/64 That is an entire IPv6 address, even though the low 64 bits are only implicitly specified. So the literal answer to your question is no, since you have to provide an entire IPv6 address, but that address is usually written in a way that elides the boring low bits. R's, John From agthisell@yahoo.com Fri Oct 26 20:11:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E5921F86AF for ; Fri, 26 Oct 2012 20:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLtSu71+IGSv for ; Fri, 26 Oct 2012 20:11:14 -0700 (PDT) Received: from nm27.bullet.mail.ne1.yahoo.com (nm27.bullet.mail.ne1.yahoo.com [98.138.90.90]) by ietfa.amsl.com (Postfix) with ESMTP id 4A98321F84CE for ; Fri, 26 Oct 2012 20:11:14 -0700 (PDT) Received: from [98.138.90.56] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 27 Oct 2012 03:11:03 -0000 Received: from [98.138.89.164] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 27 Oct 2012 03:11:03 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 27 Oct 2012 03:11:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 264034.76146.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 98588 invoked by uid 60001); 27 Oct 2012 03:11:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1351307463; bh=Gvg7s7FxJVYQfFS51rKnTCbHUGock8Yd2yVux3aTsHY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=aW4EAoWowzqze8qDQxNmbe5NmHI73LtSZ7vadfSbfKjB6UzEV3XMhbq23sdP1aq10MIpvNzfmYSzViZUmbQy/b+/RNOPlzmYrJfqnGPPQ1lslZZ5DYsg9CaoCQUc3ioDnxa+i7h5yz6X/77oNSAL39tbKoPzMw2kdw7e6Uq3LI0= 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:MIME-Version:Content-Type; b=K3EbFQXra1rnYMkYyC174FbC9y/TUw4ltqx7meOI1tJZEXsA2UYPC37gjG4PBTjAiY/ZhFeRLOiChof4RGYcHfJg92R7FNJY0shUZwYMetyq6KOh6hiFcOwDoitiXXqgcuE+OTDxrKdGiCvyA9U9/U86AWv0DG/ahRnFEDWdDDo=; X-YMail-OSG: cnw76F0VM1mrD9JClN9EGHd4t5dufR_NHo2j8GWdTlw2k99 qxea3a8GxyCoxFgY15tHM153Z1E0iftnTgk4q6eONQSTz1O9OAN87Zivzx57 HWIj5PzyiPLQzoCBN8KsgINkMQEJRGMU6NadZImYhfjHbNFGKhpLmMs91NZC QQSC1_2Aq1.oAJoLKjnWap1GShYs7ClLfzVGDepJ1hBRkar7ph3Yr5B6LCou Y__D6RTvzTgok2wzb.EVU.hoY6XWF7zvdSxf4YRiT8EyShCoY0MhKX4YLjpJ avJV8Rr7J12c6qEd8iIDJAPPzhqp.3VnNEsdQX.2uYSKJCMeF3h_o2G4aAhB Kbp5nKGx7BuFEUisLu.kvBewh4FFGANgWZgtaxYuRoOBNjZJi5YHsGHlPGlc ogA1osD2slaPgb4.Q.KlykZTO5R78Li6w3cO6e8rJ01cPHcp.rFOQ.AOjOnL YwS5KQfP9TF0QaB4ZKGPvfPTMmVP6wB04rkQRFBeaham8PlCzzwRkqTpjf9D 7ASMZ3ZZUcsZq6YZHMzF6D0evv0Wh.TMvZeC.Rwie Received: from [71.61.133.134] by web125102.mail.ne1.yahoo.com via HTTP; Fri, 26 Oct 2012 20:11:02 PDT X-Rocket-MIMEInfo: 001.001, PiBJIHdvdWxkIHByZWZlciB0byBhZGQgdG8gdGhlIHNlbnRlbmNlIGluIHBhcmFncmFwaCA1LCBtYWtpbmcgaXQgc29tZXRoaW5nCj4gbGlrZSwgIi4uLmNvbXBhcmVkIGZvciBlcXVhbGl0eS4gIFRoZSBlbnRpcmUgSVAgYWRkcmVzcyBpcyBuZXZlcnRoZWxlc3MgCj4gc3BlY2lmaWVkLCB3aXRoIHRoZSBub24tY29tcGFyZWQgYml0cyBzZXQgdG8gemVyby4iCgpSRkMgNDQwOCBhbHJlYWR5IHNheXM6CiAgIElmIGlwNC1jaWRyLWxlbmd0aCBpcyBvbWl0dGVkLCBpdCBpcyB0YWtlbiB0byBiZSAiLzMyIi4gIEkBMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.450 Message-ID: <1351307462.80628.YahooMailClassic@web125102.mail.ne1.yahoo.com> Date: Fri, 26 Oct 2012 20:11:02 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] New (minor) issue: Inconsistency on ip4: address format X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Oct 2012 03:11:15 -0000 > I would prefer to add to the sentence in paragraph 5, making it something > like, "...compared for equality. The entire IP address is nevertheless > specified, with the non-compared bits set to zero." RFC 4408 already says: If ip4-cidr-length is omitted, it is taken to be "/32". If ip6-cidr-length is omitted, it is taken to be "/128". It is not permitted to omit parts of the IP address instead of using CIDR notations. That is, use 192.0.2.0/24 instead of 192.0.2. From superuser@gmail.com Sun Oct 28 00:33:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3A421F8445 for ; Sun, 28 Oct 2012 00:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuZJRfV5TD8l for ; Sun, 28 Oct 2012 00:33:48 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2624221F8771 for ; Sun, 28 Oct 2012 00:33:45 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so4222782obq.31 for ; Sun, 28 Oct 2012 00:33:44 -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=zyN5RXNg/IPeyFmUOHeWtlYkcv9/YsW+/OJsIUpZ59s=; b=k3Rg2Fv5buAcGOVVGFQYrhY0oUXyt+NDBqBxO+lXHrGSgxASvjGbxxXTJu7goFF0v9 n/eBS4M6X3ctE3XdSAhGhERxL1idYJ84zxfJxckfNlrPaWEdF5qe1DviADvOeMbEUSDy rSdmd6EvyevRQRpsd0BGEjttbfaPYoc9WGpqeYS175EOSW99Hzrdi6p+ha9TF6TZBmH4 Mwg+OBn9oVRdDOmWndM67SXnt02CpCyAa1KjzObdl2fmkPF1Dl52hJL4pUNL2qR3Pfse KHahSZDe349f4noCq3mvmTqA7KEIOS03GUWDGuxVXHo8KmamECzZkB33Smcr7qFlODqD 4yNQ== MIME-Version: 1.0 Received: by 10.182.157.82 with SMTP id wk18mr20391733obb.26.1351409624673; Sun, 28 Oct 2012 00:33:44 -0700 (PDT) Received: by 10.182.46.137 with HTTP; Sun, 28 Oct 2012 00:33:44 -0700 (PDT) In-Reply-To: References: <1610807.KLN8qAgPhL@scott-latitude-e6320> Date: Sun, 28 Oct 2012 00:33:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] New (minor) issue: Inconsistency on ip4: address format X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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 Oct 2012 07:33:48 -0000 On Fri, Oct 26, 2012 at 10:43 AM, Barry Leiba wrote: > I would prefer to add to the sentence in paragraph 5, making it something > like, "...compared for equality. The entire IP address is nevertheless > specified, with the non-compared bits set to zero." > > Barry, participant I don't know if it affects this question or not, or how we word the specification, but conventional implementations of inet_addr() would interpret the string "198.51.100" by saying the first octet is 198, the second is 51, and the third and fourth combined are 100. I think this goes back to pre-CIDR implementations. Yuck, I know. But it's a fairly ubiquitous function by now. -MSK From sm@elandsys.com Tue Oct 30 12:30:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2332421F861C for ; Tue, 30 Oct 2012 12:30: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5CHwbcNs2XC for ; Tue, 30 Oct 2012 12:30:30 -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 8C79521F861B for ; Tue, 30 Oct 2012 12:30:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9UJUDgx023099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Oct 2012 12:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351625425; bh=cdHR/fg+e+747kCu2dzFQiXWhFiu0Kin5upw6IyB9YA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=Xld5eYwEtwTcER+mGtvQZCqRPlJAmreh6af+m5V5ySMCkXJNt5hEpsuZkzryE0yj/ zLy55v6LzjUSWIXqOFIPwGLdQNqvjMtBSgcz7bVgCNsBh5jGywiG3SrnqCj85Oxvz3 JsCUjE0VxQWthiPOtXSa8brl1LhCLlA778QghpR4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1351625425; i=@elandsys.com; bh=cdHR/fg+e+747kCu2dzFQiXWhFiu0Kin5upw6IyB9YA=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=00lkKqzIkT2uMTO9rJ1ZLvlPcJROVR4rMZ42rB6mAA3O3Z64H3CNGuA4jPK4scARf gnqtuJA+Qh4V/DNEScy3OSVIWKrAxmnplrMs7u9KBPgnPncCTeJWfrL7b2rrCls2J7 SB4tLcdOLRdIucTXdcKj940qupTR+usCkMpMIL8g= Message-Id: <6.2.5.6.2.20121030115138.0957f450@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 30 Oct 2012 12:29:31 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 19:30:31 -0000 At 13:37 17-09-2012, Murray S. Kucherawy wrote: >On reviewing the -07 draft I observed that the flow could be improved, >and that's thus one of the things I tried to do in the proposal. Could the WG let me know whether the following is an adequate summary of the discussion about the proposal? Please note that this message is not about debating about the views that were expressed. There should be ample time during the face-to-face (Jabber for remote participants) meeting for that discussion. Murray Kucherawy mentioned that the specification has however become somewhat bloated with documentation of nuance and other text that has nothing to do with interoperability, security, or other topics critical to defining a protocol and enabling interoperability. Much of that bloat may well have been there in RFC4408 itself, and the working group has focused on developing it rather than cleaning it up. [1] John Leslie mentioned that "we're going 'round in circles largely because we have differing opinions on what is protocol and what is operational advice." [2] William Leibzon noted that that such re-organization is likely to go against original intent of SPF. The intent was to have it published as a standard document and if part of it is split into "informational" type document that is very different especially given that SPF was published as experimental standard already [3]. Dave Crocker posted the following questions [4]: 1. Is it generally 'legal' to reorganize a specification document during an effort like spfbis and specifically legal for spfbis? 2. Does the existing organization have some issues? 3. Does the proposed reorganization increase clarity or otherwise improve the document? Scott Kitterman mentioned that the current document (4408) is the basis for multiple, interoperable implementations [5]. William Leibzon mentioned that the material has been used and understood by countless developers [6]. Alessandro Vesely commented that Version -07 was still organized according to RFC 4408, with such idiosyncrasies as putting macros after Received-SPF rather than along with mechanisms and modifiers where they pertain and separating filter handling from the result computation is a needed cleanup that this reorganization opens nicely [7]. Arthur Thisell commented that deciding the order of the macro and received-spf headers is not important [8]. Andrew Sullivan tried to clarify the goals of the discussion about the proposed reorganization [9]. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02872.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02874.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02878.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02881.html 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02883.html 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02884.html 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02893.html 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02895.html 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02912.html From prvs=64315d15c=fmartin@linkedin.com Tue Oct 30 12:40:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD8821F862A for ; Tue, 30 Oct 2012 12:40:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hliKWptnz5MM for ; Tue, 30 Oct 2012 12:40:12 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 775E521F8621 for ; Tue, 30 Oct 2012 12:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1351626012; x=1383162012; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=wp4VRssTnv0a5lZ2k1OQp8DDYT76hJ5qNafpZZWigM8=; b=wsBWxDWO5paw6etGxsMHKgnxYYgHvYIOmr1etOlcDif0nknstSwMrPlr GdGtGTYxi+GI1AQ3cehFgIbf8QDiCz0ViHXEo6MtDRmyVqrKuNj6X8jKw 5jIkcfd+OCHYBat7GHqRFCKtrmrD9IME2XHmWtDxKYwnyV+sqwhCetPnb 8=; X-IronPort-AV: E=Sophos;i="4.80,682,1344236400"; d="scan'208";a="29232957" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 30 Oct 2012 12:39:31 -0700 Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.01.0218.012; Tue, 30 Oct 2012 12:39:31 -0700 From: Franck Martin To: S Moonesamy , "spfbis@ietf.org" Thread-Topic: [spfbis] A proposed reorganization Thread-Index: AQHNttUNkJyMnhoa00q/Lecf2zC85pfSPvAA Date: Tue, 30 Oct 2012 19:39:31 +0000 Message-ID: In-Reply-To: <6.2.5.6.2.20121030115138.0957f450@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="us-ascii" Content-ID: <515B82F5D04E03418366EC27FA98187F@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 19:40:13 -0000 The question is may be a more fundamental one, considering the original document was intended to be experimental, the editorial proofing may have been very relaxed. Now that the document is on the standard track, it may need to be in par in format to other standards developed today So is the document formatted like a standard? Does it need a rewrite to adopt current editorial practices, and that without changing the protocol? On 10/30/12 12:29 PM, "S Moonesamy" wrote: >At 13:37 17-09-2012, Murray S. Kucherawy wrote: >>On reviewing the -07 draft I observed that the flow could be improved, >>and that's thus one of the things I tried to do in the proposal. > >Could the WG let me know whether the following is an adequate summary >of the discussion about the proposal? Please note that this message >is not about debating about the views that were expressed. There >should be ample time during the face-to-face (Jabber for remote >participants) meeting for that discussion. > >Murray Kucherawy mentioned that the specification has however become >somewhat bloated with documentation of nuance and other text that has >nothing to do with interoperability, security, or other topics >critical to defining a protocol and enabling interoperability. Much >of that bloat may well have been there in RFC4408 itself, and the >working group has focused on developing it rather than cleaning it up. [1] > >John Leslie mentioned that "we're going 'round in circles largely >because we have differing opinions on what is protocol and what is >operational advice." [2] William Leibzon noted that that such >re-organization is likely to go against original intent of SPF. The >intent was to have it published as a standard document and if part of >it is split into "informational" type document that is very different >especially given that SPF was published as experimental standard >already [3]. Dave Crocker posted the following questions [4]: > > 1. Is it generally 'legal' to reorganize a specification document >during an effort > like spfbis and specifically legal for spfbis? > > 2. Does the existing organization have some issues? > > 3. Does the proposed reorganization increase clarity or otherwise >improve the > document? > >Scott Kitterman mentioned that the current document (4408) is the >basis for multiple, interoperable implementations [5]. William >Leibzon mentioned that the material has been used and understood by >countless developers [6]. Alessandro Vesely commented that Version >-07 was still organized according to RFC 4408, with such >idiosyncrasies as putting macros after Received-SPF rather than along >with mechanisms and modifiers where they pertain and separating >filter handling from the result computation is a needed cleanup that >this reorganization opens nicely [7]. Arthur Thisell commented that >deciding the order of the macro and received-spf headers is not important >[8]. > >Andrew Sullivan tried to clarify the goals of the discussion about >the proposed reorganization [9]. > >Regards, >S. Moonesamy > >1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02872.html >2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02874.html >3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02878.html >4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02881.html >5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02883.html >6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02884.html >7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02893.html >8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02895.html >9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02912.html > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From dotzero@gmail.com Tue Oct 30 12:42:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7582621F863F for ; Tue, 30 Oct 2012 12:42:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhkUEPvVhZhI for ; Tue, 30 Oct 2012 12:42:04 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7CCD21F862A for ; Tue, 30 Oct 2012 12:42:04 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so1127925iec.31 for ; Tue, 30 Oct 2012 12:42:04 -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=JL8rBTQIIt3SOOlp6RZUHpbM8mbslOcrGUUdG6ihefA=; b=AiQOOYCYr8BkPnsRuqQXI8cxd008WQg+q2/6zkHsNvykqUgZ2Qu3kPh7nRJroVQ2hN qs19UUzfs4v1xaYdA44tYsjjlZZNK3qMTIqUA43ZVZOOORaA10OH9DODNetzcuIgEg2x lKrqUgsL1hMbd8ZsHJBDdk8dA/1tszRjUNQ0c8gIs0ALz0LhoPVYnEtr4aqZKIPQVOOu qjPlNy11rPzIJIaKTboYJfpS9laGmNqdHks7ty0dZ/bxmTy/nZ7U53UFdPqvgI4/DCyp MwI60xb6fl7HoLN1n5+otM/55do+MSASQMokX3RvyWQY143QAHf/Kesx8q0OCXpgv8Sb vEWQ== MIME-Version: 1.0 Received: by 10.50.178.106 with SMTP id cx10mr2613366igc.24.1351626124369; Tue, 30 Oct 2012 12:42:04 -0700 (PDT) Received: by 10.64.110.138 with HTTP; Tue, 30 Oct 2012 12:42:04 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20121030115138.0957f450@resistor.net> References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> Date: Tue, 30 Oct 2012 15:42:04 -0400 Message-ID: From: Dotzero To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 19:42:05 -0000 I think this is an adequate summary of the discussion but would point out that the requirements for a successful standards track document are more stringent than publishing an experimental document. Mike On Tue, Oct 30, 2012 at 3:29 PM, S Moonesamy wrote: > At 13:37 17-09-2012, Murray S. Kucherawy wrote: >> >> On reviewing the -07 draft I observed that the flow could be improved, >> and that's thus one of the things I tried to do in the proposal. > > > Could the WG let me know whether the following is an adequate summary of the > discussion about the proposal? Please note that this message is not about > debating about the views that were expressed. There should be ample time > during the face-to-face (Jabber for remote participants) meeting for that > discussion. > > Murray Kucherawy mentioned that the specification has however become > somewhat bloated with documentation of nuance and other text that has > nothing to do with interoperability, security, or other topics critical to > defining a protocol and enabling interoperability. Much of that bloat may > well have been there in RFC4408 itself, and the working group has focused on > developing it rather than cleaning it up. [1] > > John Leslie mentioned that "we're going 'round in circles largely because we > have differing opinions on what is protocol and what is operational advice." > [2] William Leibzon noted that that such re-organization is likely to go > against original intent of SPF. The intent was to have it published as a > standard document and if part of it is split into "informational" type > document that is very different especially given that SPF was published as > experimental standard already [3]. Dave Crocker posted the following > questions [4]: > > > 1. Is it generally 'legal' to reorganize a specification document during an > effort > like spfbis and specifically legal for spfbis? > > 2. Does the existing organization have some issues? > > 3. Does the proposed reorganization increase clarity or otherwise improve > the > document? > > Scott Kitterman mentioned that the current document (4408) is the basis for > multiple, interoperable implementations [5]. William Leibzon mentioned that > the material has been used and understood by countless developers [6]. > Alessandro Vesely commented that Version -07 was still organized according > to RFC 4408, with such idiosyncrasies as putting macros after Received-SPF > rather than along with mechanisms and modifiers where they pertain and > separating filter handling from the result computation is a needed cleanup > that this reorganization opens nicely [7]. Arthur Thisell commented that > deciding the order of the macro and received-spf headers is not important > [8]. > > Andrew Sullivan tried to clarify the goals of the discussion about the > proposed reorganization [9]. > > Regards, > S. Moonesamy > > 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02872.html > 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02874.html > 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02878.html > 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02881.html > 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02883.html > 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02884.html > 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02893.html > 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02895.html > 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02912.html > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From vesely@tana.it Wed Oct 31 04:43:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5AE21F85A9 for ; Wed, 31 Oct 2012 04:43: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKu800hy45DS for ; Wed, 31 Oct 2012 04:43:35 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 39A7721F86F9 for ; Wed, 31 Oct 2012 04:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1351683792; bh=yMTZpe6xsbFZGd9W1/TeFse9TUdo+BzJprdrSi5HKp4=; l=1844; h=Date:From:To:References:In-Reply-To; b=I6y/ZreMaaapwt8r0Ve5ehS6OHXBxOJ6sjMJKYvXlG3zRl98+PJdbWtl9aJ2RarQT klwVy5KQSEYBnIi0eMHdkZfsxbkwBh6b5knHLgsZHJWfK3wLPi8+74xTC7tAEDqa2X HCNxdlr8LmK130/MY5pgOU1YV33lAg3pTn6laEAw= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 31 Oct 2012 12:43:12 +0100 id 00000000005DC033.0000000050910ED0.00003844 Message-ID: <50910ECF.4010607@tana.it> Date: Wed, 31 Oct 2012 12:43:11 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: spfbis@ietf.org References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> In-Reply-To: <6.2.5.6.2.20121030115138.0957f450@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 11:43:36 -0000 On Tue 30/Oct/2012 20:29:31 +0100 S Moonesamy wrote: > At 13:37 17-09-2012, Murray S. Kucherawy wrote: >> On reviewing the -07 draft I observed that the flow could be improved, >> and that's thus one of the things I tried to do in the proposal. > > Could the WG let me know whether the following is an adequate summary > of the discussion about the proposal? Please note that this message > is not about debating about the views that were expressed. There > should be ample time during the face-to-face (Jabber for remote > participants) meeting for that discussion. Hm.. not sure what you mean by adequate. The summary is rather euphemistic :-) > [...] Dave Crocker posted the following questions [4]: > > 1. Is it generally 'legal' to reorganize a specification document > during an effort like spfbis and specifically legal for spfbis? > > 2. Does the existing organization have some issues? > > 3. Does the proposed reorganization increase clarity or otherwise > improve the document? Those are good questions, but IMHO we should first clarify what exactly do we want to standardize. Specifically, whether we want to cover receiver behavior or not: If we standardize just the *SPF function* then we should severely cut the bloat. For example, considerations about whether the function is computed on a mail server rather than some other kind of host --which used to constitute experimental guidance-- becomes 98% fluffy in a standard document. Not to mention SMTP reply codes. If we want to standardize *SPF implementation*, since most concerned software runs at SMTP servers, we have to specify it much better than what is currently drafted, using MUSTard like e.g. RFC 6647 does. That may imply splitting the document. > 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02881.html From hsantos@isdg.net Wed Oct 31 09:26:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E6B21F8592 for ; Wed, 31 Oct 2012 09:26:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spoX4FHNK+6X for ; Wed, 31 Oct 2012 09:26:43 -0700 (PDT) Received: from pop3.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CDFB721F858E for ; Wed, 31 Oct 2012 09:26:42 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4895; t=1351700794; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=2TqLxVsuMPEwiK5KeEG1wNpKmZo=; b=GIh+xFp/VotJxcmzKqAn 6KKrgO8mmYBx6GuM+WDROe0mCpIkWXzfebOBngEE+CZgGyh20/TUVUMzoSmlPcpC G/Gr7USWUPTVvtr89GwiPTP0yllQW+FYio2ucmZNtukx7Xx3bRdDTR9kzEcWJadC LFwjxvsjb47Z2/WKWFsjdqk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 31 Oct 2012 11:26:34 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3427555448.1540.5272; Wed, 31 Oct 2012 11:26:33 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4895; t=1351700481; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=YS4UuHE vsEVp2KK7bkZH0TvuNC0HchlG5Ga5GsN4m/Q=; b=NiOtNUieBnsDO1FnX9vGL1y lCCxDWB9hrvI0B6Fu5KKUTJu7X7wQ1kGgsoVXRFZizxoVjMorbK7PRmzHMruBL4s 47Qefhmrc3FMsDyW9PZ2DZHRM9dAyNfhJ0Wx3pFLLO+Hb33unyE3utTck53v/WLV bAU+Dg2OtI/Hj/byXLLc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 31 Oct 2012 12:21:21 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4026312631.7.3400; Wed, 31 Oct 2012 12:21:21 -0400 Message-ID: <50915157.1090301@isdg.net> Date: Wed, 31 Oct 2012 12:27:03 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> In-Reply-To: <6.2.5.6.2.20121030115138.0957f450@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 31 Oct 2012 09:48:04 -0700 Cc: S Moonesamy Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:26:43 -0000 IMV, this is confusing and I don't believe it captures all the concerns here 100%. There is some that appear to be misread and other statements not even included. Nonetheless, there are some key issues IMO need to be resolved before any decision on reorganization, fine tuning or "reduction" of RFC4408 can be properly done. If we can't agree with some of the key and central issues, I doubt a reorganization will resolve the disagreement with satisfaction. However, a higher concern is it could do exactly the same thing that hurt the DKIM protocol and its potential payoff value: - Relaxation of the strong security value of the SPF protocol, - Remodeled around an abstract REPUTATION framework IMV, This has been among the central debate with SPF here which IMV, lead the WG to an impasse. Some don't like the current specification description and any implied strong operation of a -ALL (Failed) and wish it to be watered down in the name of using integrated heuristics methods, especially methods offered by Reputation services (borderlines conflict of interest concerns among others already exhibited in the WG). I think there is a lost of SPF "BIS" focus in this group because in large part, there has been concerted effort to alter the SPF specification so it can work with other protocols written by the same concerted group. That has a air of conflict of interest. -- HLS S Moonesamy wrote: > At 13:37 17-09-2012, Murray S. Kucherawy wrote: >> On reviewing the -07 draft I observed that the flow could be improved, >> and that's thus one of the things I tried to do in the proposal. > > Could the WG let me know whether the following is an adequate summary of > the discussion about the proposal? Please note that this message is not > about debating about the views that were expressed. There should be > ample time during the face-to-face (Jabber for remote participants) > meeting for that discussion. > > Murray Kucherawy mentioned that the specification has however become > somewhat bloated with documentation of nuance and other text that has > nothing to do with interoperability, security, or other topics critical > to defining a protocol and enabling interoperability. Much of that > bloat may well have been there in RFC4408 itself, and the working group > has focused on developing it rather than cleaning it up. [1] > > John Leslie mentioned that "we're going 'round in circles largely > because we have differing opinions on what is protocol and what is > operational advice." [2] William Leibzon noted that that such > re-organization is likely to go against original intent of SPF. The > intent was to have it published as a standard document and if part of it > is split into "informational" type document that is very different > especially given that SPF was published as experimental standard already > [3]. Dave Crocker posted the following questions [4]: > > 1. Is it generally 'legal' to reorganize a specification document > during an effort > like spfbis and specifically legal for spfbis? > > 2. Does the existing organization have some issues? > > 3. Does the proposed reorganization increase clarity or otherwise > improve the > document? > > Scott Kitterman mentioned that the current document (4408) is the basis > for multiple, interoperable implementations [5]. William Leibzon > mentioned that the material has been used and understood by countless > developers [6]. Alessandro Vesely commented that Version -07 was still > organized according to RFC 4408, with such idiosyncrasies as putting > macros after Received-SPF rather than along with mechanisms and > modifiers where they pertain and separating filter handling from the > result computation is a needed cleanup that this reorganization opens > nicely [7]. Arthur Thisell commented that deciding the order of the > macro and received-spf headers is not important [8]. > > Andrew Sullivan tried to clarify the goals of the discussion about the > proposed reorganization [9]. > > Regards, > S. Moonesamy > > 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02872.html > 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02874.html > 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02878.html > 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02881.html > 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02883.html > 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02884.html > 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02893.html > 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02895.html > 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02912.html > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From hsantos@isdg.net Wed Oct 31 09:49:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7583421F8795 for ; Wed, 31 Oct 2012 09:49: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZ0-Sl9eOgmv for ; Wed, 31 Oct 2012 09:49:44 -0700 (PDT) Received: from pop3.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB2521F878D for ; Wed, 31 Oct 2012 09:49:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4895; t=1351702179; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=2TqLxVsuMPEwiK5KeEG1wNpKmZo=; b=Xh1IVYy61YPOl5/8Uwhg WzDz2Wg2Sdh97l14xJWm/6H5LhfMRn6cNHIjQPJ/Dp4GjAl7HfNBPWWXsTVGIUCK PwU5dOL16vtluFnaNxawg4vn8Dru8xlzsMLe7gfP8x+lbXOv4UQoQeel7EkBi/KA VGOb8Cms8KuVd5DwYWU6g/s= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 31 Oct 2012 11:49:39 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3428940924.1540.4548; Wed, 31 Oct 2012 11:49:38 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4895; t=1351701867; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=YS4UuHE vsEVp2KK7bkZH0TvuNC0HchlG5Ga5GsN4m/Q=; b=R+a7+uHEm5zE/vi5BXjfGiu Pdl0t1U08Vw/AwIOjjJFqBxKEPLuWwJY+tTXy6gUtDrORFRjLLYkckIN8FtSwgI/ NlTn2ntgU1/OCddrZpkPCPQD/c6Ahq3ajCXLVDNfK8lFzZhzNKvpSU8wamBHGZCa S3TbCp0767RA1H8rC3iI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 31 Oct 2012 12:44:27 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4027698474.7.5016; Wed, 31 Oct 2012 12:44:27 -0400 Message-ID: <509156C1.7090804@isdg.net> Date: Wed, 31 Oct 2012 12:50:09 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <6.2.5.6.2.20121030115138.0957f450@resistor.net> In-Reply-To: <6.2.5.6.2.20121030115138.0957f450@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: S Moonesamy Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:49:45 -0000 IMV, this is confusing and I don't believe it captures all the concerns here 100%. There is some that appear to be misread and other statements not even included. Nonetheless, there are some key issues IMO need to be resolved before any decision on reorganization, fine tuning or "reduction" of RFC4408 can be properly done. If we can't agree with some of the key and central issues, I doubt a reorganization will resolve the disagreement with satisfaction. However, a higher concern is it could do exactly the same thing that hurt the DKIM protocol and its potential payoff value: - Relaxation of the strong security value of the SPF protocol, - Remodeled around an abstract REPUTATION framework IMV, This has been among the central debate with SPF here which IMV, lead the WG to an impasse. Some don't like the current specification description and any implied strong operation of a -ALL (Failed) and wish it to be watered down in the name of using integrated heuristics methods, especially methods offered by Reputation services (borderlines conflict of interest concerns among others already exhibited in the WG). I think there is a lost of SPF "BIS" focus in this group because in large part, there has been concerted effort to alter the SPF specification so it can work with other protocols written by the same concerted group. That has a air of conflict of interest. -- HLS S Moonesamy wrote: > At 13:37 17-09-2012, Murray S. Kucherawy wrote: >> On reviewing the -07 draft I observed that the flow could be improved, >> and that's thus one of the things I tried to do in the proposal. > > Could the WG let me know whether the following is an adequate summary of > the discussion about the proposal? Please note that this message is not > about debating about the views that were expressed. There should be > ample time during the face-to-face (Jabber for remote participants) > meeting for that discussion. > > Murray Kucherawy mentioned that the specification has however become > somewhat bloated with documentation of nuance and other text that has > nothing to do with interoperability, security, or other topics critical > to defining a protocol and enabling interoperability. Much of that > bloat may well have been there in RFC4408 itself, and the working group > has focused on developing it rather than cleaning it up. [1] > > John Leslie mentioned that "we're going 'round in circles largely > because we have differing opinions on what is protocol and what is > operational advice." [2] William Leibzon noted that that such > re-organization is likely to go against original intent of SPF. The > intent was to have it published as a standard document and if part of it > is split into "informational" type document that is very different > especially given that SPF was published as experimental standard already > [3]. Dave Crocker posted the following questions [4]: > > 1. Is it generally 'legal' to reorganize a specification document > during an effort > like spfbis and specifically legal for spfbis? > > 2. Does the existing organization have some issues? > > 3. Does the proposed reorganization increase clarity or otherwise > improve the > document? > > Scott Kitterman mentioned that the current document (4408) is the basis > for multiple, interoperable implementations [5]. William Leibzon > mentioned that the material has been used and understood by countless > developers [6]. Alessandro Vesely commented that Version -07 was still > organized according to RFC 4408, with such idiosyncrasies as putting > macros after Received-SPF rather than along with mechanisms and > modifiers where they pertain and separating filter handling from the > result computation is a needed cleanup that this reorganization opens > nicely [7]. Arthur Thisell commented that deciding the order of the > macro and received-spf headers is not important [8]. > > Andrew Sullivan tried to clarify the goals of the discussion about the > proposed reorganization [9]. > > Regards, > S. Moonesamy > > 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02872.html > 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02874.html > 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg02878.html > 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02881.html > 5. http://www.ietf.org/mail-archive/web/spfbis/current/msg02883.html > 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg02884.html > 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg02893.html > 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02895.html > 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02912.html > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > >