From agthisell@yahoo.com Mon Jun 4 11:56:14 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 5120211E80B5 for ; Mon, 4 Jun 2012 11:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILBSu6nHl1Dp for ; Mon, 4 Jun 2012 11:56:13 -0700 (PDT) Received: from nm28.bullet.mail.ne1.yahoo.com (nm28.bullet.mail.ne1.yahoo.com [98.138.90.91]) by ietfa.amsl.com (Postfix) with SMTP id 6D91711E80B3 for ; Mon, 4 Jun 2012 11:56:13 -0700 (PDT) Received: from [98.138.90.57] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jun 2012 18:56:10 -0000 Received: from [98.138.89.248] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jun 2012 18:56:10 -0000 Received: from [127.0.0.1] by omp1040.mail.ne1.yahoo.com with NNFMP; 04 Jun 2012 18:56:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 404630.24006.bm@omp1040.mail.ne1.yahoo.com Received: (qmail 32126 invoked by uid 60001); 4 Jun 2012 18:56:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1338836169; bh=m6G5gGOU3So6kc+3oodaMXyAVA67dSsSyhMe4dIJPYo=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=WkO82ESzSA3QhHpSIMS5TpSIXit/KEspIdxba/kc0c/mjRi5rgH95PDaz/Q/OI2gDHuBdUAdfkiwbKCyvuQ1FJsKyt3d44uwITSh46gmVoebIGWncGdGebOLSyh5JF/Z5fXtIgr5aXBzLn67UpvvuuqsVmkJGpFL8o8mFE/mpU4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=41DL6JJLDHOW2I/fRVihnoYt5RtQbnF1UfsBgzGUh+5+ZqqBxUjc2H8yIof7eHiwxvjVc0Y4yKux9LFP3XMr0PFtSjmezw9EGLU0M7NM2BZg2s7xn9YATx5V/0AkqReYvXk9UAi7qbBAnzFOPVgormbMX/9iAyr4NfA4OSaAfhk=; X-YMail-OSG: zvIhJQIVM1kqigqPDuVO2JI7AesE8AIb6D.QaoAPYi9H0va DzF9EcED4kkc5bcF4P5kacFOhWEbN51HJP8t4JMeNaeZfkG72qIW_Zfqv.xD bl83SqYvUoNTaQafpDsCJyPPlkuqqmcEBPaRXrSltRHHWInhHm8gVPMU5T1Y xuqA_weN1.BcwjPMh7TamZu9roSfuPvalOnuX8i7.sJcdLI0UyzZefSpU5XP sgf6CMJRfNBjS2q8TCBiYfeQrZtn.iP8sFUD67ZneR_c2e72HqNLp32WxRkF okMwjS9JhhKoIuS_ZxpWpSwCZ.fVzetOEk_OLtIDhwLhZsaIl54JKUuYUILZ FwHRxKCf3afkv8gtBQ6rih4yUsj7sTf6IG7lUxMzJniqzHnGi7UJ96ScYmvs J9brlWwp4eF9hxzMgN.lcthKLsjOoz_D97KYOoA_bEhRfsM5w7o.gBmq1e88 zs78- Received: from [71.61.133.134] by web125404.mail.ne1.yahoo.com via HTTP; Mon, 04 Jun 2012 11:56:09 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1338836169.30418.YahooMailClassic@web125404.mail.ne1.yahoo.com> Date: Mon, 4 Jun 2012 11:56:09 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] Last Call: (Resolution of The SPF and Sender ID Experiments) to Informational RFC X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 18:56:14 -0000 mostly an fyi; I have reviewed the last call draft and find it quite acceptable for publication. I realize I've been quite lax in following this WG lately and I should posted comments earlier. In hind sight, I doubt any comments I would have made would have made any significant improvements to the draft, it turned out just fine without me. That said, here are a few comments... 1) It was never clear to me why the IESG declared these MARID drafts as being experimental. Besides the possible confusion between interpreting records as both SPF and Sender ID, I was under the impression that the IESG wasn't sure if these proposals would help or hurt email in general, whether they would damage the function of the DNS, and whether it was appropriate to let individual submissions (the WG concluded without any approved IDs) to be other than experimental or informational. I'm not sure that there is much point in speculating what the IESG thought, but this draft seems to concentrate on only the SPF v Sender ID conflicts. 2) I always thought that the type 99 transition plan was faulty, but I could not think of anything better. This draft glosses over some key points about why it ended up with the transition plan that it did. * First, no one could come up with an example of a successful transition where the original had significant deployment (like the TXT records did) and the new version had no significant advantages (the type 99 was exactly the same as TXT, other than theoretical elegance.) Even MX records still fall back to A records. * Jim and Harry from Microsoft expressed very strong objections to any requirement that type 99 records MUST be checked. Their explanation was that apparently some MS applications used an API to ask about DNS records, my impression was that this API worked transparently on things like netware and their active directory and such too. No port 53 communication was done via this API, indeed, port 53 was often explicitly blocked at the firewall so clients couldn't even get around using this API if the wanted to. This API supported a very limited set of DNS records, TXT being one of them, but had zero support for new/unknown record types. Not only did the then current version of that API have no way of querying type 99 records, the next version had been put into feature freeze, and the version after that had no plans on adding such support. In short, if the RFCs required checking type 99 records, MS could not produce implementations that could be standard compliant. They were willing to compromise on many things, but this wasn't one of them. On the other hand, people in the MARID WG objected to any requirement to check TXT records, arguing that doing so would hinder the transition to type 99 records since people could just publish TXT records and know that they would always work. So, the result was: * the RFC MUST NOT require checking type 99 records, or it would lose support of MS. * the RFC MUST allow the checking of type 99 records, otherwise no migration would be possible. * the RFC MUST NOT require checking of TXT records, or it would lose support of IETF players and hinder migration. * the RFC MUST allow the checking of TXT records, otherwise you would lose a large install base. I, and others, were quite aware at the time that the language put into the RFC would make it so compliant implementations might not be able to communicate with compliant publishers. No one came forward with better language. I felt that as long as TXT could be used, noting else was likely to matter. Hindsight is 20/20 and positions appear to have softened over the years. Things like DKIM managed to get by with much less handwringing and I suspect if SPF was done today, known-bogus language like this wouldn't have made it into the draft. From sm@elandsys.com Mon Jun 4 13:03:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4232621F8863; Mon, 4 Jun 2012 13:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSOb5R+Ft89f; Mon, 4 Jun 2012 13:03:15 -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 2D60321F885D; Mon, 4 Jun 2012 13:03:15 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.69]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q54K300r028294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 13:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338840192; i=@elandsys.com; bh=jgJ4GK3RifTXHUyRTpXoKIUeVVMsZLkOutPbx2LraFI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1moC9XRmXWQTvE1mFV8KJf3y2Asihbv6cAILxHCs1fUpneGOC9B/QepKCQ5k++1ee 77O/V4dQELuMh0Ff/kZUHumnEtKgZNkdf65E8PwvhiIyoiF3hqx/Fp5E5MqnsVWeji r88T7oCuQxGkepuHazewFgd0XczJkir17Qb0DUek= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1338840192; i=@elandsys.com; bh=jgJ4GK3RifTXHUyRTpXoKIUeVVMsZLkOutPbx2LraFI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uVvSDxqOBb6gNnpXa5TwebcWH1ors65C+UmedGsmN4yqWJAEi+a1iDvyqX86BAM8k /k3tv6EoI0a0RVgimerWPXBytTPp72/LiV46RrtOjuGlmBh/udHY/vBICehBM4zwK9 xJRH6459PC5LUCwJCCoPDvME1zQJmwRuB+bYgknY= Message-Id: <6.2.5.6.2.20120604122117.0a484fd0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 04 Jun 2012 12:59:58 -0700 To: Arthur Thisell From: S Moonesamy In-Reply-To: <1338836169.30418.YahooMailClassic@web125404.mail.ne1.yahoo .com> References: <1338836169.30418.YahooMailClassic@web125404.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, ietf@ietf.org Subject: Re: [spfbis] Last Call: (Resolution of The SPF and Sender ID Experiments) to Informational RFC X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 20:03:18 -0000 Hi Arthur, At 11:56 04-06-2012, Arthur Thisell wrote: >I have reviewed the last call draft and find it quite acceptable for >publication. Thanks for the review. >I realize I've been quite lax in following this WG lately and I >should posted comments earlier. In hind sight, I doubt any comments >I would have made would have made any significant improvements to >the draft, it turned out just fine without me. > >That said, here are a few comments... > >1) It was never clear to me why the IESG declared these MARID drafts >as being experimental. Besides the possible confusion between >interpreting records as both SPF and Sender ID, I was under the >impression that the IESG wasn't sure if these proposals would help >or hurt email in general, whether they would damage the function of >the DNS, and whether it was appropriate to let individual >submissions (the WG concluded without any approved IDs) to be other >than experimental or informational. I'm not sure that there is much >point in speculating what the IESG thought, but this draft seems to >concentrate on only the SPF v Sender ID conflicts. The second paragraph of Section 1 of draft-ietf-spfbis-experiment-09 discusses about the publication status. >2) I always thought that the type 99 transition plan was faulty, but >I could not think of anything better. This draft glosses over some >key points about why it ended up with the transition plan that it did. > >* First, no one could come up with an example of a successful >transition where the original had significant deployment (like the >TXT records did) and the new version had no significant advantages >(the type 99 was exactly the same as TXT, other than theoretical >elegance.) Even MX records still fall back to A records. > >* Jim and Harry from Microsoft expressed very strong objections to >any requirement that type 99 records MUST be checked. Their >explanation was that apparently some MS applications used an API to >ask about DNS records, my impression was that this API worked >transparently on things like netware and their active directory and >such too. No port 53 communication was done via this API, indeed, >port 53 was often explicitly blocked at the firewall so clients >couldn't even get around using this API if the wanted to. This API >supported a very limited set of DNS records, TXT being one of them, >but had zero support for new/unknown record types. Not only did >the then current version of that API have no way of querying type 99 >records, the next version had been put into feature freeze, and the >version after that had no plans on adding such support. > >In short, if the RFCs required checking type 99 records, MS could >not produce implementations that could be standard compliant. They >were willing to compromise on many things, but this wasn't one of them. > >On the other hand, people in the MARID WG objected to any >requirement to check TXT records, arguing that doing so would hinder >the transition to type 99 records since people could just publish >TXT records and know that they would always work. According to the SPFBIS Charter the following is out-of-scope: "Revisiting past technical arguments where consensus was reached in the MARID working group, except where review is reasonably warranted based on operational experience." The working group followed what was in the charter. >So, the result was: > >* the RFC MUST NOT require checking type 99 records, or it would >lose support of MS. > >* the RFC MUST allow the checking of type 99 records, otherwise no >migration would be possible. > >* the RFC MUST NOT require checking of TXT records, or it would lose >support of IETF players and hinder migration. > >* the RFC MUST allow the checking of TXT records, otherwise you >would lose a large install base. > >I, and others, were quite aware at the time that the language put >into the RFC would make it so compliant implementations might not be >able to communicate with compliant publishers. No one came forward >with better language. I felt that as long as TXT could be used, >noting else was likely to matter. > >Hindsight is 20/20 and positions appear to have softened over the >years. Things like DKIM managed to get by with much less >handwringing and I suspect if SPF was done today, known-bogus >language like this wouldn't have made it into the draft. There were discussions about this issue on the WG mailing list and during last IETF meeting ( http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt ). The matter was noted in the Write-up: The discussions about the RRTYPE 99 DNS Resource Record were controversial. The issue was resolved. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Wed Jun 6 08:32:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DDF21F889B for ; Wed, 6 Jun 2012 08:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DHncJKVG31r for ; Wed, 6 Jun 2012 08:32:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AEF21F8896 for ; Wed, 6 Jun 2012 08:32:44 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.116]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q56FWQAn029756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 08:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1338996759; i=@elandsys.com; bh=vxcImfPfbNU5cyY3k3blEx/fqd33oUaFqmmjPx6bHDw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EunvKuRVhnPoPjBxzehjnF8HhPbIjOZaJdPNC7yqCXn81cMqTMl/V7h4Ncx6HzxaH W5GPzJkWwPSSQpfa39/meqM0jKgEo9y3OWLDD1GrHXVkCTcffzkaJtjPmojKxL2Jey q/SqogYsAtIh2NTPPq8f7BQ9RtXup4TPfncbUjno= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1338996759; i=@elandsys.com; bh=vxcImfPfbNU5cyY3k3blEx/fqd33oUaFqmmjPx6bHDw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gIB074wlEXJg5hF/P4/A052SnUOf7GmvDOT1A0jrzwDDtHy3JQ6puD4fGQWIJ2MHl PMX1Ep3Y2wBD4ekeWFZpGUx0W9mkjmXa40kn0xpfzK3iInlHFJXSsJPlU9is8R1l+C gaMkdJb306z5PLYkjyHAGPxmx5AiTnEA4es3dmAM= Message-Id: <6.2.5.6.2.20120606081749.0a94ad98@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Jun 2012 08:30:49 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4FCF32B5.7010102@gmail.com> References: <4FCF32B5.7010102@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:32:47 -0000 At 03:36 06-06-2012, Brian E Carpenter wrote: >Please see attached review. >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please see the FAQ at >. > >Please resolve these comments along with any other Last Call comments >you may receive. > >Document: draft-ietf-spfbis-experiment-09.txt >Reviewer: Brian Carpenter >Review Date: 2012-06-06 >IETF LC End Date: 2012-06-09 >IESG Telechat date: > >Summary: Almost ready >-------- > >Comment: >-------- > >I think the Conclusions and Appendix A are almost entirely correct. > >Major issues: >------------- > >IMHO section 3.1 needs several clarifications: > >"These surveys selected substantial sets of distinct domain names..." > >Were these exclusively domain names with MX records? > >Also in section 3.1 there are several tables like: > > "+------------------+-----------+-------+ > | Domains queried | 1,000,000 | - | > | TXT replies | 397,511 | 39.8% | > | SPF replies | 6,627 | <1.0% | > | SPF+TXT replies | 6,603 | <1.0% | > | spf2.0/* replies | 5,291 | <1.0% | > +------------------+-----------+-------+" > >It is not explained what is meant by "TXT replies" and "SPF+TXT replies". > >Does "TXT replies" mean *any* kind of TXT record, or only TXT records that >start with "v=spf"? > >Does "SPF+TXT replies" mean that both an SPF and a TXT record exists for these >FQDNs? If so, are they identical? (Presumably they should be.) > >At the moment I can't fully understand the significance of the results. > >Also, RFC4406 states that "Sending domains MAY publish either or both formats" >(i.e. spf1 or spf2.0). That being so, I would ideally expect to see nine rows >in the results table: > >SPF RR only, spf1 only >SPF RR only, spf2.0 only >SPF RR only, spf1 and spf2.0 >TXT RR only, spf1 only >TXT RR only, spf2.0 only >TXT RR only, spf1 and spf2.0 >SPF and TXT RRs, spf1 only >SPF and TXT RRs, spf2.0 only >SPF and TXT RRs, spf1 and spf2.0 > >It's possible that some of these are always zero but there is no way >for a reader >to tell. This relates to the breakage in the SPF transition plan >that the draft >points out (Appendix A, bullet 4). There was a significant comment about Section 3.1 during the AD evaluation. I'll leave it to Murray to get me the modified text to address this review. :-) >Finally, in Appendix A we find: > > "Fortunately in the intervening time, the requirements for new RRTYPE > assignments was changed to Expert Review, and the posture has become > more relaxed." > >This is slightly inaccurate. Actually the policy has been changed to >RFC6195, which is a modified form of Expert Review. I suggest something >less opinionated: > > Fortunately in the intervening time, the requirements for new RRTYPE > assignments was changed to be less stringent [RFC6195]. > >Nits >---- > >"9.1. Normative References > > [DNS] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, November 1987. > > [PRA] Lyon, J., "Purported Responsible Address in E-Mail > Messages", RFC 4407, April 2006." > >Firstly, it's quite inconvenient having references like this >instead of [RFC1035] etc. I'll leave it to Andrew to come up with the change to address this. :-) >Secondly, it doesn't seem right to have Experimental RFCs listed >as normative references. In fact, since this draft is not a technical >specification, I'm not sure it needs to have the Normative/Informative >split at all. There were some comments about the normative references (see summary at http://www.ietf.org/mail-archive/web/spfbis/current/msg01505.html ). I'll use that as input for the answer if there aren't any comments. If anyone has any comments about the above, please post them to the SPFBIS mailing list. Regards, S. Moonesamy (as document shepherd) From ajs@anvilwalrusden.com Wed Jun 6 08:53:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCC321F8851 for ; Wed, 6 Jun 2012 08:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id towEOoSs7dPW for ; Wed, 6 Jun 2012 08:53:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8626421F851E for ; Wed, 6 Jun 2012 08:53:21 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1C92F1ECB41D; Wed, 6 Jun 2012 15:53:20 +0000 (UTC) Date: Wed, 6 Jun 2012 11:53:21 -0400 From: Andrew Sullivan To: S Moonesamy Message-ID: <20120606155305.GH5859@crankycanuck.ca> References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606081749.0a94ad98@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120606081749.0a94ad98@elandnews.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: spfbis@ietf.org, draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:53:22 -0000 On Wed, Jun 06, 2012 at 08:30:49AM -0700, S Moonesamy wrote: > >Firstly, it's quite inconvenient having references like this > >instead of [RFC1035] etc. > > I'll leave it to Andrew to come up with the change to address this. :-) This isn't a change anyone needs to make, it's a style complaint. The editors preferred to use the symbolic-reference style, and the reviewer prefers the RFC-named style. I also personally prefer the latter, but the RFC Editor doesn't have a rule, and I am not willing to run roughshod over historical freedoms that WG document editors have. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From barryleiba.mailing.lists@gmail.com Wed Jun 6 12:23: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 68AC221F87D4 for ; Wed, 6 Jun 2012 12:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.846 X-Spam-Level: X-Spam-Status: No, score=-101.846 tagged_above=-999 required=5 tests=[AWL=-1.136, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6e-FAj7AWc-x for ; Wed, 6 Jun 2012 12:23:10 -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 B435621F8810 for ; Wed, 6 Jun 2012 12:23:07 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5549849lbb.31 for ; Wed, 06 Jun 2012 12:23:06 -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=mfPpvsDnxbvi3HccU+JNx21uIirpgoNI3Q700kSxmGE=; b=C2ZrzoutF1EzGbnNBVtZstsWiDihnzdCTv2JMu6e/BZY/WqOTTy3tvjfZrZ0H50JYp M+1vAP5C+Yyqw1SsM8L8WdEK+IKPS5KTj0Ve67cKPn9EzijQmBR2L4IVFNEqPJ3YHTsh 4zshUEqVK1JleEPLvc0gJtJuDtZKLO2QjLximCQgY1UAd3Cunws6akcNoTN/0BuuJf1N lGVfBwoQHEMqpCfT1Exxw6gK/hzf39Rwo7NjQw0MHmzTlWmXNpGdu8ih9N8knn7FpaZF h1R7vIuS4Wacgy+TEQacfVfmRjMsG6m5O80bxtKJR5t7znWiqUAN4iA6pYHz+pWkv5U1 iMJA== MIME-Version: 1.0 Received: by 10.152.111.200 with SMTP id ik8mr22697847lab.15.1339010586521; Wed, 06 Jun 2012 12:23:06 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Wed, 6 Jun 2012 12:23:06 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120606081749.0a94ad98@elandnews.com> References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606081749.0a94ad98@elandnews.com> Date: Wed, 6 Jun 2012 15:23:06 -0400 X-Google-Sender-Auth: _j5Uh97vd7w27NmaE15e0CM8uP8 Message-ID: From: Barry Leiba To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f46d040891315c304204c1d2b2c1 Cc: "spfbis@ietf.org" , "draft-ietf-spfbis-experiment.all@tools.ietf.org" Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 19:23:11 -0000 --f46d040891315c304204c1d2b2c1 Content-Type: text/plain; charset=ISO-8859-1 Leaving the entire message below, because Brian doesn't appear to have been copied on it. But I just want to respond to one bit: >> Secondly, it doesn't seem right to have Experimental RFCs listed as normative >> references. In fact, since this draft is not a technical specification, I'm not sure >> it needs to have the Normative/Informative split at all. > > There were some comments about the normative references (see summary > at http://www.ietf.org/mail-**archive/web/spfbis/current/**msg01505.html ). > I'll use that as input for the answer if there aren't any comments. I don't see why it's not right at all, and please don't make the mistake of thinking that an informational document doesn't have normative references. I think the original Experimental docs are *absolutely* normative references for this document, and i see nothing wrong with that at all. Barry On Wednesday, June 6, 2012, S Moonesamy wrote: > At 03:36 06-06-2012, Brian E Carpenter wrote: > >> Please see attached review. >> > > I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> . >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-spfbis-experiment-**09.txt >> Reviewer: Brian Carpenter >> Review Date: 2012-06-06 >> IETF LC End Date: 2012-06-09 >> IESG Telechat date: >> >> Summary: Almost ready >> -------- >> >> Comment: >> -------- >> >> I think the Conclusions and Appendix A are almost entirely correct. >> >> Major issues: >> ------------- >> >> IMHO section 3.1 needs several clarifications: >> >> "These surveys selected substantial sets of distinct domain names..." >> >> Were these exclusively domain names with MX records? >> >> Also in section 3.1 there are several tables like: >> >> "+------------------+---------**--+-------+ >> | Domains queried | 1,000,000 | - | >> | TXT replies | 397,511 | 39.8% | >> | SPF replies | 6,627 | <1.0% | >> | SPF+TXT replies | 6,603 | <1.0% | >> | spf2.0/* replies | 5,291 | <1.0% | >> +------------------+----------**-+-------+" >> >> It is not explained what is meant by "TXT replies" and "SPF+TXT replies". >> >> Does "TXT replies" mean *any* kind of TXT record, or only TXT records that >> start with "v=spf"? >> >> Does "SPF+TXT replies" mean that both an SPF and a TXT record exists for >> these >> FQDNs? If so, are they identical? (Presumably they should be.) >> >> At the moment I can't fully understand the significance of the results. >> >> Also, RFC4406 states that "Sending domains MAY publish either or both >> formats" >> (i.e. spf1 or spf2.0). That being so, I would ideally expect to see nine >> rows >> in the results table: >> >> SPF RR only, spf1 only >> SPF RR only, spf2.0 only >> SPF RR only, spf1 and spf2.0 >> TXT RR only, spf1 only >> TXT RR only, spf2.0 only >> TXT RR only, spf1 and spf2.0 >> SPF and TXT RRs, spf1 only >> SPF and TXT RRs, spf2.0 only >> SPF and TXT RRs, spf1 and spf2.0 >> >> It's possible that some of these are always zero but there is no way for >> a reader >> to tell. This relates to the breakage in the SPF transition plan that the >> draft >> points out (Appendix A, bullet 4). >> > > There was a significant comment about Section 3.1 during the AD > evaluation. I'll leave it to Murray to get me the modified text to address > this review. :-) > > Finally, in Appendix A we find: >> >> "Fortunately in the intervening time, the requirements for new RRTYPE >> assignments was changed to Expert Review, and the posture has become >> more relaxed." >> >> This is slightly inaccurate. Actually the policy has been changed to >> RFC6195, which is a modified form of Expert Review. I suggest something >> less opinionated: >> >> Fortunately in the intervening time, the requirements for new RRTYPE >> assignments was changed to be less stringent [RFC6195]. >> >> Nits >> ---- >> >> "9.1. Normative References >> >> [DNS] Mockapetris, P., "Domain names - implementation and >> specification", STD 13, RFC 1035, November 1987. >> >> [PRA] Lyon, J., "Purported Responsible Address in E-Mail >> Messages", RFC 4407, April 2006." >> >> Firstly, it's quite inconvenient having references like this >> instead of [RFC1035] etc. >> > > I'll leave it to Andrew to come up with the change to address this. :-) > > Secondly, it doesn't seem right to have Experimental RFCs listed >> as normative references. In fact, since this draft is not a technical >> specification, I'm not sure it needs to have the Normative/Informative >> split at all. >> > > There were some comments about the normative references (see summary at > http://www.ietf.org/mail-**archive/web/spfbis/current/**msg01505.html ). > I'll use that as input for the answer if there aren't any comments. > > If anyone has any comments about the above, please post them to the SPFBIS > mailing list. > > Regards, > S. Moonesamy (as document shepherd) > ______________________________**_________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/**listinfo/spfbis > --f46d040891315c304204c1d2b2c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Leaving the entire message below, because Brian doesn't appear to have = been copied on it. =A0But I just want to respond to one bit:
>> Secondly, it doesn't seem right to= have Experimental RFCs listed=A0as normative
>> references. In fact, s= ince this draft is not a technical=A0specification, I'm not sure=
>> it needs to have= the Normative/Informative=A0split at all.
>
> There were some comment= s about the normative references (see summary
> at=A0http://www.ietf.org/mail-archi= ve/web/spfbis/current/msg01505.html ).
> I'll use that as input= for the answer if there aren't any comments.

=
I don't see why it's not right at all, and please don't ma= ke the mistake of thinking that an informational document doesn't have = normative references. =A0I think the original Experimental docs are *absolu= tely* normative references for this document, and i see nothing wrong with = that at all.

Barry

On Wednesday, June 6, 2012, S Moonesamy w= rote:
At 03:36 = 06-06-2012, Brian E Carpenter wrote:
Please see attached review.

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&g= t;.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-spfbis-experiment-09.txt
Reviewer: Brian Carpenter
Review Date: 2012-06-06
IETF LC End Date: 2012-06-09
IESG Telechat date:

Summary: =A0Almost ready
--------

Comment:
--------

I think the Conclusions and Appendix A are almost entirely correct.

Major issues:
-------------

IMHO section 3.1 needs several clarifications:

"These surveys selected substantial sets of distinct domain names...&q= uot;

Were these exclusively domain names with MX records?

Also in section 3.1 there are several tables like:

=A0 =A0"+------------------+-----------+-------+
=A0 =A0 | Domains queried =A0| 1,000,000 | =A0 - =A0 |
=A0 =A0 | TXT replies =A0 =A0 =A0| =A0 397,511 | 39.8% |
=A0 =A0 | SPF replies =A0 =A0 =A0| =A0 =A0 6,627 | <1.0% |
=A0 =A0 | SPF+TXT replies =A0| =A0 =A0 6,603 | <1.0% |
=A0 =A0 | spf2.0/* replies | =A0 =A0 5,291 | <1.0% |
=A0 =A0 +------------------+-----------+-------+"

It is not explained what is meant by "TXT replies" and "SPF+= TXT replies".

Does "TXT replies" mean *any* kind of TXT record, or only TXT rec= ords that
start with "v=3Dspf"?

Does "SPF+TXT replies" mean that both an SPF and a TXT record exi= sts for these
FQDNs? If so, are they identical? (Presumably they should be.)

At the moment I can't fully understand the significance of the results.=

Also, RFC4406 states that "Sending domains MAY publish either or both = formats"
(i.e. spf1 or spf2.0). That being so, I would ideally expect to see nine ro= ws
in the results table:

SPF RR only, spf1 only
SPF RR only, spf2.0 only
SPF RR only, spf1 and spf2.0
TXT RR only, spf1 only
TXT RR only, spf2.0 only
TXT RR only, spf1 and spf2.0
SPF and TXT RRs, spf1 only
SPF and TXT RRs, spf2.0 only
SPF and TXT RRs, spf1 and spf2.0

It's possible that some of these are always zero but there is no way fo= r a reader
to tell. This relates to the breakage in the SPF transition plan that the d= raft
points out (Appendix A, bullet 4).

There was a significant comment about Section 3.1 during the AD evaluation.= =A0I'll leave it to Murray to get me the modified text to address this= review. :-)

Finally, in Appendix A we find:

=A0"Fortunately in the intervening time, the requirements for new RRT= YPE
=A0 assignments was changed to Expert Review, and the posture has become =A0 more relaxed."

This is slightly inaccurate. Actually the policy has been changed to
RFC6195, which is a modified form of Expert Review. I suggest something
less opinionated:

=A0 Fortunately in the intervening time, the requirements for new RRTYPE =A0 assignments was changed to be less stringent [RFC6195].

Nits
----

"9.1. =A0Normative References

=A0 [DNS] =A0 =A0 =A0Mockapetris, P., "Domain names - implementation = and
=A0 =A0 =A0 =A0 =A0 =A0 =A0specification", STD 13, RFC 1035, November= 1987.

=A0 [PRA] =A0 =A0 =A0Lyon, J., "Purported Responsible Address in E-Ma= il
=A0 =A0 =A0 =A0 =A0 =A0 =A0Messages", RFC 4407, April 2006."

Firstly, it's quite inconvenient having references like this
instead of [RFC1035] etc.

I'll leave it to Andrew to come up with the change to address this. :-)=

Secondly, it doesn't seem right to have Experimental RFCs listed
as normative references. In fact, since this draft is not a technical
specification, I'm not sure it needs to have the Normative/Informative<= br> split at all.

There were some comments about the normative references (see summary at = http://www.ietf.org/mail-archive/web/spfbis/current/msg01= 505.html ). =A0I'll use that as input for the answer if there aren'= t any comments.

If anyone has any comments about the above, please post them to the SPFBIS = mailing list.

Regards,
S. Moonesamy (as document shepherd)
_______________________________________________
spfbis mailing list
spfbis@ietf.org
https://www.ietf.org/mailman/listinfo/spfbis
--f46d040891315c304204c1d2b2c1-- From sm@elandsys.com Wed Jun 6 12:49:30 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B2611E80AD for ; Wed, 6 Jun 2012 12:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OltRCdV7IQuc for ; Wed, 6 Jun 2012 12:49:24 -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 EDDA811E80AC for ; Wed, 6 Jun 2012 12:49:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.116]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q56Jmxqn016243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 12:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339012152; i=@elandsys.com; bh=jJL9EgVkndiNXACdh4Qzk7y3fb1y1n0nRfRMtoHwc5I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UNNTkLSHM0bM8kzONm1gsCA9fuBVaY4lyY43ugH5Yjp1oVAs1VTWhW9G7J16J+fL6 GdWwAAg9X7GfD7mk9Gs0I6w3iHU6nTwX0GTiBVqjSjuUb8g5El9AvH+HM0i7yrcf5F q6gw43UXHK0ysIgHZIxFMrUvQG89M86w8FyknnSI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1339012152; i=@elandsys.com; bh=jJL9EgVkndiNXACdh4Qzk7y3fb1y1n0nRfRMtoHwc5I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZRxHr0WHgP77Plyh9zAIjgH+KXcqhz0rebCLQot5nA/m4IlEXKYibEXNRobmh4njo Ymg95k1eQXp8Pi9IfFcqpJ76lXt5KAf6eFvh0k/yNbJuI9wiqnFKBZsLNegNtyXsHO P5nzVRCOrZTtD4JAF5TSkRD4M2F7WVRtkkOjtkTc= Message-Id: <6.2.5.6.2.20120606122623.088e6170@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Jun 2012 12:43:18 -0700 To: Barry Leiba , Brian E Carpenter From: S Moonesamy In-Reply-To: References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606081749.0a94ad98@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 19:49:30 -0000 Hi Barry, At 12:23 06-06-2012, Barry Leiba wrote: >Leaving the entire message below, because Brian doesn't appear to >have been copied on it. I didn't copy Brian as I thought it better to wait for a WG reply. >I don't see why it's not right at all, and please don't make the >mistake of thinking that an informational document doesn't have >normative references. I think the original Experimental docs are >*absolutely* normative references for this document, and i see >nothing wrong with that at all. The comment posted by Dave is at http://www.ietf.org/mail-archive/web/spfbis/current/msg01426.html I generally use the following for guidance: "Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work." Regards S. Moonesamy From superuser@gmail.com Wed Jun 6 21:51:07 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 A338C21F86A4 for ; Wed, 6 Jun 2012 21:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgJMop0H9pG2 for ; Wed, 6 Jun 2012 21:51:05 -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 92D9421F869E for ; Wed, 6 Jun 2012 21:50:49 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so266015lbb.31 for ; Wed, 06 Jun 2012 21:50:48 -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=T6Jv+b3wh8DFCtKHceF/Pt/mAER9TPzECXCpPhly7x4=; b=OuCZkwEBx22KMwvKQs368ASE+6W4FTLd81Y7AtF0kTJhaeBON/Nm/aZPylTSjcK9iX wxBDb41dYw/AQ9CRt3s2EoPDHMc7NOgbUVNS8qOheV27olZD+b8AhIvTrKwYVTpvM31L R3tdD7HEkIl0AEj05SllY8j3X+RziBFOqlJ4bd7rxOljp6dMcqE4hW622aGn30qMyUTR IGjvy0/scryrdD1ugqDsRuBguov9ExTSIv7VY2vW5EOe8Lqtp4SkrLy0sdFjRSNkaVcN d7j5fdHvJp8iQmMaym7Xb6wUDgxas6EPqTsbzFwXoLaUhytcNWwPddzNLWIXLxQrl62l Poew== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr630307lab.40.1339044648442; Wed, 06 Jun 2012 21:50:48 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 6 Jun 2012 21:50:48 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120606081749.0a94ad98@elandnews.com> References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606081749.0a94ad98@elandnews.com> Date: Wed, 6 Jun 2012 21:50:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d040838d39bdbc804c1daa080 Cc: spfbis@ietf.org, draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 04:51:07 -0000 --f46d040838d39bdbc804c1daa080 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 6, 2012 at 8:30 AM, S Moonesamy wrote: > > ------------- >> >> IMHO section 3.1 needs several clarifications: >> >> "These surveys selected substantial sets of distinct domain names..." >> >> Were these exclusively domain names with MX records? >> > Is that an important thing to state? I don't believe it is. They're domain names seen on incoming email in some way. > >> Also in section 3.1 there are several tables like: >> >> "+------------------+-----------+-------+ >> | Domains queried | 1,000,000 | - | >> | TXT replies | 397,511 | 39.8% | >> | SPF replies | 6,627 | <1.0% | >> | SPF+TXT replies | 6,603 | <1.0% | >> | spf2.0/* replies | 5,291 | <1.0% | >> +------------------+-----------+-------+" >> >> It is not explained what is meant by "TXT replies" and "SPF+TXT replies". >> > The section is discussing RRTYPEs, so TXT refers to TXT RRTYPEs (type 16) and SPF refers to SPF RRTYPEs (type 99). > >> Does "TXT replies" mean *any* kind of TXT record, or only TXT records that >> start with "v=spf"? >> > That's a fair question. I'll update the draft accordingly. > >> Does "SPF+TXT replies" mean that both an SPF and a TXT record exists for >> these >> FQDNs? If so, are they identical? (Presumably they should be.) >> > Yes to the first question. We didn't evaluate the second. > >> At the moment I can't fully understand the significance of the results. >> > The picture they're trying to paint is twofold: (a) the uptake of type 99 records versus type 16 records; and (b) for type 16 records, the number of attempts to cause receivers to apply PRA, which is part of Sender ID. Substantial uptake of either type 99 records or type 16 records that request PRA processing would be an indicator of substantial interest in Sender ID. The data show neither is present. > >> Also, RFC4406 states that "Sending domains MAY publish either or both >> formats" >> (i.e. spf1 or spf2.0). That being so, I would ideally expect to see nine >> rows >> in the results table: >> >> SPF RR only, spf1 only >> SPF RR only, spf2.0 only >> SPF RR only, spf1 and spf2.0 >> TXT RR only, spf1 only >> TXT RR only, spf2.0 only >> TXT RR only, spf1 and spf2.0 >> SPF and TXT RRs, spf1 only >> SPF and TXT RRs, spf2.0 only >> SPF and TXT RRs, spf1 and spf2.0 >> > I think this will provide more clutter than clarity. The answer to the over-arching question, namely "Which one has greater uptake?", is already available without this breakdown, simply because the number of "spf2.0" records is miniscule by comparison to the rest. So really we need to compare the use of the two RRTYPEs and the use of the two protocols independent of the RRTYPEs, since SPF only cared about TXT and SIDF could use either. Pete suggests having two tables for each survey: (a) a comparison of RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of RRTYPE. Would that be sufficient? >> It's possible that some of these are always zero but there is no way for >> a reader >> to tell. This relates to the breakage in the SPF transition plan that the >> draft >> points out (Appendix A, bullet 4). >> > Major issues: > > There was a significant comment about Section 3.1 during the AD > evaluation. I'll leave it to Murray to get me the modified text to address > this review. :-) > Right; Pete had roughly the same question but he hasn't asked it on the spfbis list yet. His suggestion is now above, for the record. :-) > > Finally, in Appendix A we find: >> >> "Fortunately in the intervening time, the requirements for new RRTYPE >> assignments was changed to Expert Review, and the posture has become >> more relaxed." >> >> This is slightly inaccurate. Actually the policy has been changed to >> RFC6195, which is a modified form of Expert Review. I suggest something >> less opinionated: >> >> Fortunately in the intervening time, the requirements for new RRTYPE >> assignments was changed to be less stringent [RFC6195]. >> > OK. > >> Nits >> ---- >> >> "9.1. Normative References >> >> [DNS] Mockapetris, P., "Domain names - implementation and >> specification", STD 13, RFC 1035, November 1987. >> >> [PRA] Lyon, J., "Purported Responsible Address in E-Mail >> Messages", RFC 4407, April 2006." >> >> Firstly, it's quite inconvenient having references like this >> instead of [RFC1035] etc. >> > > I'll leave it to Andrew to come up with the change to address this. :-) > I concur with Andrew that this is a stylistic choice. I find the mnemonic method in use easier to read. > > Secondly, it doesn't seem right to have Experimental RFCs listed >> as normative references. In fact, since this draft is not a technical >> specification, I'm not sure it needs to have the Normative/Informative >> split at all. >> > > There were some comments about the normative references (see summary at > http://www.ietf.org/mail-**archive/web/spfbis/current/**msg01505.html ). > I'll use that as input for the answer if there aren't any comments. > I concur with Barry's reply to this point. -MSK --f46d040838d39bdbc804c1daa080 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 6, 2012 at 8:30 AM, S Moonesamy <sm+ietf@elandsys.com= > wrote:

-------------

IMHO section 3.1 needs several clarifications:

"These surveys selected substantial sets of distinct domain names...&q= uot;

Were these exclusively domain names with MX records?

Is that an important thing to state?=A0 I don't believe= it is.=A0 They're domain names seen on incoming email in some way.

=A0

Also in section 3.1 there are several tables like:

=A0 =A0"+------------------+-----------+-------+
=A0 =A0 | Domains queried =A0| 1,000,000 | =A0 - =A0 |
=A0 =A0 | TXT replies =A0 =A0 =A0| =A0 397,511 | 39.8% |
=A0 =A0 | SPF replies =A0 =A0 =A0| =A0 =A0 6,627 | <1.0% |
=A0 =A0 | SPF+TXT replies =A0| =A0 =A0 6,603 | <1.0% |
=A0 =A0 | spf2.0/* replies | =A0 =A0 5,291 | <1.0% |
=A0 =A0 +------------------+-----------+-------+"

It is not explained what is meant by "TXT replies" and "SPF+= TXT replies".

The section is dis= cussing RRTYPEs, so TXT refers to TXT RRTYPEs (type 16) and SPF refers to S= PF RRTYPEs (type 99).
=A0

Does "TXT replies" mean *any* kind of TXT record, or only TXT rec= ords that
start with "v=3Dspf"?

That&= #39;s a fair question.=A0 I'll update the draft accordingly.
=A0
=

Does "SPF+TXT replies" mean that both an SPF and a TXT record exi= sts for these
FQDNs? If so, are they identical? (Presumably they should be.)

Yes to the first question.=A0 We didn't evalu= ate the second.
=A0

At the moment I can't fully understand the significance of the results.=

The picture they're trying to pa= int is twofold: (a) the uptake of type 99 records versus type 16 records; a= nd (b) for type 16 records, the number of attempts to cause receivers to ap= ply PRA, which is part of Sender ID.=A0 Substantial uptake of either type 9= 9 records or type 16 records that request PRA processing would be an indica= tor of substantial interest in Sender ID.=A0 The data show neither is prese= nt.

=A0

Also, RFC4406 states that "Sending domains MAY publish either or both = formats"
(i.e. spf1 or spf2.0). That being so, I would ideally expect to see nine ro= ws
in the results table:

SPF RR only, spf1 only
SPF RR only, spf2.0 only
SPF RR only, spf1 and spf2.0
TXT RR only, spf1 only
TXT RR only, spf2.0 only
TXT RR only, spf1 and spf2.0
SPF and TXT RRs, spf1 only
SPF and TXT RRs, spf2.0 only
SPF and TXT RRs, spf1 and spf2.0

I th= ink this will provide more clutter than clarity.=A0 The answer to the over-= arching question, namely "Which one has greater uptake?", is alre= ady available without this breakdown, simply because the number of "sp= f2.0" records is miniscule by comparison to the rest.

So really we need to compare the use of the two RRTYPEs and the use of = the two protocols independent of the RRTYPEs, since SPF only cared about TX= T and SIDF could use either.

Pete suggests having two tables for ea= ch survey: (a) a comparison of RRTYPEs, and (b) a comparison of SPF vs. SID= F independent of RRTYPE.=A0 Would that be sufficient?


It's possible that some of these are always zero but there is no way fo= r a reader
to tell. This relates to the breakage in the SPF transition plan that the d= raft
points out (Appendix A, bullet 4).
Major issues:

There was a significant comment about Section 3.1 during the AD evaluation.= =A0I'll leave it to Murray to get me the modified text to address this= review. :-)

Right; Pete had roughly the same ques= tion but he hasn't asked it on the spfbis list yet.=A0 His suggestion i= s now above, for the record.=A0 :-)
=A0

Finally, in Appendix A we find:

=A0"Fortunately in the intervening time, the requirements for new RRT= YPE
=A0 assignments was changed to Expert Review, and the posture has become =A0 more relaxed."

This is slightly inaccurate. Actually the policy has been changed to
RFC6195, which is a modified form of Expert Review. I suggest something
less opinionated:

=A0 Fortunately in the intervening time, the requirements for new RRTYPE =A0 assignments was changed to be less stringent [RFC6195].

OK.
=A0

Nits
----

"9.1. =A0Normative References

=A0 [DNS] =A0 =A0 =A0Mockapetris, P., "Domain names - implementation = and
=A0 =A0 =A0 =A0 =A0 =A0 =A0specification", STD 13, RFC 1035, November= 1987.

=A0 [PRA] =A0 =A0 =A0Lyon, J., "Purported Responsible Address in E-Ma= il
=A0 =A0 =A0 =A0 =A0 =A0 =A0Messages", RFC 4407, April 2006."

Firstly, it's quite inconvenient having references like this
instead of [RFC1035] etc.

I'll leave it to Andrew to come up with the change to address this. :-)=

I concur with Andrew that this is a stylistic cho= ice.=A0 I find the mnemonic method in use easier to read.
=A0

Secondly, it doesn't seem right to have Experimental RFCs listed
as normative references. In fact, since this draft is not a technical
specification, I'm not sure it needs to have the Normative/Informative<= br> split at all.

There were some comments about the normative references (see summary at = http://www.ietf.org/mail-archive/web/spfbis/current/msg01= 505.html ). =A0I'll use that as input for the answer if there aren'= t any comments.

I concur with Barry's reply to this point.
-MSK

--f46d040838d39bdbc804c1daa080-- From sm@elandsys.com Wed Jun 6 22:35:07 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 BEC5511E8106; Wed, 6 Jun 2012 22:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.24 X-Spam-Level: X-Spam-Status: No, score=-102.24 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W358Ath1yNlg; Wed, 6 Jun 2012 22:35:05 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 904E311E8104; Wed, 6 Jun 2012 22:35:05 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.116]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q575YjEA017146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2012 22:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339047299; i=@elandsys.com; bh=qJi/u4g2/z5hofWlYU4LmfpJQPeXH97x+n5BZZuIbWA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=m/L0QgGEtqg+SIBpvRJY/9Pws0pCfJbTuE5+I6sjCVovGorHG+7SyZjcvhJRaqyoe Yq8xLJyl4e7Hq/GZShiihmJ7WOo1RM93WszokW1P9RYCZAAK7KGEHf3hQpSy8Imnog wctyvT21+NkrB47GPw26gNj3VoQwxmICCklpjHBE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1339047299; i=@elandsys.com; bh=qJi/u4g2/z5hofWlYU4LmfpJQPeXH97x+n5BZZuIbWA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gcpBr/MX8W1Z+1nuNAzm2xdxuBJtgpuckj9osQiIg8C3lIeAtJ+rhYpW3xappCCcn 3iunAMgsHafqQFfTNht1uQFBXjbLS0SwQ22OK7hTpmpH3BK90lbPvZcr1I0qIALia3 DgjBaXI/YU9x85nO+2FNHqQKzV2DkvWSqumSgT9U= Message-Id: <6.2.5.6.2.20120606215706.0aa1d6c0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Jun 2012 22:28:40 -0700 To: Brian E Carpenter , General Area Review Team From: S Moonesamy In-Reply-To: <4FCF32B5.7010102@gmail.com> References: <4FCF32B5.7010102@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 05:35:08 -0000 Hi Brian, At 03:36 06-06-2012, Brian E Carpenter wrote: >Please see attached review. Thanks for the review. >I think the Conclusions and Appendix A are almost entirely correct. > >Major issues: >------------- > >IMHO section 3.1 needs several clarifications: > >"These surveys selected substantial sets of distinct domain names..." > >Were these exclusively domain names with MX records? They're domain names seen on incoming email in some way. Murray doesn't believe that it is important to state that. If you think it is important, let me know. >Also in section 3.1 there are several tables like: > > "+------------------+-----------+-------+ > | Domains queried | 1,000,000 | - | > | TXT replies | 397,511 | 39.8% | > | SPF replies | 6,627 | <1.0% | > | SPF+TXT replies | 6,603 | <1.0% | > | spf2.0/* replies | 5,291 | <1.0% | > +------------------+-----------+-------+" > >It is not explained what is meant by "TXT replies" and "SPF+TXT replies". > >Does "TXT replies" mean *any* kind of TXT record, or only TXT records that >start with "v=spf"? It's a fair question. The draft will be updated to fix that. >Does "SPF+TXT replies" mean that both an SPF and a TXT record exists for these >FQDNs? If so, are they identical? (Presumably they should be.) Yes to the first question. The working group didn't evaluate the second. >At the moment I can't fully understand the significance of the results. > >Also, RFC4406 states that "Sending domains MAY publish either or both formats" >(i.e. spf1 or spf2.0). That being so, I would ideally expect to see nine rows >in the results table: > >SPF RR only, spf1 only >SPF RR only, spf2.0 only >SPF RR only, spf1 and spf2.0 >TXT RR only, spf1 only >TXT RR only, spf2.0 only >TXT RR only, spf1 and spf2.0 >SPF and TXT RRs, spf1 only >SPF and TXT RRs, spf2.0 only >SPF and TXT RRs, spf1 and spf2.0 Pete suggests having two tables for each survey: (a) a comparison of RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of RRTYPE. Would that be sufficient? >It's possible that some of these are always zero but there is no way >for a reader >to tell. This relates to the breakage in the SPF transition plan >that the draft >points out (Appendix A, bullet 4). > >Finally, in Appendix A we find: > > "Fortunately in the intervening time, the requirements for new RRTYPE > assignments was changed to Expert Review, and the posture has become > more relaxed." > >This is slightly inaccurate. Actually the policy has been changed to >RFC6195, which is a modified form of Expert Review. I suggest something >less opinionated: > > Fortunately in the intervening time, the requirements for new RRTYPE > assignments was changed to be less stringent [RFC6195]. This is slightly inaccurate. Actually the policy has been changed to RFC6195, which is a modified form of Expert Review. Murray suggests something less opinionated: Fortunately in the intervening time, the requirements for new RRTYPE assignments was changed to be less stringent [RFC6195]. >Nits >---- > >"9.1. Normative References > > [DNS] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, November 1987. > > [PRA] Lyon, J., "Purported Responsible Address in E-Mail > Messages", RFC 4407, April 2006." > >Firstly, it's quite inconvenient having references like this >instead of [RFC1035] etc. Here's Andrew's response as WG Chair: This isn't a change anyone needs to make, it's a style complaint. The editor preferred to use the symbolic-reference style, and the reviewer prefers the RFC-named style. He also personally prefer the latter, but the RFC Editor doesn't have a rule. Murray finds the mnemonic method in use easier to read. >Secondly, it doesn't seem right to have Experimental RFCs listed >as normative references. In fact, since this draft is not a technical >specification, I'm not sure it needs to have the Normative/Informative >split at all. Dave Crocker and Barry Leiba had an discussion about "normative references" at http://www.ietf.org/mail-archive/web/spfbis/current/msg01426.html. Even though the draft is not a technical specification, it is important that the reader reads the RFCs listed as normative to understand the draft. The Experimental RFCs are not even a downward reference in this case as this draft is not being published on the Standards Track. Regards, S. Moonesamy (as document shepherd) From brian.e.carpenter@gmail.com Thu Jun 7 00:26:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC6821F85EA; Thu, 7 Jun 2012 00:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.671 X-Spam-Level: X-Spam-Status: No, score=-101.671 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNgrPI2xtTzG; Thu, 7 Jun 2012 00:26:40 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1D8A21F8541; Thu, 7 Jun 2012 00:26:39 -0700 (PDT) Received: by eekd4 with SMTP id d4so109452eek.31 for ; Thu, 07 Jun 2012 00:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zpbe70X/utG+0dbvqr9dC6TknxtCoG3EDikz6M0giVo=; b=p5+A/c8tBHoCG1nMLC0zOo8g8CeFSjWpGu+qQE4rPrvHWIKdL6c/TZq5n8pWZyTArL fqv9/bZ9IFh0Kn0cXZuw6sY9ZCol7BxVxJsWekYToHVIL54EDPyfovZDSEmYTvQol9kz Mmpv+baPQXkLJqPNEVB2mTMfmoh6vofdWUMCt7irqC0B99+otrJwJWDkjgvea7srIreO 6mq/DzQ9uK7IZ9zhz3+fqHwPY351v/KclFHmRt+EPyzoge+FmvB5xD2dpSxTA8GaUwp9 hfiQbl9wojaskebuhwNoCcdFn6GASLN/NRXkGB3smgpQFtHc4nB7Vbq/jdNp3mgPLBir ghdw== Received: by 10.14.97.77 with SMTP id s53mr522331eef.104.1339053998746; Thu, 07 Jun 2012 00:26:38 -0700 (PDT) Received: from [192.168.1.66] (host-2-102-217-102.as13285.net. [2.102.217.102]) by mx.google.com with ESMTPS id c13sm7585924eeb.7.2012.06.07.00.26.36 (version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 00:26:37 -0700 (PDT) Message-ID: <4FD057A2.5060909@gmail.com> Date: Thu, 07 Jun 2012 08:26:26 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: S Moonesamy References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606081749.0a94ad98@elandnews.com> <6.2.5.6.2.20120606122623.088e6170@elandnews.com> In-Reply-To: <6.2.5.6.2.20120606122623.088e6170@elandnews.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 Jun 2012 00:48:05 -0700 Cc: spfbis@ietf.org, General Area Review Team , Barry Leiba , draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 07:26:40 -0000 Restoring the Gen-ART CC since we need the discussion in the archive. See below... On 2012-06-06 20:43, S Moonesamy wrote: > Hi Barry, > At 12:23 06-06-2012, Barry Leiba wrote: >> Leaving the entire message below, because Brian doesn't appear to have >> been copied on it. > > I didn't copy Brian as I thought it better to wait for a WG reply. > >> I don't see why it's not right at all, and please don't make the >> mistake of thinking that an informational document doesn't have >> normative references. I think the original Experimental docs are >> *absolutely* normative references for this document, and i see nothing >> wrong with that at all. > > The comment posted by Dave is at > http://www.ietf.org/mail-archive/web/spfbis/current/msg01426.html > > I generally use the following for guidance: > > "Normative references specify documents that must be read to > understand or implement the technology in the new RFC, or > whose technology must be present for the technology in the > new RFC to work." Exactly. This draft does not define new technology, is not a technical specification (cf RFC 2026), and therefore does not need normative references. Brian > > Regards > S. Moonesamy > > . > From brian.e.carpenter@gmail.com Thu Jun 7 00:35:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7BC21F864A; Thu, 7 Jun 2012 00:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.372 X-Spam-Level: X-Spam-Status: No, score=-101.372 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MDSWRhwXdax; Thu, 7 Jun 2012 00:35:19 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7F1A21F8648; Thu, 7 Jun 2012 00:35:18 -0700 (PDT) Received: by eaaq13 with SMTP id q13so110889eaa.31 for ; Thu, 07 Jun 2012 00:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UCi8a9fQMU7zs+fINcq4f00hKhTbXC9pA1BqWoIwhoY=; b=STLTta5jFzHg4cbjTtQf0l3ZJAFUzFJI3zYY9fKb4/1BGPNi7EDXI1sPzi3acm6+RN rcVlJee+ncG8R/WnGHzMtWNiB1ch5iSbJor8JiLn3ocbPKbGKn0WVF9+2GybdGsqExnp NzYjoyOiSHFY/blT4AOE8wKjOq1+JMYtJvRvgqL7Q08Kwv9MBhxHAghKcwom7cgMlOb7 ns5EvMiRbM4Ygrxd86aO1ExTw3KYDNdGI9YSl15qPRfFwJrl/+0vxUWLzqnXnsdM6nzu ErsG5cpKnoJULLH3K7stAYhvZ6p5KzD/7tBgS+CQV0L/S2o/mVrg4rOVNW1n+6FJC7gL mAQg== Received: by 10.14.188.4 with SMTP id z4mr632975eem.228.1339054517813; Thu, 07 Jun 2012 00:35:17 -0700 (PDT) Received: from [192.168.1.66] (host-2-102-217-102.as13285.net. [2.102.217.102]) by mx.google.com with ESMTPS id c51sm7630278eei.12.2012.06.07.00.35.16 (version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 00:35:16 -0700 (PDT) Message-ID: <4FD059B0.9020900@gmail.com> Date: Thu, 07 Jun 2012 08:35:12 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606081749.0a94ad98@elandnews.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 Jun 2012 00:48:14 -0700 Cc: spfbis@ietf.org, General Area Review Team , draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Fwd: Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 07:35:20 -0000 Restoring the Gen-ART CC since we need the discussion in the archive. Thanks Murray, see below... On 2012-06-07 06:12, Murray S. Kucherawy wrote: > For some reason you were dropped from the Cc: list. Forwarding for your > consideration. > > ---------- Forwarded message ---------- > From: Murray S. Kucherawy > Date: Wed, Jun 6, 2012 at 9:50 PM > Subject: Re: [spfbis] Gen-ART LC review of > draft-ietf-spfbis-experiment-09.txt > To: S Moonesamy > Cc: spfbis@ietf.org, draft-ietf-spfbis-experiment.all@tools.ietf.org > > > On Wed, Jun 6, 2012 at 8:30 AM, S Moonesamy wrote: > >> ------------- >>> IMHO section 3.1 needs several clarifications: >>> >>> "These surveys selected substantial sets of distinct domain names..." >>> >>> Were these exclusively domain names with MX records? >>> > Is that an important thing to state? I don't believe it is. They're > domain names seen on incoming email in some way. OK, it's necessary and sufficient to state that. > >>> Also in section 3.1 there are several tables like: >>> >>> "+------------------+-----------+-------+ >>> | Domains queried | 1,000,000 | - | >>> | TXT replies | 397,511 | 39.8% | >>> | SPF replies | 6,627 | <1.0% | >>> | SPF+TXT replies | 6,603 | <1.0% | >>> | spf2.0/* replies | 5,291 | <1.0% | >>> +------------------+-----------+-------+" >>> >>> It is not explained what is meant by "TXT replies" and "SPF+TXT replies". >>> > The section is discussing RRTYPEs, so TXT refers to TXT RRTYPEs (type 16) > and SPF refers to SPF RRTYPEs (type 99). As noted below there are 9 different combinations and you only have 4 rows. It's ambiguous data. >>> Does "TXT replies" mean *any* kind of TXT record, or only TXT records that >>> start with "v=spf"? >>> > That's a fair question. I'll update the draft accordingly. > > >>> Does "SPF+TXT replies" mean that both an SPF and a TXT record exists for >>> these >>> FQDNs? If so, are they identical? (Presumably they should be.) >>> > Yes to the first question. We didn't evaluate the second. > > >>> At the moment I can't fully understand the significance of the results. >>> > The picture they're trying to paint is twofold: (a) the uptake of type 99 > records versus type 16 records; and (b) for type 16 records, the number of > attempts to cause receivers to apply PRA, which is part of Sender ID. > Substantial uptake of either type 99 records or type 16 records that > request PRA processing would be an indicator of substantial interest in > Sender ID. The data show neither is present. > > > >>> Also, RFC4406 states that "Sending domains MAY publish either or both >>> formats" >>> (i.e. spf1 or spf2.0). That being so, I would ideally expect to see nine >>> rows >>> in the results table: >>> >>> SPF RR only, spf1 only >>> SPF RR only, spf2.0 only >>> SPF RR only, spf1 and spf2.0 >>> TXT RR only, spf1 only >>> TXT RR only, spf2.0 only >>> TXT RR only, spf1 and spf2.0 >>> SPF and TXT RRs, spf1 only >>> SPF and TXT RRs, spf2.0 only >>> SPF and TXT RRs, spf1 and spf2.0 >>> > I think this will provide more clutter than clarity. The answer to the > over-arching question, namely "Which one has greater uptake?", is already > available without this breakdown, simply because the number of "spf2.0" > records is miniscule by comparison to the rest. Yes, but when presenting data, as in a scientifc paper, you need to be precise, so that an independent 3rd party could in principle repeat the measurement and the analysis. That's my problem with the existing tables. > So really we need to compare the use of the two RRTYPEs and the use of the > two protocols independent of the RRTYPEs, since SPF only cared about TXT > and SIDF could use either. > > Pete suggests having two tables for each survey: (a) a comparison of > RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of RRTYPE. Would > that be sufficient? Yes, I think that would be much better. I haven't seen Pete's comment but it sounds as if I would agree with it :-) Brian > > >>> It's possible that some of these are always zero but there is no way for >>> a reader >>> to tell. This relates to the breakage in the SPF transition plan that the >>> draft >>> points out (Appendix A, bullet 4). >>> >> Major issues: >> >> >> There was a significant comment about Section 3.1 during the AD >> evaluation. I'll leave it to Murray to get me the modified text to address >> this review. :-) >> > > Right; Pete had roughly the same question but he hasn't asked it on the > spfbis list yet. His suggestion is now above, for the record. :-) > > >> Finally, in Appendix A we find: >>> "Fortunately in the intervening time, the requirements for new RRTYPE >>> assignments was changed to Expert Review, and the posture has become >>> more relaxed." >>> >>> This is slightly inaccurate. Actually the policy has been changed to >>> RFC6195, which is a modified form of Expert Review. I suggest something >>> less opinionated: >>> >>> Fortunately in the intervening time, the requirements for new RRTYPE >>> assignments was changed to be less stringent [RFC6195]. >>> > OK. > > >>> Nits >>> ---- >>> >>> "9.1. Normative References >>> >>> [DNS] Mockapetris, P., "Domain names - implementation and >>> specification", STD 13, RFC 1035, November 1987. >>> >>> [PRA] Lyon, J., "Purported Responsible Address in E-Mail >>> Messages", RFC 4407, April 2006." >>> >>> Firstly, it's quite inconvenient having references like this >>> instead of [RFC1035] etc. >>> >> I'll leave it to Andrew to come up with the change to address this. :-) >> > > I concur with Andrew that this is a stylistic choice. I find the mnemonic > method in use easier to read. > > >> Secondly, it doesn't seem right to have Experimental RFCs listed >>> as normative references. In fact, since this draft is not a technical >>> specification, I'm not sure it needs to have the Normative/Informative >>> split at all. >>> >> There were some comments about the normative references (see summary at >> http://www.ietf.org/mail-**archive/web/spfbis/current/**msg01505.html ). >> I'll use that as input for the answer if there aren't any comments. >> > > I concur with Barry's reply to this point. > > -MSK > From hsantos@isdg.net Thu Jun 7 00:58:14 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 DC2D621F8661 for ; Thu, 7 Jun 2012 00:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.049 X-Spam-Level: X-Spam-Status: No, score=-102.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANxREePEEHEp for ; Thu, 7 Jun 2012 00:58:14 -0700 (PDT) Received: from dkim.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A264721F86A3 for ; Thu, 7 Jun 2012 00:58:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2465; t=1339055887; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=7A4uiNEzXFiJgPvM7PG6lerFXco=; b=KPe39T+AB8k2DEVdoaIT 6tfbuK1Ix6/enX2fMCQecImd2hlwxFoamerU62vYzbwpCyKYlT0gl4i0SfOMOvvm 55iw+MibtKJjNZRRJvl+nQWRmjGzgJkvJH35JoyLHSiluaXFKAUgcUlTvRQ18wXs nCvBWNS2AzOBSWj7ae0kzQY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 07 Jun 2012 03:58:07 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3667693180.1481.4016; Thu, 07 Jun 2012 03:58:06 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2465; t=1339055826; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JKBI5XS TPwUtUPaP9jN7mAfzgodecsblXjV5aGhAEhs=; b=yI0AEPC9qPYeDdbeZxrTLWY ijkrGtnegIc910Utuz4jr88v4+AB/lqgrdb2V9twmeDXiHMBgjK0AHnAXy4HCusA PWw6xGupBViF/n3WnHWHUhpBzg3AXEs5G9IGYZ8P/TrLEx2RNt0W7UDBv2V8TynB QZK4AZV0ApRDWqYAG/Yo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 07 Jun 2012 03:57:05 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4266558191.7.7508; Thu, 07 Jun 2012 03:57:04 -0400 Message-ID: <4FD05F2D.8010200@isdg.net> Date: Thu, 07 Jun 2012 03:58:37 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606215706.0aa1d6c0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120606215706.0aa1d6c0@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, General Area Review Team , Brian E Carpenter , draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 07:58:15 -0000 S Moonesamy wrote: >> Brian Carpenter wrote: >> Also, RFC4406 states that "Sending domains MAY publish either or both >> formats" (i.e. spf1 or spf2.0). That being so, I would ideally expect to see >> nine rows in the results table: >> >> SPF RR only, spf1 only >> SPF RR only, spf2.0 only >> SPF RR only, spf1 and spf2.0 >> TXT RR only, spf1 only >> TXT RR only, spf2.0 only >> TXT RR only, spf1 and spf2.0 >> SPF and TXT RRs, spf1 only >> SPF and TXT RRs, spf2.0 only >> SPF and TXT RRs, spf1 and spf2.0 > > Pete suggests having two tables for each survey: (a) a comparison of > RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of RRTYPE. > Would that be sufficient? I don't see where this is headed. The report was looking for something that was already there and know and I guess it trying to get a justification to eliminate something. What are we looking for? Elimination of SPF RR lookups? Elimination of SPF2.0 content in the SPF or TXT records? I hate to revert back to the original design presumptions in MARID, but everyone was working on the basis that one day DNS servers, ALL OF THEM, CROSS THE OS BOARD, would inevitably be updated to support RFC3597 Handling of Unknown DNS Resource Record (RR) Types. But that has not been the case, MS DNS 5.0 was only updated to support SVR, DNSSEC. But not the passthru query recursive requirements necessary for RFC3597. So supporting any unnamed RR type is simply not practical today. However, as predicted, the migration advice did materialize, abeit in short numbers. So IMO, we need to make a decision if its still feasible to pursue unnamed RR type support. Second and finally, the results of SPF2.0 record is irrelevant because this REPORT is not doing anything towards or does it have any business in eliminating or providing the "illusion" of eliminating Sender ID or SIDF (Sender ID Framework) which includes PRA and SUBMITTER protocol support. This Report has failed to consider the original EXPERIMENTAL questions of the so call conflicts that were cited, ones I have failed to see since its inception in early 2000s. Address the real technical issues so that deployments of many years can learn what do do with the mix support of SPF vs SIDF and also TXT vs SPF RRs. The data in this report has not provided any engineering insight whatsoever other than the fact that clients DO support both SIDF and SPF RRs. -- HLS From sm@elandsys.com Thu Jun 7 02:24:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC9F21F8675 for ; Thu, 7 Jun 2012 02:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmARrHWqpWe9 for ; Thu, 7 Jun 2012 02:24:19 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B51C821F8564 for ; Thu, 7 Jun 2012 02:24:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.116]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q579O21n022206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jun 2012 02:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339061058; i=@elandsys.com; bh=oMQYNkq0UZObChWXAxjtrYHf8QHYKakiP6+tiM+k6S4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=iy9RyZph6bEZOhhAvVoGTuPebPhtzsop8bSSdVdKxNI/Yc1vZUMEE0+eGEq1R1TiM oJKOZDXs+vLwGtp/eSrYNcsutNMR8yu+GHY6TVvMmfecPJzQQq5q1sWs12l9jVbE+a KMQxtbbqgkr62F1cblKAUkP0ufdR8N5w2ZD1S6xk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1339061058; i=@elandsys.com; bh=oMQYNkq0UZObChWXAxjtrYHf8QHYKakiP6+tiM+k6S4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ccBYKKD8YNnq1p300aq0S+arYeCIPThYEl3RzHOyLxcUT3bH/rhv4AnWLycmhWAoS 8lgE/D7lNbRnMBhy38pv/o4IIWQ/FV6yjpL69upeE/7Y9BCnLOpwN9qB80MSpTAxzx v5PaMDk4TNhwWtRbXtntlIFVFtkM8UjDpn92WsvQ= Message-Id: <6.2.5.6.2.20120607013625.085b16e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 07 Jun 2012 02:21:49 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <4FD05F2D.8010200@isdg.net> References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606215706.0aa1d6c0@elandnews.com> <4FD05F2D.8010200@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 09:24:22 -0000 Hi Hector, [Gen-ART removed from Cc as this not a Gen-ART issue in my opinion] At 00:58 07-06-2012, Hector Santos wrote: >I don't see where this is headed. The report was looking for >something that was already there and know and I guess it trying to >get a justification to eliminate something. The Responsible Area Director performed an evaluation of the draft. As the question was something which could be resolved, I suggested that to proceed with the Last Call. Any proposed changes will be brought to the attention of the SPFBIS WG for comment. I suggest waiting for the actual text before starting the discussion. >What are we looking for? > > Elimination of SPF RR lookups? > Elimination of SPF2.0 content in the SPF or TXT records? > >I hate to revert back to the original design presumptions in MARID, >but everyone was working on the basis that one day DNS servers, ALL >OF THEM, CROSS THE OS BOARD, would inevitably be updated to support >RFC3597 Handling of Unknown DNS Resource Record (RR) Types. But >that has not been the case, MS DNS 5.0 was only updated to support >SVR, DNSSEC. But not the passthru query recursive requirements >necessary for RFC3597. > >So supporting any unnamed RR type is simply not practical today. >However, as predicted, the migration advice did materialize, abeit >in short numbers. So IMO, we need to make a decision if its still >feasible to pursue unnamed RR type support. > >Second and finally, the results of SPF2.0 record is irrelevant >because this REPORT is not doing anything towards or does it have >any business in eliminating or providing the "illusion" of >eliminating Sender ID or SIDF (Sender ID Framework) which includes >PRA and SUBMITTER protocol support. > >This Report has failed to consider the original EXPERIMENTAL >questions of the so call conflicts that were cited, ones I have >failed to see since its inception in early 2000s. > >Address the real technical issues so that deployments of many years >can learn what do do with the mix support of SPF vs SIDF and also >TXT vs SPF RRs. The data in this report has not provided any >engineering insight whatsoever other than the fact that clients DO >support both SIDF and SPF RRs. The message at http://www.ietf.org/mail-archive/web/spfbis/current/msg01520.html was posted as a WGLC comment. I read it as meaning that "it works for you". I cannot tell from the above which part of draft-ietf-spfbis-experiment-09 is an issue for you. I suggest that you comment on specific text from draft-ietf-spfbis-experiment-09 if you would like to recommend any change as part of the Last Call. Please note that the Last Call ends on June 9, 2012. Regards, S. Moonesamy (as document shepherd) From barryleiba.mailing.lists@gmail.com Thu Jun 7 02:40: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 172F721F8659 for ; Thu, 7 Jun 2012 02:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.962 X-Spam-Level: X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.014, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG1Aw1qhEzi1 for ; Thu, 7 Jun 2012 02:40:03 -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 33ED421F852A for ; Thu, 7 Jun 2012 02:39:52 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so475643lbb.31 for ; Thu, 07 Jun 2012 02:39:51 -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=CtPwfqLII5OwxBxqP/8fHdAFnLT7QwdGgnPAvsOGYNA=; b=sQTuXYjJpKsUy5B1xhrk+3GTjiE4bLIJxKKhcCgOIswndysX8/IOkf2mLNz5Yy/5PK oNwcqja8FIMH5/0Nt6VV68MOUqCGYMYYT7MUM9jb8bik232G7zmZimt2ZHC80FsdM4yD aMaip19elRe4IKc/W30yKwDKMRXEVBCYGkfAPU5g7kOtzDQA3unJq5oP9ifkJfQipZp8 9B7GvA4dvULHBGnCORlSuRzg6DU3efwf1NHoWie0nncg0YGXEsBsfwNCkiMXujd7HNJ8 j1gSq2Jte63kZSLVYJ3OhZMa0NdIn87P/7v9SzCR/VbfGN0QdqDb7YQzJy9DEBoxL3Ox 6auQ== MIME-Version: 1.0 Received: by 10.112.26.131 with SMTP id l3mr987516lbg.80.1339061991138; Thu, 07 Jun 2012 02:39:51 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Thu, 7 Jun 2012 02:39:51 -0700 (PDT) In-Reply-To: References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606081749.0a94ad98@elandnews.com> Date: Thu, 7 Jun 2012 05:39:51 -0400 X-Google-Sender-Auth: NaFtNGENX2sjjyuFBFv_KmGx50o Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=bcaec55555a450640404c1deaae3 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 09:40:04 -0000 --bcaec55555a450640404c1deaae3 Content-Type: text/plain; charset=ISO-8859-1 > > > [DNS] Mockapetris, P., "Domain names - implementation and >> specification", STD 13, RFC 1035, November 1987. >> >> [PRA] Lyon, J., "Purported Responsible Address in E-Mail >> Messages", RFC 4407, April 2006." >> >> Firstly, it's quite inconvenient having references like this >> instead of [RFC1035] etc. >> > > I'll leave it to Andrew to come up with the change to address this. :-) > > I concur with Andrew that this is a stylistic choice. I find the mnemonic > method in use easier to read. For what it's worth, I find the most useful citations to be ones that BOTH tell me what the document is and how to find it, without requiring me to go to the references. For instance, up in Section 2: The term "RRTPYE" is used to refer to a Domain Name System ([DNS]) Resource Record (RR) type. I think this is more convenient for readers: The term "RRTPYE" is used to refer to a Domain Name System [RFC1035] Resource Record (RR) type. ... because it already tells me that it's about DNS, and adding the RFC number is useful. This is more obvious when you talk about, say, PRA. Suppose we had a citation to PRA at the beginning of Section 3.3, using your style: The [PRA] is the output of a heuristic (...etc...) Compare with this: The Purported Responsible Address [RFC4407] is the output (...etc...) Or even with this: The PRA [RFC4407] is the output (...etc...) That tells me both WHAT it is (PRA) *and* WHERE to find it (RFC 4407). But none of this is blocking; if you want to use the style you're using, as Andrew says, the RFC Editor does not force a style that changes that. Maybe you have a good reason to disagree with what I'm saying here. And this is, in any case, not the place to have a lengthy discussion about it. Barry --bcaec55555a450640404c1deaae3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=A0 [DNS] =A0 = =A0 =A0Mockapetris, P., "Domain names - implementation and
=A0 =A0 =A0 =A0 =A0 =A0 =A0specification", STD 13, RFC 1035, November = 1987.

=A0 [PRA] =A0 =A0 =A0Lyon, J., "Purported Responsible Add= ress in E-Mail
=A0 =A0 =A0 =A0 =A0 =A0 =A0Messages", RFC 4407, Apri= l 2006."

Firstly, it's quite inconvenient having references= like this
instead of [RFC1035] etc.

I'll leave it to Andrew t= o come up with the change to address this. :-)

>= ; I concur with Andrew that this is a stylistic choice.=A0 I find the mnemo= nic
> method in use easier to read.

For what i= t's worth, I find the most useful citations to be ones that BOTH tell m= e what the document is and how to find it, without requiring me to go to th= e references. =A0For instance, up in Section 2:

=A0 =A0The term "RRTPYE" is used to ref= er to a Domain Name System ([DNS])
=A0 =A0Resource Record (RR) ty= pe.

I think this is more convenient for readers:

=A0 =A0Th= e term "RRTPYE" is used to refer to a Domain Name System [RFC1035= ]
=A0 =A0Resource Record (RR) type.

... because it already tells me that it's about DNS, and adding the RFC= number is useful. =A0This is more obvious when you talk about, say, PRA. S= uppose we had a citation to PRA at the beginning of Section 3.3, using your= style:

=A0 =A0The [PRA] is the output of a heuristic (...etc..= .)

Compare with this:

=A0= =A0The Purported Responsible Address [RFC4407] is the output (...etc...)

Or even with this:

=A0 =A0The PRA [RFC4407] is the output (= ...etc...)

That tells me both WHAT it= is (PRA) *and* WHERE to find it (RFC 4407).

But none of this is blocking; if you want to use the st= yle you're using, as Andrew says, the RFC Editor does not force a style= that changes that. Maybe you have a good reason to disagree with what I= 9;m saying here. =A0And this is, in any case, not the place to have a lengt= hy discussion about it.

Barry

=
--bcaec55555a450640404c1deaae3-- From brian.e.carpenter@gmail.com Thu Jun 7 06:28: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 6472321F8702; Thu, 7 Jun 2012 06:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.661 X-Spam-Level: X-Spam-Status: No, score=-101.661 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8bORCiq3DiL; Thu, 7 Jun 2012 06:28:13 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD0421F8700; Thu, 7 Jun 2012 06:28:12 -0700 (PDT) Received: by eekd4 with SMTP id d4so283977eek.31 for ; Thu, 07 Jun 2012 06:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/ENRrTyPclIPcdzvqrUrdD2jUNnIRIHcxnaCh5M/El4=; b=wU3A5Lg471CriDNnhm+p4zUpVyAKUapnr17FuUV4v+S5WNYUuOn2jbAPcN4wL0ciJs rgf9yqNl6M8Xjh51Atx/HeGl3STLJuOT+lg4HRtFkYX0jgQ+pTteHDhwZP0afgsUN3W1 cZhKopPT9/bcBolZ4hgQm7UDXDeXk3KlCvGLntQNKR6oijM+EKMmdc3IVSATb+qXAFwg yzGe1Xp0xqYkoStBt5MTcYGtBnhkn+TIU6ARXO3KWHGgZsfRJp4D1ol68V3EaRSyL2kd 3NQq8JYwl7Bq37eM1rcizNH/45tfw/EbpUdT0W/jlR2UW1VBmctV3h8f2tdJdaG7749h uPgw== Received: by 10.14.189.14 with SMTP id b14mr1233236een.141.1339075691501; Thu, 07 Jun 2012 06:28:11 -0700 (PDT) Received: from [192.168.1.66] (host-2-102-217-102.as13285.net. [2.102.217.102]) by mx.google.com with ESMTPS id m5sm10884565eeh.17.2012.06.07.06.28.09 (version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 06:28:10 -0700 (PDT) Message-ID: <4FD0AC66.50602@gmail.com> Date: Thu, 07 Jun 2012 14:28:06 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hector Santos References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606215706.0aa1d6c0@elandnews.com> <4FD05F2D.8010200@isdg.net> In-Reply-To: <4FD05F2D.8010200@isdg.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 Jun 2012 07:53:31 -0700 Cc: spfbis@ietf.org, General Area Review Team , S Moonesamy , draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 13:28:13 -0000 On 2012-06-07 08:58, Hector Santos wrote: > S Moonesamy wrote: > >>> Brian Carpenter wrote: >>> Also, RFC4406 states that "Sending domains MAY publish either or both >>> formats" (i.e. spf1 or spf2.0). That being so, I would ideally expect >>> to see nine rows in the results table: >>> >>> SPF RR only, spf1 only >>> SPF RR only, spf2.0 only >>> SPF RR only, spf1 and spf2.0 >>> TXT RR only, spf1 only >>> TXT RR only, spf2.0 only >>> TXT RR only, spf1 and spf2.0 >>> SPF and TXT RRs, spf1 only >>> SPF and TXT RRs, spf2.0 only >>> SPF and TXT RRs, spf1 and spf2.0 >> >> Pete suggests having two tables for each survey: (a) a comparison of >> RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of RRTYPE. >> Would that be sufficient? > > I don't see where this is headed. The report was looking for something > that was already there and know and I guess it trying to get a > justification to eliminate something. > > What are we looking for? I am looking for clear presentation of the observed data, nothing more, as I do whenever I read a data-based document. As my review stated, I have no problem with the conclusions drawn in the draft. Brian > > Elimination of SPF RR lookups? > Elimination of SPF2.0 content in the SPF or TXT records? > > I hate to revert back to the original design presumptions in MARID, but > everyone was working on the basis that one day DNS servers, ALL OF THEM, > CROSS THE OS BOARD, would inevitably be updated to support RFC3597 > Handling of Unknown DNS Resource Record (RR) Types. But that has not > been the case, MS DNS 5.0 was only updated to support SVR, DNSSEC. But > not the passthru query recursive requirements necessary for RFC3597. > > So supporting any unnamed RR type is simply not practical today. > However, as predicted, the migration advice did materialize, abeit in > short numbers. So IMO, we need to make a decision if its still feasible > to pursue unnamed RR type support. > > Second and finally, the results of SPF2.0 record is irrelevant because > this REPORT is not doing anything towards or does it have any business > in eliminating or providing the "illusion" of eliminating Sender ID or > SIDF (Sender ID Framework) which includes PRA and SUBMITTER protocol > support. > > This Report has failed to consider the original EXPERIMENTAL questions > of the so call conflicts that were cited, ones I have failed to see > since its inception in early 2000s. > > Address the real technical issues so that deployments of many years can > learn what do do with the mix support of SPF vs SIDF and also TXT vs > SPF RRs. The data in this report has not provided any engineering > insight whatsoever other than the fact that clients DO support both SIDF > and SPF RRs. > From vesely@tana.it Thu Jun 7 09:41:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E09721F865F for ; Thu, 7 Jun 2012 09:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6lUU0jevQnw for ; Thu, 7 Jun 2012 09:41:07 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F3FC721F8671 for ; Thu, 7 Jun 2012 09:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1339087265; bh=f4ffxRgBnbVEmxxkoQi60Zm7QDkf5znX/iXFvUij4ZI=; l=675; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Lxpv3lnn3Fo3hkpuXJKTzKGF22eyhrUHE+hCO3rVVqJbgDhacpwqLVq1er9QnrBie OWoiShdKNmWMt84HShS2OTcm66rzXb4ziej1zGrBKykbPu0/W8qam9Lsu8czRT8+t5 t8V9bHO5ihzK8gUxr3v3W+vBxTqFs1mGoNx++9wY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 07 Jun 2012 18:41:05 +0200 id 00000000005DC033.000000004FD0D9A1.0000021B Message-ID: <4FD0D9A0.90109@tana.it> Date: Thu, 07 Jun 2012 18:41:04 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606215706.0aa1d6c0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120606215706.0aa1d6c0@elandnews.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 16:41:08 -0000 Ooops, re-posting... On Thu 07/Jun/2012 07:28:40 +0200 S Moonesamy wrote: >> Does "SPF+TXT replies" mean that both an SPF and a TXT record exists >> for these FQDNs? If so, are they identical? (Presumably they should be.) > > Yes to the first question. The working group didn't evaluate the second. Actually, Philip evaluated the second question as well, mentioning that some 17% of type99 records differ from the corresponding type16. http://www.ietf.org/mail-archive/web/spfbis/current/msg00354.html FWIW, I repeated a similar test for 24,853 domains in the DNSWL list, and found that only 3% of the 587 domains that use both types had such difference. From presnick@qualcomm.com Sat Jun 9 08:29: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 C757421F884C; Sat, 9 Jun 2012 08:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.32 X-Spam-Level: X-Spam-Status: No, score=-106.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b32DEjHAnBs6; Sat, 9 Jun 2012 08:29:43 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0644B21F884E; Sat, 9 Jun 2012 08:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1339255782; x=1370791782; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; bh=o7j3t5LDSOiaYc9iTC/8yz+Pbz6zrvUWIw1cqPBgF14=; b=XWomJ3W392N+AWtyot9XguUmnpfgILoURAsK/t63TFCGr9C11BzX7tj6 ZU5p3cy2kNsxyyeWtMkABjjX+IrCiMZ5I4dSrcL0rq4pzqlP3hnvv8jJJ 2uusO1XWizBgWa/dK88WeREG1hJhmwvuqXsx+tOLvLc4nx7MqKQH23GTC w=; X-IronPort-AV: E=McAfee;i="5400,1158,6736"; a="197130514" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 09 Jun 2012 08:29:38 -0700 X-IronPort-AV: E=Sophos;i="4.75,741,1330934400"; d="scan'208";a="263793785" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Jun 2012 08:29:38 -0700 Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.283.3; Sat, 9 Jun 2012 08:29:37 -0700 Message-ID: <4FD36BDE.5010502@qualcomm.com> Date: Sat, 9 Jun 2012 10:29:34 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Brian E Carpenter References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606215706.0aa1d6c0@elandnews.com> <4FD05F2D.8010200@isdg.net> <4FD0AC66.50602@gmail.com> In-Reply-To: <4FD0AC66.50602@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, General Area Review Team , Hector Santos , S Moonesamy , draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 15:29:43 -0000 Brian, On 6/7/12 8:28 AM, Brian E Carpenter wrote: >> S Moonesamy wrote: >> >> >>>> Brian Carpenter wrote: >>>> Also, RFC4406 states that "Sending domains MAY publish either or both >>>> formats" (i.e. spf1 or spf2.0). That being so, I would ideally expect >>>> to see nine rows in the results table: >>>> >>>> SPF RR only, spf1 only >>>> SPF RR only, spf2.0 only >>>> SPF RR only, spf1 and spf2.0 >>>> TXT RR only, spf1 only >>>> TXT RR only, spf2.0 only >>>> TXT RR only, spf1 and spf2.0 >>>> SPF and TXT RRs, spf1 only >>>> SPF and TXT RRs, spf2.0 only >>>> SPF and TXT RRs, spf1 and spf2.0 >>>> >>> Pete suggests having two tables for each survey: (a) a comparison of >>> RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of RRTYPE. >>> Would that be sufficient? >>> > I am looking for clear presentation of the observed data, nothing more, > as I do whenever I read a data-based document. As my review stated, > I have no problem with the conclusions drawn in the draft. > I'm afraid you got distracted by Hector's question and didn't answer SM's. Please do. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From brian.e.carpenter@gmail.com Sat Jun 9 08:35: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 48DF221F864C; Sat, 9 Jun 2012 08:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNjF-s186ncE; Sat, 9 Jun 2012 08:35:34 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4431C21F864D; Sat, 9 Jun 2012 08:35:34 -0700 (PDT) Received: by eekd4 with SMTP id d4so2076392eek.31 for ; Sat, 09 Jun 2012 08:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BuPPQWkfJPYWwxSkDyhNvHzqblzX2oQVensQL4tJ6pE=; b=LjGaUh8UJ1N1jwfHiufT0j6lLikf+YZSjNBCKd92uY4tp2Sdr/UvR2c+zMgzUTamWM dTKAggtswNPQap1V80naRzzOJeacBuPZ+UjBjc0+699B56JOj5TrBiqtk99+piHJ9ZHy +kQiyxHuoAu3a83Fgb/ld3WqYSLUHfJm+x28m9q+tMod6mnl3e8czpHkc4YAJCY0nHVW eVvZiQMjHoBM9VltxM/pkoWyQkVWS9EO1sDezvEZfjd3M1JXhynwfqTd0FNDlmb3zTaa UVc3jJnUSnL64pJQRPjFkkpsakpFsdUA0YMzTlooj1oO8AHCi1ERr/YKNDEiAkn1AeZ7 H4Bg== Received: by 10.14.127.130 with SMTP id d2mr4989554eei.82.1339256133424; Sat, 09 Jun 2012 08:35:33 -0700 (PDT) Received: from [192.168.1.68] (host-2-101-189-72.as13285.net. [2.101.189.72]) by mx.google.com with ESMTPS id q53sm33294846eef.8.2012.06.09.08.35.31 (version=SSLv3 cipher=OTHER); Sat, 09 Jun 2012 08:35:32 -0700 (PDT) Message-ID: <4FD36D42.2080308@gmail.com> Date: Sat, 09 Jun 2012 16:35:30 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pete Resnick References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606215706.0aa1d6c0@elandnews.com> <4FD05F2D.8010200@isdg.net> <4FD0AC66.50602@gmail.com> <4FD36BDE.5010502@qualcomm.com> In-Reply-To: <4FD36BDE.5010502@qualcomm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 09 Jun 2012 13:28:46 -0700 Cc: spfbis@ietf.org, General Area Review Team , Hector Santos , S Moonesamy , draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 15:35:35 -0000 Hi Pete, On 2012-06-09 16:29, Pete Resnick wrote: > Brian, > > On 6/7/12 8:28 AM, Brian E Carpenter wrote: > >>> S Moonesamy wrote: >>> >>> >>>>> Brian Carpenter wrote: >>>>> Also, RFC4406 states that "Sending domains MAY publish either or both >>>>> formats" (i.e. spf1 or spf2.0). That being so, I would ideally expect >>>>> to see nine rows in the results table: >>>>> >>>>> SPF RR only, spf1 only >>>>> SPF RR only, spf2.0 only >>>>> SPF RR only, spf1 and spf2.0 >>>>> TXT RR only, spf1 only >>>>> TXT RR only, spf2.0 only >>>>> TXT RR only, spf1 and spf2.0 >>>>> SPF and TXT RRs, spf1 only >>>>> SPF and TXT RRs, spf2.0 only >>>>> SPF and TXT RRs, spf1 and spf2.0 >>>>> >>>> Pete suggests having two tables for each survey: (a) a comparison of >>>> RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of RRTYPE. >>>> Would that be sufficient? >>>> >> I am looking for clear presentation of the observed data, nothing more, >> as I do whenever I read a data-based document. As my review stated, >> I have no problem with the conclusions drawn in the draft. >> > > I'm afraid you got distracted by Hector's question and didn't answer > SM's. Please do. Sorry - yes, I think those two tables would be fine. Brian From superuser@gmail.com Sun Jun 10 14:14:21 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 1F46B21F8549; Sun, 10 Jun 2012 14:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT9MMPZsWDxr; Sun, 10 Jun 2012 14:14:20 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 306A221F8547; Sun, 10 Jun 2012 14:14:19 -0700 (PDT) Received: by lagv3 with SMTP id v3so3620995lag.31 for ; Sun, 10 Jun 2012 14:14:19 -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=AOJaObAvZFyrf059XhpnzTzogyAi7lN0ubtIXZi9tM0=; b=d+TREdMuv44HjmNLSdPamdWXro114wXQcaASE2DFod7OqQRcX6bl9h/OChKkVA1Mhf 82AlRD1Oxyac57GgLQfMjfKRo3WVhKqCl6nc/TXjaWpWIDLZxE5X5N+PakshX8mg3eje V7ge6+42MBAt6XvXuIo1e56nEuygoNWqR24ddYj1B5f6bRT/n5Uk1nhEWeGVGxyDhm2T WZtX3ko2j1eGokK3DKTmgLzCFiJ7nIcddmQsanTDh/28nkvsF4dRWLl/APJhRZqnuQXj lD8YFAUsh/D0RPyaThUBYqPXHOcycjCRmoVUhTvQVhY1T8oQ3QJGjGTeYZZ0UjXu4c+g t3XQ== MIME-Version: 1.0 Received: by 10.112.84.168 with SMTP id a8mr2270633lbz.92.1339362858995; Sun, 10 Jun 2012 14:14:18 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sun, 10 Jun 2012 14:14:18 -0700 (PDT) In-Reply-To: <4FD36D42.2080308@gmail.com> References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606215706.0aa1d6c0@elandnews.com> <4FD05F2D.8010200@isdg.net> <4FD0AC66.50602@gmail.com> <4FD36BDE.5010502@qualcomm.com> <4FD36D42.2080308@gmail.com> Date: Sun, 10 Jun 2012 14:14:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Brian E Carpenter , spfbis@ietf.org Content-Type: multipart/alternative; boundary=f46d04016cad6f911004c224b72e Cc: General Area Review Team Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 21:14:21 -0000 --f46d04016cad6f911004c224b72e Content-Type: text/plain; charset=ISO-8859-1 I have a revised version with the requested changes stuck in submission tool limbo. I'll get it posted as soon as the Secretariat can fix it. -MSK --f46d04016cad6f911004c224b72e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have a revised version with the requested changes stuck in submission too= l limbo.=A0 I'll get it posted as soon as the Secretariat can fix it.
-MSK
=A0 --f46d04016cad6f911004c224b72e-- From ajs@anvilwalrusden.com Mon Jun 11 09:07:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238C021F854C for ; Mon, 11 Jun 2012 09:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp-iwhcY-jOI for ; Mon, 11 Jun 2012 09:07:43 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 364AB21F8543 for ; Mon, 11 Jun 2012 09:07:43 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2C6C91ECB41C for ; Mon, 11 Jun 2012 16:07:42 +0000 (UTC) Date: Mon, 11 Jun 2012 12:07:40 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120611160740.GL11684@crankycanuck.ca> 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] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:07:44 -0000 Dear colleagues, Now that the document concluding the SPF experiment is well on its way to publication, it is time for the WG to turn its attention to our other chartered work item: a standards-track document for SPF. Note that an IPR disclosure ( https://datatracker.ietf.org/ipr/1698/ ) has been filed for RFC 4408. We would like the working group to consider adopting draft-kitterman-4408bis as the basis for such a specification. As the charter explicitly mentions that draft as a possible basis for work, it is the presumptive candidate for adoption. If you have any objections against adoption of the draft please send them to the mailing list before 18 June. Please include an outline of what the alternative draft will be like or an alternative draft. If there is such an objection, we will wait one additional week for that alternative draft to materialize before taking a decision. The date, 18 June, gives us one month prior to the date for WG agendas to be posted for Vancouver. We have requested a 30 minute meeting slot in Vancouver. If by 18 July we do not seem to have any need for further discussion in Vancouver, we will cede the time. Best regards, SM & AS -- Andrew Sullivan ajs@anvilwalrusden.com From internet-drafts@ietf.org Mon Jun 11 09:31:07 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 DD6B521F8644; Mon, 11 Jun 2012 09:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lr6Ws1JNAB+n; Mon, 11 Jun 2012 09:31:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6701D21F85CC; Mon, 11 Jun 2012 09:31:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120611163106.27409.48335.idtracker@ietfa.amsl.com> Date: Mon, 11 Jun 2012 09:31:06 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-10.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:31:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Resolution of The SPF and Sender ID Experiments Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-10.txt Pages : 12 Date : 2012-06-11 In 2006 the IETF published a suite of protocol documents comprising SPF and Sender ID, two proposed email authentication protocols. Both of these protocols enable one to publish via the Domain Name System a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required the publication of all of these documents (RFC4405, RFC4406, RFC4407, and RFC4408) with Experimental status, and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment/ From spf2@kitterman.com Mon Jun 11 09:54:50 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 0316121F862A for ; Mon, 11 Jun 2012 09:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYQhtsPc5fM7 for ; Mon, 11 Jun 2012 09:54:49 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE6A21F84BF for ; Mon, 11 Jun 2012 09:54:49 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5E42B20E40BD; Mon, 11 Jun 2012 12:54:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1339433688; bh=/I16O1CbClyqtz3tBXIllcFUt1xrZy7TR6bVYgKqSqQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=kkVKaY/4QwMzuiJ+8VOxI91a7uhS4+W3C2Hywi7Udy7ATiXCKEbPh+q0DLb1KXlQo Bk8oy6au+KHg/VHiVgaC4P+bO5vAbOZhnUMI2Shebo46/pmD1HyOHmJ3UR+ZH5P7wh gkHaN9dKIadMe9OKOLCw1iHbW8jtOlAtHeAB8MAk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 412D520E409D; Mon, 11 Jun 2012 12:54:48 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 11 Jun 2012 12:54:47 -0400 Message-ID: <1554302.cmKEOW5Xd3@scott-latitude-e6320> User-Agent: KMail/4.8.3 (Linux/3.2.0-24-generic-pae; KDE/4.8.3; i686; ; ) In-Reply-To: <20120611160740.GL11684@crankycanuck.ca> References: <20120611160740.GL11684@crankycanuck.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:54:50 -0000 On Monday, June 11, 2012 12:07:40 PM Andrew Sullivan wrote: > Dear colleagues, > > Now that the document concluding the SPF experiment is well on its way > to publication, it is time for the WG to turn its attention to our > other chartered work item: a standards-track document for SPF. Note > that an IPR disclosure ( https://datatracker.ietf.org/ipr/1698/ ) has > been filed for RFC 4408. > > We would like the working group to consider adopting > draft-kitterman-4408bis as the basis for such a specification. As the > charter explicitly mentions that draft as a possible basis for work, > it is the presumptive candidate for adoption. The draft is currently expired. I'll publish a revision today or tomorrow to get it unexpired. Scott K From WebMaster@Commerco.Net Mon Jun 11 11:38:52 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 69C7B21F857F for ; Mon, 11 Jun 2012 11:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtPt-N-3oIcY for ; Mon, 11 Jun 2012 11:38:52 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id C497D21F856D for ; Mon, 11 Jun 2012 11:38:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=TeCZqhz+FI6wynxseXYIAFzuQRw87jTz31KIWVDTPHnjKbBTutHF8hZ1dEGni4AtNpka2irXdl8mMo3EHbCNr0CrqWyk0m+35uUE8W0Sg5O/012lEGt9PtixzsAFXN5I9x4ZphDpunsghJVwZrBvyY4acmpBFUCRGQPaUXF2pvE= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Mon, 11 Jun 2012 18:38:49 +0000 Message-ID: <4FD63B33.3020000@Commerco.Net> Date: Mon, 11 Jun 2012 12:38:43 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120611160740.GL11684@crankycanuck.ca> In-Reply-To: <20120611160740.GL11684@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 18:38:52 -0000 Makes sense, thank you for moving the process forward. +1 Alan M On 6/11/2012 10:07 AM, Andrew Sullivan wrote: > Dear colleagues, > > Now that the document concluding the SPF experiment is well on its way > to publication, it is time for the WG to turn its attention to our > other chartered work item: a standards-track document for SPF. Note > that an IPR disclosure ( https://datatracker.ietf.org/ipr/1698/ ) has > been filed for RFC 4408. > > We would like the working group to consider adopting > draft-kitterman-4408bis as the basis for such a specification. As the > charter explicitly mentions that draft as a possible basis for work, > it is the presumptive candidate for adoption. > > If you have any objections against adoption of the draft please send > them to the mailing list before 18 June. Please include an outline of > what the alternative draft will be like or an alternative draft. If > there is such an objection, we will wait one additional week for that > alternative draft to materialize before taking a decision. > > The date, 18 June, gives us one month prior to the date for WG agendas > to be posted for Vancouver. We have requested a 30 minute meeting > slot in Vancouver. If by 18 July we do not seem to have any need for > further discussion in Vancouver, we will cede the time. > > Best regards, > > SM& AS > From superuser@gmail.com Mon Jun 11 15:26:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7963121F8534 for ; Mon, 11 Jun 2012 15:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.041 X-Spam-Level: X-Spam-Status: No, score=-3.041 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9+sDwraygVp for ; Mon, 11 Jun 2012 15:26:59 -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 A44C721F8532 for ; Mon, 11 Jun 2012 15:26:58 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4753806lbb.31 for ; Mon, 11 Jun 2012 15:26:57 -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=+hIyAUn7liDDvbYopayH5HFwpuvxknrbHOqL//sxQas=; b=IRSEj1hUTLPC1fm4LgLYiW7l3qAWCmoaDXK8noxcZbXqfdEGE//QsXDh9Wk4sbzu2+ VNToU+FXB+WNoFh9OfnCEa9riVdI1DlX+dbU5ZUoExXmCQ7MtmcHm0XUoMk04V6rJcY+ CpE5T6D8iMZZ/pdCqII2x7gSJFVrz81AwFz8YA88AjZKStgI30TVlpSxND31cSpEcAXz bAfwle2HE8MWs17F4eYERzGuImyvLRkhvYv/ISj48RN9pm/u8cWXhS0FDkROADKtRn6j 4Rop05U5U4RgsAUHVei2/zY25/1GAMNUsCbxIgBGgDrGALXxShvJDCDsSDSzzfeXBu97 pc9w== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr18533554lab.47.1339453617385; Mon, 11 Jun 2012 15:26:57 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 11 Jun 2012 15:26:57 -0700 (PDT) In-Reply-To: <20120611160740.GL11684@crankycanuck.ca> References: <20120611160740.GL11684@crankycanuck.ca> Date: Mon, 11 Jun 2012 15:26:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=f46d0435c1d20eb23f04c239d93a Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 22:26:59 -0000 --f46d0435c1d20eb23f04c239d93a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 11, 2012 at 9:07 AM, Andrew Sullivan wrote: > Dear colleagues, > > Now that the document concluding the SPF experiment is well on its way > to publication, it is time for the WG to turn its attention to our > other chartered work item: a standards-track document for SPF. Note > that an IPR disclosure ( https://datatracker.ietf.org/ipr/1698/ ) has > been filed for RFC 4408. > [...] > > I support adoption of that document. -MSK --f46d0435c1d20eb23f04c239d93a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jun 11, 2012 at 9:07 AM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
Dear colleagues,

Now that the document concluding the SPF experiment is well on its way
to publication, it is time for the WG to turn its attention to our
other chartered work item: a standards-track document for SPF. =A0Note
that an IPR disclosure ( https://datatracker.ietf.org/ipr/1698/ ) has
been filed for RFC 4408.
[...]


I support adoption of that document.
=
-MSK

--f46d0435c1d20eb23f04c239d93a-- From hsantos@isdg.net Mon Jun 11 21:03: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 8DD2511E809C for ; Mon, 11 Jun 2012 21:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oqAaI6E7hf3 for ; Mon, 11 Jun 2012 21:03:02 -0700 (PDT) Received: from groups.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8946811E8087 for ; Mon, 11 Jun 2012 21:03:02 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2386; t=1339473775; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=PguZ8eH/RNLHV9pbfiC83msuXHs=; b=J80/rAu6zx6LOmiNguR/ so1/3qFkB9SEcV0NyoTgCQghb7vxLjBxqKpf2M3DaUOi+vVGtscCmIySNU0kdKyi KD8tAzIpAmF6aU/FENLuK5k9Fe/O2Wpk4BSxa9YToAplAXh6Sqk7lYTq6nqKIMeV 3Ts+k9PzEAg8tkohUUy53BY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 12 Jun 2012 00:02:55 -0400 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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4085577083.545.5972; Tue, 12 Jun 2012 00:02:54 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2386; t=1339473708; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pQRuOyi HWi3N8tmcL/+DMrT5vbcmhFRO3v1gcyG/Leg=; b=yJoTlxuPaLVZuQEP/lhsnoZ N5wCerD7qpAWgjS6UAMVAi1t26DeuQHZnEOzHSdVoJwlBpDA7vFF1v60lqJuyH0P nOUSKbDk4cSH5+0beXfGGoXcWU9tmhcvRkKxLrMnRQY9HnpDelrOlx9ovhJio2Lj A8Zf71ELmJaCCI7JlaYg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 12 Jun 2012 00:01:48 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 389472910.9.2928; Tue, 12 Jun 2012 00:01:46 -0400 Message-ID: <4FD6BF7C.9000306@isdg.net> Date: Tue, 12 Jun 2012 00:03:08 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andrew Sullivan References: <20120611160740.GL11684@crankycanuck.ca> In-Reply-To: <20120611160740.GL11684@crankycanuck.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 04:03:03 -0000 Andrew Sullivan wrote: > We would like the working group to consider adopting > draft-kitterman-4408bis as the basis for such a specification. As the > charter explicitly mentions that draft as a possible basis for work, > it is the presumptive candidate for adoption. +1, make sense. > If you have any objections against adoption of the draft please send > them to the mailing list before 18 June. Please include an outline of > what the alternative draft will be like or an alternative draft. If > there is such an objection, we will wait one additional week for that > alternative draft to materialize before taking a decision. I don't think we need a major change. Three items come to mind: 1) Focus is a consolidation of concepts and functionality currently peppered throughout of the docs. 2) Opportunity to bring positive engineering conclusion to the "experimental" is an ideal document that considered the total SPF spectrum - the reality. References are good enough, but I thought the single integrated piece - SUBMITTER as part of the check_host() function. This was proposed in issue #4 http://tools.ietf.org/wg/spfbis/trac/ticket/4 which seems to me to be mysteriously CLOSED for some reason. It seems all presumptuous without proper realistic integrated considerations. I hope you can understand ISSUE #4 should be reopen for a proper integrated SPF implementation engineering design consideration. Look at it this way, you can't ignore it and in the reality, implementations check_host() will be more than just two inputs, so at the very least, a text change to point that out is necessary. 3) To avoid high potential conflicts, draft-kitterman-4408bis has to start by removing talk about DKIM: In the interval since that statement, DKIM (see [RFC4871] was developed and achieved wide deployment. Both Sender ID (as the protocol defined in RFC 4405, RFC 4406, and RFC 4407 was named) and DKIM target "message content", as described in [RFC5598], while SPF targets the "transit-handling envelope". The success or failure of the Sender ID portion of this IESG experiment should be evaluated relative to DKIM. DKIM is not SPF - two different models of reputation vs deterministic methods, respectively. Such integration needs to be done outside the SPF framework and specification. Thanks -- HLS From spf2@kitterman.com Mon Jun 11 21:08:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE3A11E8087 for ; Mon, 11 Jun 2012 21:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D66Cqvbd1RzA for ; Mon, 11 Jun 2012 21:08:43 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADC011E809B for ; Mon, 11 Jun 2012 21:08:43 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3448A20E40BD; Tue, 12 Jun 2012 00:08:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1339474121; bh=TAOGCJBGm9MRr3nQd4Mq5Z85fhEzIwzI4n46oCthWoU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=bhJHe410y9wv3TojfbbD0lfmkz90boa/ul6ZYSVDpM6Loizs2APg0CSxViFpEtg9g TKmdSAxyh9vBfrHJWqqejp5kNm8E8SI597Ofy4WGEe+lUbN0sx8NietHWexbhSAAAl YgrOXBoGlqja7Nf6Yi1AwtXtBXH3st0CgmiPKzU4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1505420E409D; Tue, 12 Jun 2012 00:08:40 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 12 Jun 2012 00:08:40 -0400 Message-ID: <25275332.sOUTd2vrt5@scott-latitude-e6320> User-Agent: KMail/4.8.3 (Linux/3.2.0-24-generic-pae; KDE/4.8.3; i686; ; ) In-Reply-To: <4FD6BF7C.9000306@isdg.net> References: <20120611160740.GL11684@crankycanuck.ca> <4FD6BF7C.9000306@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 04:08:44 -0000 On Tuesday, June 12, 2012 12:03:08 AM Hector Santos wrote: > 3) To avoid high potential conflicts, draft-kitterman-4408bis has to > start by removing talk about DKIM: > > In the interval since that statement, DKIM (see [RFC4871] was > developed and achieved wide deployment. Both Sender ID (as the > protocol defined in RFC 4405, RFC 4406, and RFC 4407 was named) and > DKIM target "message content", as described in [RFC5598], while SPF > targets the "transit-handling envelope". The success or failure of > the Sender ID portion of this IESG experiment should be evaluated > relative to DKIM. > > DKIM is not SPF - two different models of reputation vs deterministic > methods, respectively. Such integration needs to be done outside the > SPF framework and specification. The separate draft the resolved the end of the so called experiments didn't exist when I wrote that. It's OBE by that draft, so it'll go away. Don't worry about it. Scott K From brian.e.carpenter@gmail.com Tue Jun 12 00:36:39 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 D1ED421F85AF; Tue, 12 Jun 2012 00:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.136 X-Spam-Level: X-Spam-Status: No, score=-101.136 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TRVgJSF572R; Tue, 12 Jun 2012 00:36:39 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEC9621F850D; Tue, 12 Jun 2012 00:36:38 -0700 (PDT) Received: by eaaq13 with SMTP id q13so2903193eaa.31 for ; Tue, 12 Jun 2012 00:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CDITGxRyHThtw7EmEr1FuE4AopLFoGb2pCk6HpEIz64=; b=W0f+dKzT/WiL25xdPjDjDRUFkuOp/LSJqfp4SxYE7Tn21b/Guclb2mQYWt3cpJWN3c bcSqSTJsrrYFqgMovk4dvGPxfSOeWMSaY6dveWEKsZFaUyZinp0HK9wfLuIuB6Miozh8 jOweCPKbuG6FcaY/lnhyi8XAYtlSG5sqSIHHrCKC116m5uK3lHos2R4MhoHDqBi+sfma luiX5uj7nP4htdbT2KyXIM7KLiR4zCckmMzVw3Gv8AkIGiM4LGMqYTft80EaLBFDNGw4 6awYoz79WHo6UMfRlbHg4UieCTkoQO4g0DKH3h9nK+Ww3mYuBY4tz1LmVgzV0xcg4kZ6 Nz6w== Received: by 10.14.37.12 with SMTP id x12mr6523552eea.161.1339486597862; Tue, 12 Jun 2012 00:36:37 -0700 (PDT) Received: from [192.168.1.67] (host-2-102-219-50.as13285.net. [2.102.219.50]) by mx.google.com with ESMTPS id p41sm61059430eef.5.2012.06.12.00.36.35 (version=SSLv3 cipher=OTHER); Tue, 12 Jun 2012 00:36:37 -0700 (PDT) Message-ID: <4FD6F180.8010401@gmail.com> Date: Tue, 12 Jun 2012 08:36:32 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: General Area Review Team References: <4FCF32B5.7010102@gmail.com> <6.2.5.6.2.20120606215706.0aa1d6c0@elandnews.com> <4FD05F2D.8010200@isdg.net> <4FD0AC66.50602@gmail.com> <4FD36BDE.5010502@qualcomm.com> <4FD36D42.2080308@gmail.com> In-Reply-To: <4FD36D42.2080308@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 12 Jun 2012 00:44:05 -0700 Cc: Pete Resnick , spfbis@ietf.org, S Moonesamy , draft-ietf-spfbis-experiment.all@tools.ietf.org Subject: Re: [spfbis] Gen-ART LC review of draft-ietf-spfbis-experiment-09.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 07:36:40 -0000 I've looked at the changes in the -10 version, and it's much clearer to me, thanks. If I'm asked to review it again it will be "Ready". Regards Brian On 2012-06-09 16:35, Brian E Carpenter wrote: > Hi Pete, > > On 2012-06-09 16:29, Pete Resnick wrote: >> Brian, >> >> On 6/7/12 8:28 AM, Brian E Carpenter wrote: >> >>>> S Moonesamy wrote: >>>> >>>> >>>>>> Brian Carpenter wrote: >>>>>> Also, RFC4406 states that "Sending domains MAY publish either or both >>>>>> formats" (i.e. spf1 or spf2.0). That being so, I would ideally expect >>>>>> to see nine rows in the results table: >>>>>> >>>>>> SPF RR only, spf1 only >>>>>> SPF RR only, spf2.0 only >>>>>> SPF RR only, spf1 and spf2.0 >>>>>> TXT RR only, spf1 only >>>>>> TXT RR only, spf2.0 only >>>>>> TXT RR only, spf1 and spf2.0 >>>>>> SPF and TXT RRs, spf1 only >>>>>> SPF and TXT RRs, spf2.0 only >>>>>> SPF and TXT RRs, spf1 and spf2.0 >>>>>> >>>>> Pete suggests having two tables for each survey: (a) a comparison of >>>>> RRTYPEs, and (b) a comparison of SPF vs. SIDF independent of RRTYPE. >>>>> Would that be sufficient? >>>>> >>> I am looking for clear presentation of the observed data, nothing more, >>> as I do whenever I read a data-based document. As my review stated, >>> I have no problem with the conclusions drawn in the draft. >>> >> I'm afraid you got distracted by Hector's question and didn't answer >> SM's. Please do. > > Sorry - yes, I think those two tables would be fine. > > Brian > From vesely@tana.it Tue Jun 12 00:46: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 729D721F85CD for ; Tue, 12 Jun 2012 00:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vInaP9gbZAjv for ; Tue, 12 Jun 2012 00:46:31 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACFE21F85C5 for ; Tue, 12 Jun 2012 00:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1339487190; bh=0sn6lbf+b1KUyGoIC5zlsLfXXFLQ9RigZevAmvILz4w=; l=2164; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=dn0fwFv9tOLRF4vjWxaq+YRNIYFqTdGETr4iA5Fu5UTkyTLgJ6Jl8E6xn5plxGhCu JlBsz/9oMv4/hfn407vicNY7oCM0gtFKv4HhhH4N3uVGBu9bmRfuZWFXX3Ld1OYQxF Yfbov4Nddr8k6eEtl0XK0mEryuRslgLGhWBZaEao= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 12 Jun 2012 09:46:29 +0200 id 00000000005DC033.000000004FD6F3D5.00006C1F Message-ID: <4FD6F3D5.4030107@tana.it> Date: Tue, 12 Jun 2012 09:46:29 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120611160740.GL11684@crankycanuck.ca> In-Reply-To: <20120611160740.GL11684@crankycanuck.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 07:46:32 -0000 On Mon 11/Jun/2012 18:07:40 +0200 Andrew Sullivan wrote: > > Now that the document concluding the SPF experiment is well on its way > to publication, it is time for the WG to turn its attention to our > other chartered work item: a standards-track document for SPF. Note > that an IPR disclosure ( https://datatracker.ietf.org/ipr/1698/ ) has > been filed for RFC 4408. Is this because there /has/ to be an IPR? (Otherwise, I don't understand why that patent would concern SPF, given that the referenced IPR 434 was related to Sender ID only.) > We would like the working group to consider adopting > draft-kitterman-4408bis as the basis for such a specification. As the > charter explicitly mentions that draft as a possible basis for work, > it is the presumptive candidate for adoption. I'd like to note explicitly that, except for some minor changes, that I-D matches the current RFC 4408. I have nothing against adoption, but the proposed I-D is nowhere near WGLC and there are many issues that need to be addressed. To mention a nit, I would s/E-Mail/email/ as per RFC Editor style guide http://www.rfc-editor.org/rfc-style-guide/terms-online.txt As for the experimental status, the IESG note mentions "there are serious open issues", while our document seems to aim at closing the experiment after considering the "concerns about using them in tandem" only. > If you have any objections against adoption of the draft please send > them to the mailing list before 18 June. Please include an outline of > what the alternative draft will be like or an alternative draft. If > there is such an objection, we will wait one additional week for that > alternative draft to materialize before taking a decision. > > The date, 18 June, gives us one month prior to the date for WG agendas > to be posted for Vancouver. We have requested a 30 minute meeting > slot in Vancouver. If by 18 July we do not seem to have any need for > further discussion in Vancouver, we will cede the time. I hope that does not imply that there is nothing to be discussed about SPF, and look forward to an open-minded meeting. Regards From ajs@anvilwalrusden.com Tue Jun 12 05:17:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543F921F860F for ; Tue, 12 Jun 2012 05:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiMx4Sv4wZN3 for ; Tue, 12 Jun 2012 05:17:18 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C9E2421F85F6 for ; Tue, 12 Jun 2012 05:17:18 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 76AD21ECB41C for ; Tue, 12 Jun 2012 12:17:17 +0000 (UTC) Date: Tue, 12 Jun 2012 08:17:18 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120612121718.GB16181@mail.yitter.info> References: <20120611160740.GL11684@crankycanuck.ca> <4FD6F3D5.4030107@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD6F3D5.4030107@tana.it> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 12:17:19 -0000 On Tue, Jun 12, 2012 at 09:46:29AM +0200, Alessandro Vesely wrote: > Is this because there /has/ to be an IPR? (Otherwise, I don't > understand why that patent would concern SPF, given that the > referenced IPR 434 was related to Sender ID only.) As the person who filed the IPR disclosure, I can tell you that it is because someone pointed out http://www.microsoft.com/openspecifications/en/us/programs/osp/security/default.aspx to me. That page clearly claims to cover RFC 4408. > I hope that does not imply that there is nothing to be discussed about > SPF, and look forward to an open-minded meeting. As we said in the original note, adopting a document as the basis for work does not mean that the document is ready. It means that it is a starting point for the work. As for the meeting in Vancouver, we'll only meet in person if there are things to sort out in person. Most work can be done on the mailing list. But if there are apparently issues that are not moving forward on the list, we'll meet in Vancouver. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Tue Jun 12 13:10:33 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 74CA421F8599 for ; Tue, 12 Jun 2012 13:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.596 X-Spam-Level: X-Spam-Status: No, score=-110.596 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEHBQj3uLnUP for ; Tue, 12 Jun 2012 13:10:27 -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 2396121F858F for ; Tue, 12 Jun 2012 13:10:26 -0700 (PDT) Received: (qmail 46122 invoked from network); 12 Jun 2012 20:10:26 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Jun 2012 20:10:26 -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=4fd7a232.xn--yuvv84g.k1206; i=johnl@user.iecc.com; bh=s6xyMV+NAB0M4WvzR32bIyqKEgzQSbcnd6VJX77nvYc=; b=aUcCSjSACs3d6bScCad7k0lVqLJPm58Voh4sOk7LA9FWYZoqy4uOJsruqvqLtZjHKGuDkAq4E7jAydNSPR/1FcFrmlEHAKFowBVZqJEscMbDrqpiAfQLDvWPx6DB5dqZouee9AQSdj3P0Or0eC0yt2SP5aJ4tVJbIIhWFzgTP/M= 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=4fd7a232.xn--yuvv84g.k1206; olt=johnl@user.iecc.com; bh=s6xyMV+NAB0M4WvzR32bIyqKEgzQSbcnd6VJX77nvYc=; b=aASMepvDU/aGmj0tuJ4yYYb675koTf4k9ya3DkRFrUNPkqH1I3ASR8n3g3TAa9hK06BQ3X/cha+yym0zTFzq3pGM7ep+IhsIaLNAX+H+2+W64JcgVqkaJxKGam9bRM+9xw4gRghs8LaDn6MSFB5ZzR3ta+7GmsK40svR7w2xZJE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Jun 2012 20:10:03 -0000 Message-ID: <20120612201003.72181.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20120612121718.GB16181@mail.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: ajs@anvilwalrusden.com Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 20:10:33 -0000 >As the person who filed the IPR disclosure, I can tell you that it is >because someone pointed out >http://www.microsoft.com/openspecifications/en/us/programs/osp/security/default.aspx >to me. That page clearly claims to cover RFC 4408. Not really. If you follow the backlink, it says that Microsoft promises not to sue you for patent infringement if you implement any of a list of specifications including RFC 4408. But it does not assert that any of their patents actually cover RFC 4408. IPR 434 referenced US patent application 10/684020, which has now turned into issued patent 7,398,315. That patent is rather opaque, even as patents go, but in a quick read I don't see anything that looks relevant to SPF. I don't know whether anyone from Microsoft is still following this, but it would be nice to see if they were willing to update the OSP page to include 4408bis, just to put the concerns to bed. R's, John From ajs@anvilwalrusden.com Tue Jun 12 13:42:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B447611E80AC for ; Tue, 12 Jun 2012 13:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVvDNoEMd7CY for ; Tue, 12 Jun 2012 13:42:00 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFA811E80B6 for ; Tue, 12 Jun 2012 13:41:59 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C401A1ECB41C for ; Tue, 12 Jun 2012 20:41:58 +0000 (UTC) Date: Tue, 12 Jun 2012 16:41:57 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120612204157.GP25201@mail.yitter.info> References: <20120612121718.GB16181@mail.yitter.info> <20120612201003.72181.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120612201003.72181.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 20:42:00 -0000 Hi, On Tue, Jun 12, 2012 at 08:10:03PM -0000, John Levine wrote: > >to me. That page clearly claims to cover RFC 4408. > > Not really. […] But it does not > assert that any of their patents actually cover RFC 4408. I shouldn't have said "clearly". My mistake. I filed that 3d party IPR disclosure because it appeared to me that there was a claim. Also, there was IIRC a disclosure filed against the MARID version of SPF, although I can't put my hands on it this moment (after about 20 seconds of trying). But, if you read your Note Well, the IETF takes no position on IPR. You have to make up your own mind. Therefore, since you've all been apprised of the IPR filing, we don't need to talk about the correctness of the filing. You can each make your own evaluation. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Tue Jun 12 14:03: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 9EFB721F86B5 for ; Tue, 12 Jun 2012 14:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYO+tOZB7y97 for ; Tue, 12 Jun 2012 14:03:14 -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 0F65C21F86B4 for ; Tue, 12 Jun 2012 14:03:14 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.27]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5CL2tU0018497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Jun 2012 14:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339534993; i=@elandsys.com; bh=/TWUr+MFSj+34FNw2cWe+sF/FsCba+GOsOD67MjjUSc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=X/G7SMVLBwcVYyGKRqsd3KIxCuMlf9AhNq5JQFJSws2a82rZhPFwrao4Z3S65x1fW Q1PvEXpOjSIFx9DuYuxSAOI6O8k3uz+g/sL9ZX8PN7PkRJYoPEFtZsQFS510/KRd0l klCN63TsrN/DdM77ZxClKiulU2fvCIf8kxaINeI8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1339534993; i=@elandsys.com; bh=/TWUr+MFSj+34FNw2cWe+sF/FsCba+GOsOD67MjjUSc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=O9z1o2XHcZom11q/04lb51pE3B9UOLSd0rgqrU+sBm15qWxS00PJurY8U++BufuaS dsbbBEI9DD9j21nK5KM89mEn1Isact659NFV4qrZPCByOOPTbKwAHj9l/oXNjzTWD8 H6+jA+7OtH+wOAfdg/PLYxX11fx1rRtcsK/z/DfE= Message-Id: <6.2.5.6.2.20120612132729.0aa9d228@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 12 Jun 2012 14:02:53 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120526124417.28073.97552.idtracker@ietfa.amsl.com> References: <20120526124417.28073.97552.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Summary of Last Call for draft-ietf-spfbis-experiment-09 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 21:03:15 -0000 Hello, Here's a summary of the Last Call for draft-ietf-spfbis-experiment-09. There was a comment from Murray about editorial changes [1]. As he is the editor, I don't have to spend time on this. There were comments from Arthur Thisell [2]. I don't see any change requested in the message. Brian Carpenter considers the Gen-ART review as addressed [3]. There were comments from Hector Santos [4]. I'll default to no changes requested as I don't see any proposed text. I'll consider the issue mentioned by the Responsible Area Director as addressed. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/ietf/current/msg73467.html 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg01557.html 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg01573.html 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg01567.html From internet-drafts@ietf.org Tue Jun 12 14:03:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4061B21F86EA; Tue, 12 Jun 2012 14:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcDimxo9KRO6; Tue, 12 Jun 2012 14:03:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F01521F86B4; Tue, 12 Jun 2012 14:03:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120612210350.6991.33790.idtracker@ietfa.amsl.com> Date: Tue, 12 Jun 2012 14:03:50 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-11.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 21:03:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Resolution of The SPF and Sender ID Experiments Author(s) : Murray S. Kucherawy Filename : draft-ietf-spfbis-experiment-11.txt Pages : 12 Date : 2012-06-12 Abstract: In 2006 the IETF published a suite of protocol documents comprising SPF and Sender ID, two proposed email authentication protocols. Both of these protocols enable one to publish via the Domain Name System a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required the publication of all of these documents (RFC4405, RFC4406, RFC4407, and RFC4408) with Experimental status, and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-11 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-experiment-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Tue Jun 12 15:51: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 CB7D821F86F8 for ; Tue, 12 Jun 2012 15:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlARmFXP3Iho for ; Tue, 12 Jun 2012 15:51:05 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9E321F86C8 for ; Tue, 12 Jun 2012 15:51:04 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 7D28FD04082; Tue, 12 Jun 2012 17:51:03 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1339541463; bh=S5+e27gXNUXKncBhHTbOKghnGIjjEVn/8ytEywy8wzQ=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=AuJ31FOUwm5zhxasUwTkKdQqTxGfGmqqplCiBGZorn99Cw3zmIh8GlmlMVymHbjX3 IS7vBB+FsxDsgDSLE67U7rHTgZoxH2j+auOo+Kz6TSndnhaJdqKy99PM+SSCupbl/Q yIi3Ma65JY3GGlT7Z+yEd2YLpuVcY7zMeXI8YTVA= Received: from 75.sub-97-10-144.myvzw.com (75.sub-97-10-144.myvzw.com [97.10.144.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EE7F4D04062; Tue, 12 Jun 2012 17:51:02 -0500 (CDT) References: <20120612201003.72181.qmail@joyce.lan> User-Agent: K-9 Mail for Android In-Reply-To: <20120612201003.72181.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 12 Jun 2012 18:51:10 -0400 To: spfbis@ietf.org Message-ID: <1a01be4d-1192-4988-b613-d7e8138138c5@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 22:51:11 -0000 John Levine wrote: >>As the person who filed the IPR disclosure, I can tell you that it is >>because someone pointed out >>http://www.microsoft.com/openspecifications/en/us/programs/osp/security/default.aspx >>to me. That page clearly claims to cover RFC 4408. > >Not really. If you follow the backlink, it says that Microsoft >promises not to sue you for patent infringement if you implement any >of a list of specifications including RFC 4408. But it does not >assert that any of their patents actually cover RFC 4408. > >IPR 434 referenced US patent application 10/684020, which has now >turned into issued patent 7,398,315. That patent is rather opaque, >even as patents go, but in a quick read I don't see anything that >looks relevant to SPF. > >I don't know whether anyone from Microsoft is still following this, but >it would be nice to see if they were willing to update the OSP page >to include 4408bis, just to put the concerns to bed. If we get to pick, I'd rather the remove 4408. I've looked at the patent as well and was unable to detect anything relevant to 4408 through the patent speak. Scott K From superuser@gmail.com Wed Jun 13 06:57: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 195B721F8468 for ; Wed, 13 Jun 2012 06:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QirzOnodHHdz for ; Wed, 13 Jun 2012 06:57:47 -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 2F7F621F8467 for ; Wed, 13 Jun 2012 06:57:47 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1524249lbb.31 for ; Wed, 13 Jun 2012 06:57:46 -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 :content-type; bh=+r7rmCyji/TBt7A6qJdHSQTZPkYcUlIB0OidWf9mR4o=; b=rtA+ElXemf8Uhq6UHLSaCUDealMtUcvymCb+G7YIfbwsYtv3cjIg8Vid2rosmqd8gq D2eRIVVmRENaed0436gfmy744Vn8AzoxEOkkaTnY48avyKeYT9W2+W2naSUM4XKAtQCr P8Epi1tucAcLpkGxEu31ww0zs0+wKW6wSuPbEXXJeGiVxOUGBQMrsv5KQkboAZQ/19Vj cH4Z7rO2Nh4OdCHsX+BsXAxNuFoJoF/DM6tSb/KuuV5CdGlFRm7BAYNpOZJ7ZZ6kSgi+ ktOghNBbg394igR8hATkspzUMRAYLXFthlOoP832381REnPEPWhYaWAbkAZ/JK8kYHbJ F6jg== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr24979281lab.9.1339595866100; Wed, 13 Jun 2012 06:57:46 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 13 Jun 2012 06:57:45 -0700 (PDT) In-Reply-To: <20120612210350.6991.33790.idtracker@ietfa.amsl.com> References: <20120612210350.6991.33790.idtracker@ietfa.amsl.com> Date: Wed, 13 Jun 2012 06:57:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: spfbis@ietf.org Content-Type: multipart/alternative; boundary=e89a8f22c411bdd1f504c25af78c Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-experiment-11.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 13:57:48 -0000 --e89a8f22c411bdd1f504c25af78c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 12, 2012 at 2:03 PM, 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 : Resolution of The SPF and Sender ID Experiments > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-spfbis-experiment-11.txt > Pages : 12 > Date : 2012-06-12 > > Abstract: > In 2006 the IETF published a suite of protocol documents comprising > SPF and Sender ID, two proposed email authentication protocols. Both > of these protocols enable one to publish via the Domain Name System a > policy declaring which mail servers were authorized to send email on > behalf of the domain name being queried. There was concern that the > two would conflict in some significant operational situations, > interfering with message delivery. > > The IESG required the publication of all of these documents (RFC4405, > RFC4406, RFC4407, and RFC4408) with Experimental status, and > requested that the community observe deployment and operation of the > protocols over a period of two years from the date of publication to > determine a reasonable path forward. > > After six years, sufficient experience and evidence have been > collected that the experiments thus created can be considered > concluded. This document presents those findings. > > This just changes some wording about IANA procedures regarding RRTYPE registration, at the request of IANA. The document is now scheduled for the next IESG telechat. -MSK --e89a8f22c411bdd1f504c25af78c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 12, 2012 at 2:03 PM, <inter= net-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the SPF Update Working Group of the IETF.
=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Resolution of The SPF and Sende= r ID Experiments
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Murray S. Kucherawy
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-spfbis-experiment-11.t= xt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-12

Abstract:
=A0 In 2006 the IETF published a suite of protocol documents comprising =A0 SPF and Sender ID, two proposed email authentication protocols. =A0Bot= h
=A0 of these protocols enable one to publish via the Domain Name System a<= br> =A0 policy declaring which mail servers were authorized to send email on =A0 behalf of the domain name being queried. =A0There was concern that the=
=A0 two would conflict in some significant operational situations,
=A0 interfering with message delivery.

=A0 The IESG required the publication of all of these documents (RFC4405,<= br> =A0 RFC4406, RFC4407, and RFC4408) with Experimental status, and
=A0 requested that the community observe deployment and operation of the =A0 protocols over a period of two years from the date of publication to =A0 determine a reasonable path forward.

=A0 After six years, sufficient experience and evidence have been
=A0 collected that the experiments thus created can be considered
=A0 concluded. =A0This document presents those findings.


This just changes some wording about IANA procedu= res regarding RRTYPE registration, at the request of IANA.

The docum= ent is now scheduled for the next IESG telechat.

-MSK

--e89a8f22c411bdd1f504c25af78c-- From spf2@kitterman.com Wed Jun 13 16:58:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1909511E808F for ; Wed, 13 Jun 2012 16:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFf2HdO0+TpS for ; Wed, 13 Jun 2012 16:58:27 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 08D7711E807F for ; Wed, 13 Jun 2012 16:58:24 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0E6D220E4095; Wed, 13 Jun 2012 19:58:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1339631903; bh=qlZJ1r3iGJYerN8wzYe3ZGazM2BBlszVHJsFVFVBhEU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=WQKqqoczsBlor+bf9mOXziOHnAYHjtq4a4ig8Cnmm6iN3H/uAcJFAck3roZi6aRPU 3aaO8XUhauOMxjmR1BKzZZ3J7PElC7BpRMtUnJHV0eZBcs1sqsx7oooErV1tsRWuVy TnfuyctxctZiWVrU9KnV8qoKq95kh8nKNBtgPY6A= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E4E8B20E4093; Wed, 13 Jun 2012 19:58:22 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 13 Jun 2012 19:58:22 -0400 Message-ID: <2092795.BIeCdPn4ql@scott-latitude-e6320> User-Agent: KMail/4.8.3 (Linux/3.2.0-24-generic-pae; KDE/4.8.3; i686; ; ) In-Reply-To: <20120611160740.GL11684@crankycanuck.ca> References: <20120611160740.GL11684@crankycanuck.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 23:58:28 -0000 On Monday, June 11, 2012 12:07:40 PM Andrew Sullivan wrote: > Dear colleagues, ... > We would like the working group to consider adopting > draft-kitterman-4408bis as the basis for such a specification. As the > charter explicitly mentions that draft as a possible basis for work, > it is the presumptive candidate for adoption. > ... As requested, I've posted a -01 to revive the draft. See: http://www.ietf.org/id/draft-kitterman-4408bis-01.txt It's the same as 00 except I removed a paragraph the discussed resolution of the experiment, since that's already been addressed and added review of WG issue status to the TODO section that was already present. Scott K From superuser@gmail.com Wed Jun 13 17:32:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CDB11E80AF for ; Wed, 13 Jun 2012 17:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfK0UsbzIHQk for ; Wed, 13 Jun 2012 17:32:08 -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 F145911E80D3 for ; Wed, 13 Jun 2012 17:32:07 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so342508obb.31 for ; Wed, 13 Jun 2012 17:32:07 -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=AqFjxyuTTAzyqRL8wUKJtt5/QQ7lq0ZEdKTkL3wNPCI=; b=zdryFS3n5LjTeqFgQLNsvTqY8jyrbxvMWlpi2LfKMNgmc5zSNBVTXDhFLsZ9phjHF5 UfnCEbTSPDj056JrXD6/SMBnlyaUPy7xGGtsjqlcjcukGWzCuSzbFUnV/uVD80qhG8px 9byZSnvKeUsWJmhJAufTrDwKeFiXqIyHEMPNaOD932kJnVVMrrGGgev6lhPLX4bc3voF D7cM6HtwF181LJ1LGB3aGEFW0nrV24XEgeWleMdZnez6s39OaCJw/pk0y+IG/YxQGqxU SbmI0lUzXYFLVpJqNP+yojjpnvmoALicDk0KKu5nbABBRXwNPHKX/QH/4Y05ZHfAxaYf BjmA== MIME-Version: 1.0 Received: by 10.60.169.174 with SMTP id af14mr26601047oec.13.1339633927564; Wed, 13 Jun 2012 17:32:07 -0700 (PDT) Received: by 10.182.66.201 with HTTP; Wed, 13 Jun 2012 17:32:07 -0700 (PDT) In-Reply-To: <2092795.BIeCdPn4ql@scott-latitude-e6320> References: <20120611160740.GL11684@crankycanuck.ca> <2092795.BIeCdPn4ql@scott-latitude-e6320> Date: Wed, 13 Jun 2012 17:32:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=bcaec54c539261ac3f04c263d4d5 Cc: spfbis@ietf.org Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 00:32:08 -0000 --bcaec54c539261ac3f04c263d4d5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 13, 2012 at 4:58 PM, Scott Kitterman wrote: > As requested, I've posted a -01 to revive the draft. See: > > http://www.ietf.org/id/draft-kitterman-4408bis-01.txt > > It's the same as 00 except I removed a paragraph the discussed resolution > of > the experiment, since that's already been addressed and added review of WG > issue status to the TODO section that was already present. > > Some housekeeping to note for later: Appendix C probably needs to be updated, especially the bit about the IESG note. Also, when we did DKIM it was suggested that the resolved errata be listed by their numbers. I don't recall if any of the ones you've got there were tracked as errata on the RFC Editor site or just at openspf.org. Should they be opened as RFC Editor errata if they were only external? Are there any external tracking numbers that would be useful to add? It helps people evaluating the document to have this sort of thing as a sort of checklist to ensure nothing's getting missed. -MSK --bcaec54c539261ac3f04c263d4d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 13, 2012 at 4:58 PM, Scott Kitterman <spf2@kitterman.com&= gt; wrote:
As requested, I've posted a -01 to revive the draft. =A0See:

http://www.ietf.org/id/draft-kitterman-4408bis-01.txt

It's the same as 00 except I removed a paragraph the discussed resoluti= on of
the experiment, since that's already been addressed and added review of= WG
issue status to the TODO section that was already present.


Some housekeeping to note for later:

Appen= dix C probably needs to be updated, especially the bit about the IESG note.=

Also, when we did DKIM it was suggested that the resolved errata be= listed by their numbers.=A0 I don't recall if any of the ones you'= ve got there were tracked as errata on the RFC Editor site or just at openspf.org.=A0 Should they be opened as RFC = Editor errata if they were only external?=A0 Are there any external trackin= g numbers that would be useful to add?=A0 It helps people evaluating the do= cument to have this sort of thing as a sort of checklist to ensure nothing&= #39;s getting missed.

-MSK

--bcaec54c539261ac3f04c263d4d5-- From sm@elandsys.com Wed Jun 13 19:07:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BFD11E80D2 for ; Wed, 13 Jun 2012 19:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZ+s8iWOXR5j for ; Wed, 13 Jun 2012 19:07:11 -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 A9FC411E8072 for ; Wed, 13 Jun 2012 19:07:11 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.201]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5E26XRE002262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jun 2012 19:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339639624; i=@elandsys.com; bh=YcEZSZaxKYXORxq7JLFsLL6fXmyF+D9xank+37Rpyjg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MexYedL0mEeXF0cFa/m1t0rH23DtoYr1V9xxRs+QAuAZKLd/gEb6KJpFmRRRjRrq4 zuqaI8XtW6lqe6ZBCqWSUeEU3akYxGtDBgQiAayohkqHcs7UgEDKXUZmCXBha7YydH iDFqhrlqE66Vbrl9bi1D3FXiW5lP0vgEbb/7z+5I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1339639624; i=@elandsys.com; bh=YcEZSZaxKYXORxq7JLFsLL6fXmyF+D9xank+37Rpyjg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tw0CpjedmUnL4TMhWXOX7lA9V4eoVG9IsCXp/2Fwv10NPBLkIABJpp57OtxZ93qZQ 6yMyV5vsiKIvNaLTo+2EQgZAm0Hzb4f1JdVE2jZKpiVdOwHiOFUJYutuK8Li/YVFn7 GDdzG1Og9EfRWy2F6M6/ujW+B4wp9HPk+pkSl9Ug= Message-Id: <6.2.5.6.2.20120613185252.094cc8a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 13 Jun 2012 19:06:18 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <20120611160740.GL11684@crankycanuck.ca> <2092795.BIeCdPn4ql@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] Call for adoption: draft-kitterman-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 02:07:16 -0000 At 17:32 13-06-2012, Murray S. Kucherawy wrote: >Appendix C probably needs to be updated, especially the bit about >the IESG note. Please leave the current version as it is as there is a call for adoption currently. >Also, when we did DKIM it was suggested that the resolved errata be >listed by their numbers. I don't recall if any of the ones you've >got there were tracked as errata on the RFC Editor site or just at >openspf.org. Should they be opened as RFC Editor errata if they >were only external? Are there any external tracking numbers that >would be useful to add? It helps people evaluating the document to >have this sort of thing as a sort of checklist to ensure nothing's >getting missed. There is no need to file errata as there is an existing working group updating RFC 4408. There are also existing tickets in the issue tracker for the errata and the issues raised during the review period. It will likely be the starting point for the upcoming discussions. The suggestion to list the erratum number also came up for work in a different working group. I would like to discuss the above and other details with Andrew Sullivan to see how the work can be planned. Regards, S. Moonesamy SPFBIS WG co-chair From dhc@dcrocker.net Fri Jun 15 12:23: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 2FF8911E80DF for ; Fri, 15 Jun 2012 12:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFpxRZNIQrFL for ; Fri, 15 Jun 2012 12:23:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A8DD711E80CD for ; Fri, 15 Jun 2012 12:23:02 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q5FJN1LT027016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 15 Jun 2012 12:23:02 -0700 Message-ID: <4FDB8B90.5000209@dcrocker.net> Date: Fri, 15 Jun 2012 12:22:56 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 15 Jun 2012 12:23:02 -0700 (PDT) Subject: [spfbis] Announce: Maturing DMARC implementations through an interoperability event X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 19:23:04 -0000 Maturing DMARC implementations through an interoperability event... At the end of January, the DMARC (Domain-based Message Authentication, Reporting & Conformance) specification was publicly announced with extensive media coverage, blog posts and discussion. Since that time various folk have been working on writing code for DMARC validators and report parsers. The dmarc-discuss list has been active, as various questions and issues have been clarified. Now it is time to see how well implementations play together in live testing. The DMARC Interopability event has been announced: http://dmarc.org/interop_event.html When: July 19-20, 2012 Where: Menlo Park California As with previous interoperability events for other specifications such as DKIM, the event for DMARC will help people who write running code to work with other implementers, to tease out any interoperability issues. If you are writing and implementing DMARC code this is an event you shouldn’t miss. From ajs@anvilwalrusden.com Mon Jun 18 14:23:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD6811E8095 for ; Mon, 18 Jun 2012 14:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELiGEFvzkgRv for ; Mon, 18 Jun 2012 14:23:39 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 73A4A11E808F for ; Mon, 18 Jun 2012 14:23:39 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BE66C1ECB41D for ; Mon, 18 Jun 2012 21:23:38 +0000 (UTC) Date: Mon, 18 Jun 2012 17:23:37 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120618212337.GD32683@mail.yitter.info> References: <20120611160740.GL11684@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120611160740.GL11684@crankycanuck.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Draft adopted (was: Call for adoption: draft-kitterman-4408bis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 21:23:40 -0000 Dear colleagues, > We would like the working group to consider adopting > draft-kitterman-4408bis as the basis for such a specification. As the > charter explicitly mentions that draft as a possible basis for work, > it is the presumptive candidate for adoption. > > If you have any objections against adoption of the draft please send > them to the mailing list before 18 June. Nobody objected. The draft is hereby adopted. Scott Kitterman is appointed as editor of the WG document. Scott, the next version of the draft gets the filename draft-ietf-spfbis-rfc4408bis-00.txt (and any xml or such like if you wish). Participants, in the meantime the draft-kitterman-4408bis-01 draft is in the datatracker as having been adopted. Please read it. As many of you know, there are open issues in WG's trac. We will be pulling them up. In the meantime, if there are particular issues you think are directly relevant for the draft, it would do no harm to add the references to the trac tickets. If you have new issues that haven't been described yet, please describe them on the list. The -experiment- process was, despite some frustration over the pace, actually fairly successful I think, and so we're going to take a similar approach here. We're going to start by describing issues first. Therefore, I'd appreciate it if people took the next week to describe any issues they have _without engaging in debate_ over the issues. Then we can prioritise issues and bring them to the list in manageable chunks. This will not be as simple as the case of -experiment- because there are protocol issues at stake, but your chairs think we can focus discussion this way and come to some conclusions successfully. Best regards, Andrew (for the chairs) -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Mon Jun 18 14:40:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED7311E80C1 for ; Mon, 18 Jun 2012 14:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.403 X-Spam-Level: X-Spam-Status: No, score=-3.403 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpPV714hQFsD for ; Mon, 18 Jun 2012 14:40:11 -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 5902511E808F for ; Mon, 18 Jun 2012 14:40:11 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5320737lbb.31 for ; Mon, 18 Jun 2012 14:40:10 -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=OZ0+8LvJOpKBN7UPPXyNzd5sgPwNyOjVdqAJdCJPV9g=; b=P73vw48BB1cyBwiefvskl32jhK43BWc0Sq/kkEsz1e3CDGvS2TiJYPwiJxzpn5ktiX TKMzEdNXYLffwiJAbRN7vAIAq2NyA11thPcV4pzHlnSmdKlsD36CsDVn+1cqUCBpyqdO 8kN+UJJMWStJK+/NuYSH0EbspBQRY9zGWzTxVWBme5p+ERi7OCYwrePRSmVrSDGWxUAc TbuwfBEoy5P0HjbMyl+HesjSqm9tZMM9Wxt1QDUrEKXRAhBJ7xz9f0rJJTbUDtzEjXO+ BH73t3g/SX8YK1sQ4IuVBcalzi8ubczqtsU8jg0wt0cB7TGRHlWXu7zyAZfN3nCLnZcw 6DHA== MIME-Version: 1.0 Received: by 10.112.36.225 with SMTP id t1mr7154675lbj.67.1340055610137; Mon, 18 Jun 2012 14:40:10 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 18 Jun 2012 14:40:10 -0700 (PDT) In-Reply-To: <20120618212337.GD32683@mail.yitter.info> References: <20120611160740.GL11684@crankycanuck.ca> <20120618212337.GD32683@mail.yitter.info> Date: Mon, 18 Jun 2012 14:40:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=e0cb4efe2f4c9f1de104c2c602da Cc: spfbis@ietf.org Subject: Re: [spfbis] Draft adopted (was: Call for adoption: draft-kitterman-4408bis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 21:40:12 -0000 --e0cb4efe2f4c9f1de104c2c602da Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 18, 2012 at 2:23 PM, Andrew Sullivan wrote: > The -experiment- process was, despite some frustration over the pace, > actually fairly successful I think, and so we're going to take a > similar approach here. We're going to start by describing issues > first. Therefore, I'd appreciate it if people took the next week to > describe any issues they have _without engaging in debate_ over the > issues. Then we can prioritise issues and bring them to the list in > manageable chunks. This will not be as simple as the case of > -experiment- because there are protocol issues at stake, but your > chairs think we can focus discussion this way and come to some > conclusions successfully. > > Does this refer to issues not already present in the tracker? -MSK --e0cb4efe2f4c9f1de104c2c602da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jun 18, 2012 at 2:23 PM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
The -experiment- process was, despite some frustration over the pace,
actually fairly successful I think, and so we're going to take a
similar approach here. =A0We're going to start by describing issues
first. =A0Therefore, I'd appreciate it if people took the next week to<= br> describe any issues they have _without engaging in debate_ over the
issues. =A0Then we can prioritise issues and bring them to the list in
manageable chunks. =A0This will not be as simple as the case of
-experiment- because there are protocol issues at stake, but your
chairs think we can focus discussion this way and come to some
conclusions successfully.


Does this refer to issues not already present in = the tracker?

-MSK

--e0cb4efe2f4c9f1de104c2c602da-- From ajs@anvilwalrusden.com Mon Jun 18 15:18:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4671C11E80CC for ; Mon, 18 Jun 2012 15:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyZbNQ2oLwmw for ; Mon, 18 Jun 2012 15:18:19 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id A837211E80C1 for ; Mon, 18 Jun 2012 15:18:14 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DA7671ECB41D for ; Mon, 18 Jun 2012 22:18:13 +0000 (UTC) Date: Mon, 18 Jun 2012 18:18:12 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120618221812.GE32683@mail.yitter.info> References: <20120611160740.GL11684@crankycanuck.ca> <20120618212337.GD32683@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Draft adopted (was: Call for adoption: draft-kitterman-4408bis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 22:18:20 -0000 On Mon, Jun 18, 2012 at 02:40:10PM -0700, Murray S. Kucherawy wrote: > Does this refer to issues not already present in the tracker? Yes. Sorry for being unclear. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Thu Jun 21 17:35:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC6E11E8091 for ; Thu, 21 Jun 2012 17:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-7V48aqN4bd for ; Thu, 21 Jun 2012 17:35:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D92EE11E8072 for ; Thu, 21 Jun 2012 17:35:13 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C6EBC20E40A3; Thu, 21 Jun 2012 20:35:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340325312; bh=K1vLnNx4c5RRNB/uleogXLZ3LBsFsiEHc4ATB/dDSPU=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=WMhyzHPEgduErsI9wMGd8WWy1siYEfqqHD0Io+Y3MqEBvL+xhMsT4P1zTrWqxMEEB J42ckrdriip+r5fwle+ktXTMWbscsINoshAeuEwcchqQRNdVGIDK2qTIF9YLF6ACtE wh4QDy+WiHW7DQgfZNwYlfC1YsB1hUbPPCdXZb5g= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id AD79420E403E; Thu, 21 Jun 2012 20:35:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 21 Jun 2012 18:12:18 -0400 Message-ID: <2699025.dxO2HPotY4@scott-latitude-e6320> User-Agent: KMail/4.8.3 (Linux/3.2.0-25-generic-pae; KDE/4.8.3; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] RFC 4408 Test Ambiguities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 00:35:16 -0000 As part of my preparations for uploading the initial WG draft of 4408bis, I'm reviewing the SPF test suite for documented ambiguities that need fixing (See http://tools.ietf.org/wg/spfbis/trac/ticket/5). Here's one I've come up with that I don't know the correct solution for that I think should be discussed: invalid-domain-empty-label: description: >- target-name that is a valid domain-spec per RFC 4408 but an invalid domain name per RFC 1035 (empty label) must be treated as non-existent. comment: >- An empty domain label, i.e. two successive dots, in a mechanism target-name is valid domain-spec syntax, even though a DNS query cannot be composed from it. The spec being unclear about it, this could either be considered a syntax error, or, by analogy to 4.3/1 and 5/10/3, the mechanism chould be treated as a no-match. spec: [4.3/1, 5/10/3] helo: mail.example.com host: 1.2.3.4 mailfrom: foo@t10.example.com result: [permerror, fail] The question is, should ".." be an error or an oddity that will never match anything because you can't actually query for it. I lean towards the former, but I think picking one matters more than which one we pick. invalid-domain-long-via-macro: description: >- target-name that is a valid domain-spec per RFC 4408 but an invalid domain name per RFC 1035 (long label) must be treated as non-existent. comment: >- A domain label longer than 63 characters that results from macro expansion in a mechanism target-name is valid domain-spec syntax (and is not even subject to syntax checking after macro expansion), even though a DNS query cannot be composed from it. The spec being unclear about it, this could either be considered a syntax error, or, by analogy to 4.3/1 and 5/10/3, the mechanism chould be treated as a no-match. spec: [4.3/1, 5/10/3] helo: "%%%%%%%%%%%%%%%%%%%%%%" host: 1.2.3.4 mailfrom: foo@t12.example.com result: [permerror,fail] This is very simlar (too long versus non-existant). Once again, I think picking one is the most important thing. Scott K From WebMaster@Commerco.Net Thu Jun 21 18:36:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D5221F8497 for ; Thu, 21 Jun 2012 18:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4i4s6AarZUt4 for ; Thu, 21 Jun 2012 18:36:55 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 53A4821F8494 for ; Thu, 21 Jun 2012 18:36:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=eFk0o76eSUw4XiJY1ZjiHs6ZrkZz0f0GldEqLFUwzp/C2eL82YuychtIXqVApytBbO0Eu2/jI90yghksRXH5yZtnXmd1afZNx/WCh2CZrt4JemHWgdrltIvgUVUfAWDBIdE3F5uu3vdGkMIg3biP8042wqrBJsovXlxqQdUaC40= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Fri, 22 Jun 2012 01:36:54 +0000 Message-ID: <4FE3CC30.8020601@Commerco.Net> Date: Thu, 21 Jun 2012 19:36:48 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <2699025.dxO2HPotY4@scott-latitude-e6320> In-Reply-To: <2699025.dxO2HPotY4@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] RFC 4408 Test Ambiguities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 01:36:56 -0000 Scott, Does it make sense to perhaps simplify even further? It might suffice to simply say that if a domain name cannot be resolved because it is invalid per RFC 1035, it MUST be considered an error by those who implement SPFBIS. It kind of leaves little to the imagination, which in this case is probably a good thing. Best, Alan M On 6/21/2012 4:12 PM, Scott Kitterman wrote: > As part of my preparations for uploading the initial WG draft of 4408bis, I'm > reviewing the SPF test suite for documented ambiguities that need fixing (See > http://tools.ietf.org/wg/spfbis/trac/ticket/5). > Here's one I've come up with that I don't know the correct solution for that I > think should be discussed: > > invalid-domain-empty-label: > description:>- > target-name that is a valid domain-spec per RFC 4408 but an invalid > domain name per RFC 1035 (empty label) must be treated as non-existent. > comment:>- > An empty domain label, i.e. two successive dots, in a mechanism > target-name is valid domain-spec syntax, even though a DNS query cannot > be composed from it. The spec being unclear about it, this could either > be considered a syntax error, or, by analogy to 4.3/1 and 5/10/3, the > mechanism chould be treated as a no-match. > spec: [4.3/1, 5/10/3] > helo: mail.example.com > host: 1.2.3.4 > mailfrom: foo@t10.example.com > result: [permerror, fail] > > The question is, should ".." be an error or an oddity that will never match > anything because you can't actually query for it. I lean towards the former, > but I think picking one matters more than which one we pick. > > invalid-domain-long-via-macro: > description:>- > target-name that is a valid domain-spec per RFC 4408 but an invalid > domain name per RFC 1035 (long label) must be treated as non-existent. > comment:>- > A domain label longer than 63 characters that results from macro > expansion in a mechanism target-name is valid domain-spec syntax (and is > not even subject to syntax checking after macro expansion), even though > a DNS query cannot be composed from it. The spec being unclear about > it, this could either be considered a syntax error, or, by analogy to > 4.3/1 and 5/10/3, the mechanism chould be treated as a no-match. > spec: [4.3/1, 5/10/3] > helo: "%%%%%%%%%%%%%%%%%%%%%%" > host: 1.2.3.4 > mailfrom: foo@t12.example.com > result: [permerror,fail] > > This is very simlar (too long versus non-existant). Once again, I think > picking one is the most important thing. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From vesely@tana.it Fri Jun 22 02:09:01 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 E3A4A21F8501 for ; Fri, 22 Jun 2012 02:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.451 X-Spam-Level: X-Spam-Status: No, score=-4.451 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbXBKMy8Tex5 for ; Fri, 22 Jun 2012 02:09:01 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C633821F84FB for ; Fri, 22 Jun 2012 02:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1340356138; bh=lWG+togfqNOEly+sswNADL8OvomXAPgcEZkXwAJjYW0=; l=842; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=i4XuS9s4m+ziSXDcWk0gqs/M4fDSlyVOixjhDJZ2z/TL3mCJgGoseANCrmD2xisu1 bDa+zeRcnz/YjH5y5Tou3NZ33h8acIXAypunHbE8DO2meSWfTPbbQ84qq28UIvm1yd s0Xw4hRFbfFu1B43w2EdxOhzWqMk6deEX6kPfYMg= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 22 Jun 2012 11:08:58 +0200 id 00000000005DC035.000000004FE4362A.00007097 Message-ID: <4FE4362A.8030601@tana.it> Date: Fri, 22 Jun 2012 11:08:58 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <2699025.dxO2HPotY4@scott-latitude-e6320> <4FE3CC30.8020601@Commerco.Net> In-Reply-To: <4FE3CC30.8020601@Commerco.Net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] RFC 4408 Test Ambiguities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 09:09:02 -0000 On Fri 22/Jun/2012 03:36:48 +0200 Commerco WebMaster wrote: > > Does it make sense to perhaps simplify even further? It might suffice > to simply say that if a domain name cannot be resolved because it is > invalid per RFC 1035, it MUST be considered an error by those who > implement SPFBIS. > > It kind of leaves little to the imagination, which in this case is > probably a good thing. That makes sense because --when adequate provisions will be in place-- it will be possible to report that as an error, which it is, to the relevant admin. Given the high number of permerrors, such kind of action is desirable, IMHO. Perhaps +all is also an error, in most of the few places where it appears, e.g. bluecross.ca. However, since it is exemplified in the text, it cannot be an error. Will we have warnings for such cases? From spf2@kitterman.com Fri Jun 22 07:39:21 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 BFC5D21F86E0 for ; Fri, 22 Jun 2012 07:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR-oVu2JuYpN for ; Fri, 22 Jun 2012 07:39:19 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4087C21F86DD for ; Fri, 22 Jun 2012 07:39:17 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 57A9E20E40A3; Fri, 22 Jun 2012 10:39:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340375956; bh=DZxspEkEQPe35yjeE0YcpeNaHOiiInN/54rV6x/26Qo=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=YV4+jnT0dL85V5VveAq+K4TTX9DPatJO3TTHF32l89PikbrMO9aUmtKTsW+wp6re1 T1R4/jDXfDEuTtt4gSSRaTDxAhum9gX2/z5L3UVh0LyT4E6CjIXeaICeDN81HxJQ/P dU0o+7+EmwQGKbAGmoCIvtttuTmvBg4WRMDwkLVI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 39FB120E4081; Fri, 22 Jun 2012 10:39:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 22 Jun 2012 10:39:15 -0400 Message-ID: <4076302.rYWlcX9yKs@scott-latitude-e6320> User-Agent: KMail/4.8.3 (Linux/3.2.0-25-generic-pae; KDE/4.8.3; i686; ; ) In-Reply-To: <4FE4362A.8030601@tana.it> References: <2699025.dxO2HPotY4@scott-latitude-e6320> <4FE3CC30.8020601@Commerco.Net> <4FE4362A.8030601@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] RFC 4408 Test Ambiguities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 14:39:21 -0000 On Friday, June 22, 2012 11:08:58 AM Alessandro Vesely wrote: > Perhaps +all is also an error, in most of the few places where it > appears, e.g. bluecross.ca. However, since it is exemplified in the > text, it cannot be an error. Will we have warnings for such cases? The protocol can't be a mind reader. If a domain owner wants to authorize every MTA on the planet to sent mail from their domain, then there's not a lot we can do about it. -1 on warnings being defined in the protocol. There are ways to make a record that acts like +all, but doesn't appear so based on casual inspection, so identifying these cases in non-trivial. It would be useful in testing tools perhaps to provide such warnings, but there's no scope for it in the protocol definition. Scott K From ajs@anvilwalrusden.com Fri Jun 22 08:02:14 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 DE37321F8541 for ; Fri, 22 Jun 2012 08:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARwOw+LY8smu for ; Fri, 22 Jun 2012 08:02:14 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id D9D6621F853E for ; Fri, 22 Jun 2012 08:02:13 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 25F3C1ECB41D for ; Fri, 22 Jun 2012 15:02:13 +0000 (UTC) Date: Fri, 22 Jun 2012 11:02:11 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120622150211.GG4401@crankycanuck.ca> References: <2699025.dxO2HPotY4@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2699025.dxO2HPotY4@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] RFC 4408 Test Ambiguities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 15:02:15 -0000 Hi, No hat. On Thu, Jun 21, 2012 at 06:12:18PM -0400, Scott Kitterman wrote: > invalid-domain-empty-label: > description: >- > target-name that is a valid domain-spec per RFC 4408 but an invalid > domain name per RFC 1035 (empty label) must be treated as non-existent. The problem with this (and the other) case is, surely, that "domain-spec" doesn't actually constrain things such that only valid DNS names pass it, right? (It doesn't permit all valid DNS names, either, but I guess that's on purpose.) Wouldn't it be better to fix domainspec so that there would necessarily never be a name that met the test, but that isn't actually a valid DNS name anyway? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Sat Jun 23 21:25:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A87921F86D4 for ; Sat, 23 Jun 2012 21:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mYutAOmwH7H for ; Sat, 23 Jun 2012 21:25:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3079621F86D3 for ; Sat, 23 Jun 2012 21:25:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1435220E40A3; Sun, 24 Jun 2012 00:25:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340511956; bh=W9cmQWJR0Rg2fG6rsw5WnOcrggxkpQbs+IafzrgIEwg=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=LqXhMJqsPOlLxDGUoX1Co+DhuusXAuaOkNihRCmkja1PXFTnZxBgf61pvSvdWsJaS TnNooLtmV3EsiqjT+ifZWYwOR6uiRumhUD5Pg4tB74T6g2Nl0kWU9e39fLVt1t7Al5 5CYv7dIIxmvgCqW1BAVmCo2I3sZaVt6eOMmQ8SF0= Received: from scott-latitude-e6320.localnet (unknown [216.169.175.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DB4D820E409C; Sun, 24 Jun 2012 00:25:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 24 Jun 2012 00:25:53 -0400 Message-ID: <2247385.Tk8q9RaASz@scott-latitude-e6320> User-Agent: KMail/4.8.3 (Linux/3.2.0-25-generic-pae; KDE/4.8.3; i686; ; ) In-Reply-To: <2699025.dxO2HPotY4@scott-latitude-e6320> References: <2699025.dxO2HPotY4@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] RFC 4408 Test Ambiguities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 04:25:58 -0000 On Thursday, June 21, 2012 06:12:18 PM Scott Kitterman wrote: > As part of my preparations for uploading the initial WG draft of 4408bis, > I'm reviewing the SPF test suite for documented ambiguities that need > fixing (See http://tools.ietf.org/wg/spfbis/trac/ticket/5). > Here's one I've come up with that I don't know the correct solution for that > I think should be discussed: > > invalid-domain-empty-label: > description: >- > target-name that is a valid domain-spec per RFC 4408 but an invalid > domain name per RFC 1035 (empty label) must be treated as > non-existent. comment: >- > An empty domain label, i.e. two successive dots, in a mechanism > target-name is valid domain-spec syntax, even though a DNS query > cannot be composed from it. The spec being unclear about it, this could > either be considered a syntax error, or, by analogy to 4.3/1 and 5/10/3, > the mechanism chould be treated as a no-match. > spec: [4.3/1, 5/10/3] > helo: mail.example.com > host: 1.2.3.4 > mailfrom: foo@t10.example.com > result: [permerror, fail] > > The question is, should ".." be an error or an oddity that will never match > anything because you can't actually query for it. I lean towards the > former, but I think picking one matters more than which one we pick. > > invalid-domain-long-via-macro: > description: >- > target-name that is a valid domain-spec per RFC 4408 but an invalid > domain name per RFC 1035 (long label) must be treated as non-existent. > comment: >- > A domain label longer than 63 characters that results from macro > expansion in a mechanism target-name is valid domain-spec syntax (and > is not even subject to syntax checking after macro expansion), even though > a DNS query cannot be composed from it. The spec being unclear about it, > this could either be considered a syntax error, or, by analogy to 4.3/1 and > 5/10/3, the mechanism chould be treated as a no-match. spec: [4.3/1, > 5/10/3] > helo: "%%%%%%%%%%%%%%%%%%%%%%" > host: 1.2.3.4 > mailfrom: foo@t12.example.com > result: [permerror,fail] > > This is very simlar (too long versus non-existant). Once again, I think > picking one is the most important thing. I'm continuing my way through things towards posting a draft. The above is tracked as http://trac.tools.ietf.org/wg/spfbis/trac/ticket/22 and it has some suggested language. Scott K From spf2@kitterman.com Sat Jun 23 22:33:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0D221F8682 for ; Sat, 23 Jun 2012 22:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJBcuK8bsBl7 for ; Sat, 23 Jun 2012 22:33:26 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 76B6A21F8680 for ; Sat, 23 Jun 2012 22:33:26 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AF8BE20E40B9; Sun, 24 Jun 2012 01:33:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340516005; bh=5nrFuNEu825vzkEorFL2thSR0wah1B7pIFToX0qkWS8=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=Xw/Gh94srPUeAX2J2HTnO1Oj3dfmlOgYg+yZ2szOwHHTJ7la0ypbcYApbnjgnckwC sJ0TDgZBvIZo2HgnSEls1yGYlZqitjs2yy0d4Pz+zRz4g4qX8wGkS8dSHOwgzGSWsS bm2WM9ZhRfyZfd8XOW/O70mrj5UfIcF9LhbXkVE8= Received: from scott-latitude-e6320.localnet (unknown [216.169.175.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 921A620E409C; Sun, 24 Jun 2012 01:33:24 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sun, 24 Jun 2012 01:32:59 -0400 Message-ID: <1638743.cLUK3D7h0X@scott-latitude-e6320> User-Agent: KMail/4.8.3 (Linux/3.2.0-25-generic-pae; KDE/4.8.3; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 05:33:27 -0000 I've just submitted the -00, but it won't appear until after a manual push. I also reviewed the open tickets and statused them below. The ones that have been incorporated were all either altready done in my pre-WG draft or obvious fixes/issues that I didn't think were controversial and it the language changes were easy. I left the fun ones on the table. Scott K Ticket #1, RFC 4408 Section 2.5.6 - Temporary errors - language added Ticket #5, RFC 4408 ambiguities - Reviewed all multiple result tests in the test suite. Sent two to the list for discussion, made two changes, and don't believe the rest require changes in 4408bis due to them being in the test suite (some are addreesed on other tickets) Ticket #7, RFC 4408 Downcase result names in spec text and ABNF - There's a comment that makes reference to updating the MARF SPF reporting draft, but since the ABNF is actually case insensitive, I don't think was actually need to do that. Ticket #9 - RFC 4408 SPF RR type - Did NOT address Ticket #10 - RFC 4408 rplace Received-SPF with RFC5451 - Did NOT address Ticket #12 - RFC 4408 Section 9 - Forwarding and helo identities - Did NOT address Ticket #14 - RFC 4408: local-part macro prep for deprecation- Did NOT address Ticket #15 - RFC 4408: Section 2.2 Requirement to check mail from - Updated text Ticket #16 - RFC 4408: Section 8.1 Add %v macro to ABNF grammar - Fixed Ticket #18 - RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections - Already fixed in pre-WG draft Ticket #20 - RFC 4408: Section 4.6.1 unknown-modifier clause is too greedy in ABNF - Already fixed in pre-WG draft Ticket #21 - Already fixed in pre-WG draft Ticket #22 - Section 2.5.7 PermError on invalid domains after macro expansion - Subject of discussion on spfbis - Did NOT address Ticket #24 - RFC 4408: Reasonable DNS error limits - Did NOT address Ticket #25 - RFC 4408: Section 4.4 Parallel Query - Did NOT address, will probably go away with no action Ticket #26 - RFC 4408: Should the syntax checking of SPF records be relaxed at all - Did NOT address Ticket #27 - RFC 4408: Should the ptr: mechanism and the %{p} macro be deprecated - Marked ptr/'p' deprecated/SHOULD NOT use. Ticket #29 - RFC 4408: Section 2.5.4 - mark on fail - Did NOT address Ticket #6 - RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization - Did NOT address Ticket #13 - RFC 4408: Best-Guess SPF - Did NOT address Ticket #8 - RFC 4408 Mixed use of RFC2119 words - Fixed. Ticket #17 - RFC 4408: Section 7 Received-SPF examples use incorrect syntax - Already fixed in pre-WG draft Ticket #19 - RFC 4408: Section 7 Received-SPF examples use incorrect syntax - Already fixed in pre-WG draft Ticket#2 - RFC 4408 Section B.3 - Errata #2250 - Already fixed in pre-WG draft Ticket #3 - RFC 4408 - Errata #99 - Fixed or made OBE due to other changes in pre-WG draft Ticket #23 - RFC 4408: Typos - Already fixed in pre-WG draft From internet-drafts@ietf.org Sat Jun 23 23:29: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 E5B8E21F85DD; Sat, 23 Jun 2012 23:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLFPpn4uY1h2; Sat, 23 Jun 2012 23:29:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A8321F85CC; Sat, 23 Jun 2012 23:29:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120624062922.6465.98729.idtracker@ietfa.amsl.com> Date: Sat, 23 Jun 2012 23:29:22 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 06:29:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Dom= ains in E-Mail, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-00.txt Pages : 55 Date : 2012-06-23 Abstract: E-mail 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 reverse-path 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 a domain can explicitly authorize the hosts that are allowed to use its domain name, and a receiving host can check such authorization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vesely@tana.it Mon Jun 25 04:19:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EA121F84E6 for ; Mon, 25 Jun 2012 04:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.478 X-Spam-Level: X-Spam-Status: No, score=-4.478 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NVfmMRLypph for ; Mon, 25 Jun 2012 04:19:23 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8936F21F8476 for ; Mon, 25 Jun 2012 04:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1340623162; bh=PZw1xGvTDNNNOeFwprziag29iaJSAPloSP3USn3i84Q=; l=4346; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WoKkt7ju/66a0TZRrCevYDgZ+8427kO/EteMjNEn/rciIe0AWi1T7Ai60js6R6TsT GXQc3kDIsIMiu8xjk3HtJVhiO03KaITQe3+8vMarekki9V4YkWkkbuEjGgu70H/nEM 9Nrps5tGtqw4muP1ACkKVBCBtImm7N8XNCFJHA80= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 25 Jun 2012 13:19:22 +0200 id 00000000005DC039.000000004FE8493A.00005539 Message-ID: <4FE84939.4060706@tana.it> Date: Mon, 25 Jun 2012 13:19:21 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <1638743.cLUK3D7h0X@scott-latitude-e6320> In-Reply-To: <1638743.cLUK3D7h0X@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 11:19:28 -0000 On Sun 24/Jun/2012 07:32:59 +0200 Scott Kitterman wrote: > > Ticket #1, RFC 4408 Section 2.5.6 - Temporary errors - language added Do you mean the text appended to Section 4.4? It looks rather obscure, as it tries to convey a complex algorithm using too few words. (I don't think that referring to RFC 6555 would be useful, since the algorithm described there is about address families.) What exactly are we suggesting mail servers to do? > Ticket #5, RFC 4408 ambiguities - Reviewed all multiple result tests in the > test suite. Sent two to the list for discussion, made two changes, and don't > believe the rest require changes in 4408bis due to them being in the test > suite (some are addressed on other tickets) > Ticket #7, RFC 4408 Downcase result names in spec text and ABNF - There's a > comment that makes reference to updating the MARF SPF reporting draft, but > since the ABNF is actually case insensitive, I don't think was actually need > to do that. > Ticket #9 - RFC 4408 SPF RR type - Did NOT address > Ticket #10 - RFC 4408 replace Received-SPF with RFC5451 - Did NOT address > Ticket #12 - RFC 4408 Section 9 - Forwarding and helo identities - Did NOT > address I hope the ban against discussing reject-on-fail will be revoked. > Ticket #14 - RFC 4408: local-part macro prep for deprecation- Did NOT address > Ticket #15 - RFC 4408: Section 2.2 Requirement to check mail from - Updated > text The changed sentence looks garbled: SPF clients MUST check the "MAIL FROM" identity if a completed "HELO" check. SPF clients check has not reached a definitive policy result. One of the possible interpretations is that a "pass" on helo is enough, i.e. that the helo identity prevails, in some sense. That works for me. However, the example in the last but two paragraph of Section 2.4 ("if the reverse-path was null") seems to imply the opposite. > Ticket #16 - RFC 4408: Section 8.1 Add %v macro to ABNF grammar - Fixed > Ticket #18 - RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional > PermError rejections - Already fixed in pre-WG draft > Ticket #20 - RFC 4408: Section 4.6.1 unknown-modifier clause is too greedy in > ABNF - Already fixed in pre-WG draft > Ticket #21 - Already fixed in pre-WG draft > Ticket #22 - Section 2.5.7 PermError on invalid domains after macro expansion > - Subject of discussion on spfbis - Did NOT address > Ticket #24 - RFC 4408: Reasonable DNS error limits - Did NOT address > Ticket #25 - RFC 4408: Section 4.4 Parallel Query - Did NOT address, will > probably go away with no action > Ticket #26 - RFC 4408: Should the syntax checking of SPF records be relaxed at > all - Did NOT address > Ticket #27 - RFC 4408: Should the ptr: mechanism and the %{p} macro be > deprecated - Marked ptr/'p' deprecated/SHOULD NOT use. Works for me. For clarity, I'd suggest to also change the relevant entries in the mechanism list (Section 5) and in the macro list (Section 8.1) to read, e.g.: ptr: DEPRECATED and p = the validated domain name of : DEPRECATED Possibly, even the title of Section 5.5 can be changed that way. How about adding a short paragraph to Section 1.3 for the term "DEPRECATED"? A closed parenthesis is missing in using IPv4 mechanisms (i.e. "ip4" and "a". > Ticket #29 - RFC 4408: Section 2.5.4 - mark on fail - Did NOT address See above > Ticket #6 - RFC 4408 Section 10.1 - Processing limits needs clarification and > reorganization - Did NOT address > Ticket #13 - RFC 4408: Best-Guess SPF - Did NOT address > Ticket #8 - RFC 4408 Mixed use of RFC2119 words - Fixed. Does this have to be done thoroughly? In that case, there is: rejecting E-Mail from invalid domains should be considered. And there's a typo in a fix: "include" directive is generally be more appropriate. > Ticket #17 - RFC 4408: Section 7 Received-SPF examples use incorrect syntax - > Already fixed in pre-WG draft > Ticket #19 - RFC 4408: Section 7 Received-SPF examples use incorrect syntax - > Already fixed in pre-WG draft > Ticket#2 - RFC 4408 Section B.3 - Errata #2250 - Already fixed in pre-WG draft > Ticket #3 - RFC 4408 - Errata #99 - Fixed or made OBE due to other changes in > pre-WG draft > Ticket #23 - RFC 4408: Typos - Already fixed in pre-WG draft From spf2@kitterman.com Mon Jun 25 10:41:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C2E21F84EC for ; Mon, 25 Jun 2012 10:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MusvuGoQ3o7K for ; Mon, 25 Jun 2012 10:41:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 95E1121F8483 for ; Mon, 25 Jun 2012 10:41:43 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 74E1C20E40FC; Mon, 25 Jun 2012 13:41:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340646102; bh=LzNUA9u99SwkhH3Z55I7Gifo2nsCgQsDncMuhyN8U+Q=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=lF7IPsg8guNmJZksiq8UC+hrE6UjpGncHqrpsAmD9ud2l9klrlCRBNYVBR28okYF3 0WxRiXnsE7zmk6FJrkxf8p9VI+NJo4R+zT3/ygaz0C8Oo37UVhDpxd1mmWemGSj0i1 rGTT/JSxhN+W4o70ZWdgXYYTX2t/72C+uksBaF84= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5A16020E409D; Mon, 25 Jun 2012 13:41:42 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Jun 2012 13:41:41 -0400 Message-ID: <5343191.9jHsL2jNxL@scott-latitude-e6320> User-Agent: KMail/4.8.3 (Linux/3.2.0-25-generic-pae; KDE/4.8.3; i686; ; ) In-Reply-To: <1638743.cLUK3D7h0X@scott-latitude-e6320> References: <1638743.cLUK3D7h0X@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] Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 17:41:44 -0000 I seem to have neglected to mention it in my summary, but I also removed X- from the draft in anticipation of BCP 178, RFC 6648 that's just been published (Deprecating the "X-" Prefix and Similar Constructs in Application Protocols). Scott K From superuser@gmail.com Mon Jun 25 11:12:07 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 5968221F8462 for ; Mon, 25 Jun 2012 11:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMEogBEQCYXj for ; Mon, 25 Jun 2012 11:12:06 -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 5766521F8460 for ; Mon, 25 Jun 2012 11:12:06 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so7368323lbb.31 for ; Mon, 25 Jun 2012 11:12:01 -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=pbG0t/ODKBUBFV+XbBZz+pQqeBx/y3yC46cnQ/QRKxY=; b=Im5Xzz6do1mIurNGZ8mCux1/RP8btSOtS5OLJeLZ+O/8uVGTnKxJUCuLgmKJi/qygZ tzpOq5sfSeiDLDNw8JPkl5/UvtIiNzijkjErdIYsodc2pQ/8oYEyr1/pnLx78C63IXXv HELcimZpDIott9f0eCGkES0GF4y/F7sr8loidxNeg2jJkzLae8b9DOEs466qPfIpImGY iYF3SPZWl3/i6RuzQRgkLK3s+B5UcC3BnhbOe1EexfQaHJ5rBqU6sP0OPytMgdoRBJ+3 dnIEbvl2Qcoy/SATNvfS3hX9KXSiprAD5V7IVzeYSGoUvIzdSgU1/UiIYudfQr+Vbxna 3f1g== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr13284084lab.9.1340647920890; Mon, 25 Jun 2012 11:12:00 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 25 Jun 2012 11:12:00 -0700 (PDT) In-Reply-To: <1638743.cLUK3D7h0X@scott-latitude-e6320> References: <1638743.cLUK3D7h0X@scott-latitude-e6320> Date: Mon, 25 Jun 2012 11:12:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=e89a8f22c41117f16504c34feb21 Cc: spfbis@ietf.org Subject: Re: [spfbis] Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 18:12:07 -0000 --e89a8f22c41117f16504c34feb21 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 23, 2012 at 10:32 PM, Scott Kitterman wrote: > I've just submitted the -00, but it won't appear until after a manual > push. I > also reviewed the open tickets and statused them below. The ones that have > been incorporated were all either altready done in my pre-WG draft or > obvious > fixes/issues that I didn't think were controversial and it the language > changes > were easy. I left the fun ones on the table. > > A few cursory observations until I carve out time for a full review: RFC4871 is obsolete; should be RFC6376 RFC2821 is obsolete; should be RFC5321 RFC2822 is obsolete; should be RFC5322 RFC4234 is obsolete; should be RFC5234 In 12.1, it's no longer a "new" record type. In 12.2, shouldn't the defining document for Received-SPF be RFC4408? The document refers to messages as "E-Mail". I'll pre-empt Dave by saying this should probably changed throughout to "email". A bunch of the terminology around roles in email can probably refer to RFC5598, especially when it comes to styles of forwarding since that's a sensitive topic with respect to SPF. For example, Section 9.3 of this document could make use of some of the terms and discussions in that document to paint a clear picture of what's going on and why it causes what are perceived as false negatives. More soon... -MSK --e89a8f22c41117f16504c34feb21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 23, 2012 at 10:32 PM, Scott Kitterma= n <spf2@kitterman.com> wrote:
I've just submitted the -00, but it won't appear until after a manu= al push. =A0I
also reviewed the open tickets and statused them below. =A0The ones that ha= ve
been incorporated were all either altready done in my pre-WG draft or obvio= us
fixes/issues that I didn't think were controversial and it the language= changes
were easy. =A0I left the fun ones on the table.


A few cursory observations until I carve out time= for a full review:

RFC4871 is obsolete; should be RFC6376
RFC282= 1 is obsolete; should be RFC5321
RFC2822 is obsolete; should be RFC5322<= br> RFC4234 is obsolete; should be RFC5234

In 12.1, it's no longer a= "new" record type.

In 12.2, shouldn't the defining do= cument for Received-SPF be RFC4408?

The document refers to messages = as "E-Mail".=A0 I'll pre-empt Dave by saying this should prob= ably changed throughout to "email".

A bunch of the terminology around roles in email can probably refer to = RFC5598, especially when it comes to styles of forwarding since that's = a sensitive topic with respect to SPF.=A0 For example, Section 9.3 of this = document could make use of some of the terms and discussions in that docume= nt to paint a clear picture of what's going on and why it causes what a= re perceived as false negatives.

More soon...

-MSK

--e89a8f22c41117f16504c34feb21-- From spf2@kitterman.com Mon Jun 25 11:38: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 4D81111E8089 for ; Mon, 25 Jun 2012 11:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BPjPl2hD-BU for ; Mon, 25 Jun 2012 11:38:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 93A7B11E8085 for ; Mon, 25 Jun 2012 11:38:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E82FA20E40FC; Mon, 25 Jun 2012 14:38:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340649509; bh=jOByhDeD9/wvDnJ/LH3KgfkZyO1wWtualedBltI7VG8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=XFLRwZuVEEs7C4fj6aKDpRFU+1vj37wgeU86mTW1GoCPXcH2G57jHQCJw3IefHFr+ OEVyYtegaMr6h3R537EQ1Zx9GPfRUfRzG1HpEhVH45/uiEmh3e9P2P/GQAcxsZb7tS 4zliDnNk964Pn/vgHumUKiV5fFkYLBlTGVicb4tY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C947E20E409D; Mon, 25 Jun 2012 14:38:29 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Jun 2012 14:38:29 -0400 Message-ID: <1914453.F4PorWEOV6@scott-latitude-e6320> User-Agent: KMail/4.8.3 (Linux/3.2.0-25-generic-pae; KDE/4.8.3; i686; ; ) In-Reply-To: <4FE84939.4060706@tana.it> References: <1638743.cLUK3D7h0X@scott-latitude-e6320> <4FE84939.4060706@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 18:38:31 -0000 On Monday, June 25, 2012 01:19:21 PM Alessandro Vesely wrote: > > Ticket #1, RFC 4408 Section 2.5.6 - Temporary errors - language added > > Do you mean the text appended to Section 4.4? It looks rather > obscure, as it tries to convey a complex algorithm using too few > words. (I don't think that referring to RFC 6555 would be useful, > since the algorithm described there is about address families.) Yes. I wasn't trying to specify what I would call an algorithm. There isn't an interoperability gain associated with everyone doing this identically. All we need to communicate is "You can treat repeated SERVFAIL for the same domain as permerror if you prefer." Suggestions welcome on text. Scott K From spf2@kitterman.com Mon Jun 25 11:46:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32ACE11E80A0 for ; Mon, 25 Jun 2012 11:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDYy8qS7HGTb for ; Mon, 25 Jun 2012 11:46:27 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 776B311E8089 for ; Mon, 25 Jun 2012 11:46:27 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DE58D20E40FC; Mon, 25 Jun 2012 14:46:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340649986; bh=p0HgrmmA5jK+UXevV8Kk3yD5C2sEm8EnGUQ3TRWWpKE=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=h5HCw5qjgPGoXypp855Bxvhm3sG1bWBKQiXKqOAW5MfgnqbsnnrEtbybSYk/ujeDx 27T/47POiYTC/KaQIbFlgtgS4v74hvj4DqoE09A2xyI0OwVPc8+Rr70yOWP9S+KlnZ MCHuRHNkXoyEmhTdzg0WW8NZvRe4cWowpgQAaH+I= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C2B2220E409D; Mon, 25 Jun 2012 14:46:26 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Jun 2012 14:46:26 -0400 Message-ID: <13275734.VBPGAXJuIv@scott-latitude-e6320> User-Agent: KMail/4.8.3 (Linux/3.2.0-25-generic-pae; KDE/4.8.3; i686; ; ) In-Reply-To: <4FE84939.4060706@tana.it> References: <1638743.cLUK3D7h0X@scott-latitude-e6320> <4FE84939.4060706@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 18:46:28 -0000 On Monday, June 25, 2012 01:19:21 PM Alessandro Vesely wrote: > The changed sentence looks garbled: > > SPF clients MUST check the "MAIL FROM" identity if a completed "HELO" > check. SPF clients check has not reached a definitive policy result. Yes. What I meant to say was: SPF clients MUST check the "MAIL FROM" identity if a completed "HELO" check has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the . Fixed locally. > One of the possible interpretations is that a "pass" on helo is > enough, i.e. that the helo identity prevails, in some sense. That > works for me. However, the example in the last but two paragraph of > Section 2.4 ("if the reverse-path was null") seems to imply the opposite. That is what I meant to convey. In software I develop one of the few ways I explicitly deviate from RFC 4408 is to not bother with checking Mail From if there's already a conclusion to reject based on HELO. It just wastes cycles. I don't think 2.4 implies the opposite. I think it applies if you are checking Mail From, but doesn't insist that you do so. Scott K From spf2@kitterman.com Mon Jun 25 12:01: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 6C36F21F85B5 for ; Mon, 25 Jun 2012 12:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0uaujKHLx47 for ; Mon, 25 Jun 2012 12:01:45 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B4D4121F8493 for ; Mon, 25 Jun 2012 12:01:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 79CAB20E40FC; Mon, 25 Jun 2012 15:01:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340650903; bh=SYPkkZsNWi+PxshoBvh4815pFG5GmiWxQXwLSNmyrdA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=i0SnV3mVg9w03UqhOGbcbzKW2MjFgH9eBUmUZXvT528J1ZrfIAVJb6U9WW+Wb0rDm AlelBWP8ONnjc93FLowHEpUvEILlwjpk7bThPgayqhlpsuVGeSGgFuhcF+pJFrHMqN 0Pea8D8Mf0Sa3CF5C5IIKwh67GQbSpOrTJg7Akkc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5E8E520E409D; Mon, 25 Jun 2012 15:01:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Jun 2012 15:01:42 -0400 Message-ID: <13682083.zYKqn5fuPU@scott-latitude-e6320> User-Agent: KMail/4.8.3 (Linux/3.2.0-25-generic-pae; KDE/4.8.3; i686; ; ) In-Reply-To: <4FE84939.4060706@tana.it> References: <1638743.cLUK3D7h0X@scott-latitude-e6320> <4FE84939.4060706@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 19:01:46 -0000 On Monday, June 25, 2012 01:19:21 PM Alessandro Vesely wrote: > > Ticket #27 - RFC 4408: Should the ptr: mechanism and the %{p} macro be > > deprecated - Marked ptr/'p' deprecated/SHOULD NOT use. > > Works for me. For clarity, I'd suggest to also change the relevant > entries in the mechanism list (Section 5) and in the macro list > (Section 8.1) to read, e.g.: > > ptr: DEPRECATED > and > p = the validated domain name of : DEPRECATED > > Possibly, even the title of Section 5.5 can be changed that way. Done locally. > How about adding a short paragraph to Section 1.3 for the term > "DEPRECATED"? Is this really needed? I would have thought it's a sufficiently standard term we don't need it, perhaps I'm wrong. My definition is, imprecisely stated, "Continuing to use this is a bad idea. It's still supported for now, but may be removed without warning in the future." If people do think this is needed, suggestions on more precisely crafted text are welcome. > > A closed parenthesis is missing in > > using IPv4 mechanisms (i.e. "ip4" and "a". Fixed. Thanks, Scott K From spf2@kitterman.com Mon Jun 25 12:04:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CD011E80A0 for ; Mon, 25 Jun 2012 12:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AaUY6rWkQbC for ; Mon, 25 Jun 2012 12:04:41 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6E411E808C for ; Mon, 25 Jun 2012 12:04:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1F00620E40FC; Mon, 25 Jun 2012 15:04:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340651081; bh=ZfM363c1pSl1cUjX9AmIozujZamg7FCwLAuZIoh4A94=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=kFS2FaglvkjDAbnFFn3G+bdL9IB0EzgAM3cWFZ7JAO3BPnyuF0Npm5pHLCq2eKpz8 4ZdmpUSHTvQC8qQ8Tlu9yzO32QR2LJXDm1kgWfaniqxZnQTHaFj6dYOMtZ4X9nmYm3 JnDXjtWBXlcF6WCT6yEfyrJwWW3dhd1Wk/UkXgPE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 017CF20E409D; Mon, 25 Jun 2012 15:04:40 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Jun 2012 15:04:40 -0400 Message-ID: <7248734.IiJpG9LAnF@scott-latitude-e6320> User-Agent: KMail/4.8.3 (Linux/3.2.0-25-generic-pae; KDE/4.8.3; i686; ; ) In-Reply-To: <4FE84939.4060706@tana.it> References: <1638743.cLUK3D7h0X@scott-latitude-e6320> <4FE84939.4060706@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 19:04:43 -0000 On Monday, June 25, 2012 01:19:21 PM Alessandro Vesely wrote: > > Ticket #8 - RFC 4408 Mixed use of RFC2119 words - Fixed. > > Does this have to be done thoroughly? In that case, there is: > > rejecting E-Mail from invalid domains should be considered. > > And there's a typo in a fix: > > "include" directive is generally be more appropriate. Thanks. Cleared that up locally. Scott K From sm@elandsys.com Mon Jun 25 15:12:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1211B21F8546 for ; Mon, 25 Jun 2012 15:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3--FBd3wSaZ for ; Mon, 25 Jun 2012 15:12:12 -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 201A321F853F for ; Mon, 25 Jun 2012 15:12:11 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5PMBuMk005053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jun 2012 15:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340662328; i=@elandsys.com; bh=BjsCa6999QDYYEYq4KhxHPlSb3S5ccl+doiRTzdQKJI=; h=Date:To:From:Subject:Cc; b=I+A5AmVBmp/OlM06RSECR9dOl5RF5bIdpWdf3vNMV8sfkAua9SM0A6XlBW7Hv6imu X/gN97RIq+YAtjFoMW056+WhPWyycqCmv0nfnqYpy7T9aoKlgzOBsOogEQAP/rGZh1 I85bX96O/nnYvDlldi1YnjuK0EYABzS3P0o4I9Mk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340662328; i=@elandsys.com; bh=BjsCa6999QDYYEYq4KhxHPlSb3S5ccl+doiRTzdQKJI=; h=Date:To:From:Subject:Cc; b=LQ4MKHGC9fXe8pPKyQN+KStMIAEW8BqQiB+2kK9dUdEi1M/i1XB8tW1s7eRhydB4k BMK0McBsDgPYCPiTK2BWV/B7SoZQYVwaAGRJa2V04Nkn2t834X+R5D3RUw7+pmqrQu dh9eZBGEFWfD2hsqrjuxKArudrBAccDiLS6PBz04= Message-Id: <6.2.5.6.2.20120625144612.09996160@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Jun 2012 15:11:29 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan , Scott Kitterman Subject: [spfbis] Moving forward with draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 22:12:16 -0000 Hello, The SPFBIS WG co-chairs posted a message on June 18 about the adoption of draft-ietf-spfbis-4408bis as a WG document. We currently have 27 open tickets in the tracker ( http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ). One of the WG co-chairs will be starting threads for each of the issues. The document editor can suggest text to start the discussion. If any WG participant would like to suggest text, feel free to do so. I'll try and start with the easy issues as it would be faster. Please keep to the thread so that it is easier to track. The document editor already posted a message about changes at http://www.ietf.org/mail-archive/web/spfbis/current/msg01604.html I'll use the issues listed in that message as a starting point. If you have any questions about how the work will be carried out, please post them to the list. Regards, S. Moonesamy From spf2@kitterman.com Mon Jun 25 15:20:07 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 0EF4A11E80AE for ; Mon, 25 Jun 2012 15:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROrPHRU3iiPU for ; Mon, 25 Jun 2012 15:20:06 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 53E4521F8596 for ; Mon, 25 Jun 2012 15:20:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C5F2E20E40FC; Mon, 25 Jun 2012 18:20:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340662805; bh=Ha0OwiRY3NxFhgSEKfOh2VgEEyzNqeX4Cay3sC5v1Cw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=WSAhtrxKiVlqpxFde1nyZ96WQoatdSW+46v31D0O4ZCabUcxVALBIrZIzTExesdnd Or99AumCUFDkn8toCa9jiIo89AnswAnEqFjU8Nm2SYV5903hIS6NjBiUdvw1qFHr7q TSVcDgb6Q4jnuUWwrdNrW83N/TbSw74nNBxyUYuk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ABBDB20E409D; Mon, 25 Jun 2012 18:20:05 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Jun 2012 18:20:05 -0400 Message-ID: <1659410.5cOOUtmPW1@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120625144612.09996160@elandnews.com> References: <6.2.5.6.2.20120625144612.09996160@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] Moving forward with draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 22:20:07 -0000 On Monday, June 25, 2012 03:11:29 PM S Moonesamy wrote: > If you have any questions about how the work will be carried out, > please post them to the list. As I mentioned in the message I sent to the list after I posted the -00 draft, quite a number of the issues in the tracker are, I believe, already resolved in the -00. Do you want me to update the tracker to reflect this status? How should we proceed? Rather than kick off a message thread per issue, it might be handy to dispose of the ones that can be marked done first? Scott K From sm@elandsys.com Mon Jun 25 15:50:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C1321F85C5 for ; Mon, 25 Jun 2012 15:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFdSelJHyJGP for ; Mon, 25 Jun 2012 15:50:46 -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 4FCF121F85C4 for ; Mon, 25 Jun 2012 15:50:45 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5PMoVQV013249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jun 2012 15:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340664643; i=@elandsys.com; bh=USfW1lZiNUkUixTLJTUB/XW12OpfuZYFbWH2yW1HD08=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=qoQjhGRx8mBWZeinFJPqT+bfjjdrH2NnucSAclhXHGPC8PtAWzNrPMBaNfg7ZSrwM GtQJKSXmh9tfVd6nXAIUM5j8qlwD89NTksvgLmzXk0TihoCpsR7ZVnYDpUrNltmvxl 8k8xSPMO3ypb1O2XG/7Pz7uI+nNmTswmuj3MxBqQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340664643; i=@elandsys.com; bh=USfW1lZiNUkUixTLJTUB/XW12OpfuZYFbWH2yW1HD08=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=JxGQWYFJbDOVvn5jmJx8Va+RaumvwtdC54nBgoZU1mCeoT9UcNMPNXNIVN7Cv3uds +ZMXiuMhF1T2/bFIuIWLSo2YP8JmB0xro81dT92dw8yqGqUQyssd85/B08O73UaOOl Q1pRSR+E+swwXO01fEIWcxx0KWAjCEG4mJQnLzfE= Message-Id: <6.2.5.6.2.20120625152457.080fe540@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Jun 2012 15:50:15 -0700 To: Scott Kitterman , spfbis@ietf.org From: S Moonesamy In-Reply-To: <1659410.5cOOUtmPW1@scott-latitude-e6320> References: <6.2.5.6.2.20120625144612.09996160@elandnews.com> <1659410.5cOOUtmPW1@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Moving forward with draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 22:50:47 -0000 Hi Scott, At 15:20 25-06-2012, Scott Kitterman wrote: >As I mentioned in the message I sent to the list after I posted the >-00 draft, >quite a number of the issues in the tracker are, I believe, already resolved >in the -00. Do you want me to update the tracker to reflect this >status? How >should we proceed? Rather than kick off a message thread per issue, it might >be handy to dispose of the ones that can be marked done first? It is easier for the WG if issues are not reopened once they are closed in the tracker unless there is new information available. The working group gets to see the change and anyone can discuss about that if we have those messages. Although it can be tedious process, it can be useful in future if we are asked about the resolution of an issue. I will start from the list of issues in the message you posted. I'll defer the ones about DNS in case they require more discussion. Let's wait a week before you update the tracker to reflect the status of the issues. Regards, S. Moonesamy From sm@elandsys.com Mon Jun 25 16:27:01 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 A3DC521F8546 for ; Mon, 25 Jun 2012 16:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUkROgRsnSKs for ; Mon, 25 Jun 2012 16:27:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 023FF21F8483 for ; Mon, 25 Jun 2012 16:27:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5PNQlYL008807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jun 2012 16:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340666819; i=@elandsys.com; bh=IFYIIZdAm+vhZCTv3BWbYF2EGfhgI4ZvPU3RUhY/PaU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=tCyuZ8eQ2s1uy8LywfrmW5NfGOps7XO/2vvP3pJ6A/Xs3u3Bwo5y3vauFFGH5BDgk 36n2rMy2+XyZVACECHwl+zTJQu4ovSS7XoKPXM421hp+qyNjYsM7CZEu10hmI0mC6i GEl33T2VrqJQBMqnYMftle+hnZmCotH2wJBmIagI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340666819; i=@elandsys.com; bh=IFYIIZdAm+vhZCTv3BWbYF2EGfhgI4ZvPU3RUhY/PaU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=13bdxlFJYEfWVSkqZpOtxtz3XeByvryPCoMREMw12LSFI5fkZ5o9GjdDl/8q/v7Zn 3U/O970CngvUM03FLAfnXBQdNB3OnN10m2WAvgMoS35bKLEmza22lm97w8oLze6RFO 1wqRr+uMfCBMagyYEAla8xb/ZAbWJEOXWJ/OmM/E= Message-Id: <6.2.5.6.2.20120625151738.093d5f68@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Jun 2012 15:28:05 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.bb6af19bdcb2318a15fc28af1a9e8b99@tools.ietf.org> References: <061.bb6af19bdcb2318a15fc28af1a9e8b99@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #15: RFC 4408: Section 2.2 Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 23:27:01 -0000 At 15:14 20-02-2012, spfbis issue tracker wrote: >#15: RFC 4408: Section 2.2 Requirement to check mail from From Section 2.2 of draft-ietf-spfbis-4408bis-00: SPF clients MUST check the "MAIL FROM" identity if a completed "HELO" check. SPF clients check has not reached a definitive policy result. The "MAIL FROM" identity by applying the check_host() function to the "MAIL FROM" identity as the Regards, S. Moonesamy From sm@elandsys.com Mon Jun 25 16:27: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 F1B6C11E808C for ; Mon, 25 Jun 2012 16:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.205 X-Spam-Level: X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, SARE_SUB_PCT_LETTER=0.784, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6ZubSjgbX6T for ; Mon, 25 Jun 2012 16:27:04 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2431C21F8562 for ; Mon, 25 Jun 2012 16:27:04 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5PNQlYN008807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jun 2012 16:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340666823; i=@elandsys.com; bh=S9h3/A+GP/yiyzKuRfV2P8ccdSlyKLVieL3nEGFnras=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=sq/M9iseHpDuOEjP19TTivIvme7jVtGmXKnMFiXLRG7EypyrOM8g4hNUKdjJ5Q61g 9Y6TMlqWAOAh/abn4fF8FLneMI0aPakkEovXRRLTkVCj1iHdDhub9K48PxhswToLiK egEFl5du29dlIg3WsnlriE8Ibia7WjKlzr0KTQw8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340666823; i=@elandsys.com; bh=S9h3/A+GP/yiyzKuRfV2P8ccdSlyKLVieL3nEGFnras=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=4NFUNvvkl2f1vgLlySFH6uKwZM8G4MpVYXqK3rxhKA1Ddi+4yWMhoUU1OtSofayLB dQATfJBNrFAhaGjjBgPcYKC1/x1+Njiqvo5z9NZp3Ryk+ud6LCF+G77nTqYYzluM8m 3jc608R/PsDpy5SwdEaKllvKOvhNSZVaV7m1T1bQ= Message-Id: <6.2.5.6.2.20120625155119.093d6ec8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Jun 2012 16:02:01 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120307000722.0e4798d8@elandnews.com> References: <061.f025e215c3de7379cf01e5e1dba0aa8e@tools.ietf.org> <6.2.5.6.2.20120307000722.0e4798d8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #16: RFC 4408: Section 8.1 Add %v macro to ABNF grammar X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 23:27:05 -0000 At 13:05 07-03-2012, S Moonesamy wrote: >>Ticket URL: > >I am going to classify Issue #16 as "hold for document update" (it >is better to discuss it when there is a 4480bis WG draft) . If >there are any objections, please post them to This issue has been addressed in the draft-ietf-spfbis-4408bis-00. Murray Kucherawy commented on updating the ABNF reference to RFC 5234 [1]. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg01608.html From sm@elandsys.com Mon Jun 25 16:30: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 07CC511E8114 for ; Mon, 25 Jun 2012 16:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXO6qdof3ZCR for ; Mon, 25 Jun 2012 16:30:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F7021F85AA for ; Mon, 25 Jun 2012 16:30:01 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5PNQlYR008807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jun 2012 16:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340666830; i=@elandsys.com; bh=wB2PDuDzHw4598uaSXXultb45muxJSuFQK6HzEBUULE=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=3l8Fg92YibdzWk6xZRZRRR+S8WNDTM2SgcMchhHfCw90ISG2cyG3U55liivs/AZkA 0vmNHKxi6zxXTJdhuTk9Lj9BydKmtULEmP1DSw3sdJurCYADYa081VYJuNapzf3N7B l1mRIuXN/iULNDwG9vI+aBXuyiGjzPpZ9Ji8vOpU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340666830; i=@elandsys.com; bh=wB2PDuDzHw4598uaSXXultb45muxJSuFQK6HzEBUULE=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=mzAhP0lfHPoRX0J957+HN/34Bzs3XNLWJf09M/ZbfQ3IjFJzhtyl/SktCHvehKLfR FCQv+AcVBo3UzLvmvsPqkzj2dpf6RlNm5XFg2GU7vrmN9TJOeWeY+fTNnShja98Cv1 0hGzg31Mpg9PYxk8ZH95ox4kNvltZywymcAMjIgs= Message-Id: <6.2.5.6.2.20120625160738.08f36698@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Jun 2012 16:10:43 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.05f032973cd80559600105ca827da0a1@tools.ietf.org> References: <061.05f032973cd80559600105ca827da0a1@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #20: RFC 4408: Section 4.6.1 unknown-modifier clause is too greedy in ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 23:30:04 -0000 At 08:15 21-02-2012, spfbis issue tracker wrote: >#20: RFC 4408: Section 4.6.1 unknown-modifier clause is too greedy in ABNF The text in Section 4.6.1 of draft-ietf-spfbis-4408bis-00 is as follows: unknown-modifier = name "=" macro-string ; where name is not any known modifier Regards, S. Moonesamy From sm@elandsys.com Mon Jun 25 16:30: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 122A811E8116 for ; Mon, 25 Jun 2012 16:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSCenPtg-zst for ; Mon, 25 Jun 2012 16:30:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB5A21F85AC for ; Mon, 25 Jun 2012 16:30:01 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5PNQlYT008807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jun 2012 16:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340666833; i=@elandsys.com; bh=i38XlaWrXRJmRl9AI6gx4kS3UPvPkDKvXFulFM8s9Gw=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=qLPXsdrI0IOWtieZr2T1v4qYo6yHUJQABQOvn+Ky23AuQTb2DB60+Gk/ZqIC5hRmE b724y0wYTbhyeH4NYWmS3oAuIlQs4UkX/zv310dOehDaJRTMfHw4hj5nkHpTkz4Now VuIuNdS2M8bYt7jbIC1q0FN0gu45PkfONiQ/lxkw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340666833; i=@elandsys.com; bh=i38XlaWrXRJmRl9AI6gx4kS3UPvPkDKvXFulFM8s9Gw=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ujkUCxEl7q3uugEQZvIUuPQnKiK8okjcK2A+8NPjH1mHg/v3Bkx5OSG5yQCUKqb19 jWaMS+ehV/j8sONyLJSs4EylNFZ5K3WcO74SwTo0ZFg09yPUUo3uwxOPvS+eunlG9k PsJcFwb4aMLEi8oK3gjiM0rsocHKL68jSZJAs9Jw= Message-Id: <6.2.5.6.2.20120625161304.081990b0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Jun 2012 16:17:18 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120220121621.09835f70@elandnews.com> References: <061.106923e4028c687741e1db9f5fb04a3a@tools.ietf.org> <6.2.5.6.2.20120220121621.09835f70@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #8: RFC 4408 Mixed use of RFC2119 words X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 23:30:04 -0000 At 13:26 20-02-2012, S Moonesamy wrote: >>Ticket URL: > >I'll classify this issue as "hold for document update". The >discussion can wait until the 4408bis draft is opened. Scott mentioned in his message about changes in -00 that the lower-case RFC 2119 key words were fixed. Regards, S. Moonesamy From sm@elandsys.com Mon Jun 25 16:30: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 26A8121F85AA for ; Mon, 25 Jun 2012 16:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEyub-4i0L2x for ; Mon, 25 Jun 2012 16:30:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C12311E808C for ; Mon, 25 Jun 2012 16:30:01 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5PNQlYV008807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jun 2012 16:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340666837; i=@elandsys.com; bh=GjTZKZ5I2F57ozUZSemmG6uXjEjKs1KFNGuf4EnEnjk=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=kB+sXJPGgl8SJs0mg0hL1Ou5FXpaUfYyv3vb2zdylAZWnRWQKiFFEMYX+dDypeAjY 3Gui2VotsPhLZ3CKLSR9Hyt1NM3uO4fiJDO6DqA7QUgrN/jGUHfaLXhas+dZyTVLMd xHC8Mws5gi6pb+sGyy5FsqA6gj1ThGOhG7gaXKrQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340666837; i=@elandsys.com; bh=GjTZKZ5I2F57ozUZSemmG6uXjEjKs1KFNGuf4EnEnjk=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ussB/Z57irXA9ccickiSseHEcYL244sQo4VZbHYzAynM9K5VoXIA4rWfu9X8RWg+h Z7ZbUUz5/jR8AGcLv+46e2uO7Ghi4tXaq1kRd1ac2UyW9PON2WrtrLyW0mWSqxp1La Wg6FycS3jvQjX1U4nJKL5ooAm/A1Dm1TZuFx/xhk= Message-Id: <6.2.5.6.2.20120625161851.08199340@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Jun 2012 16:21:12 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120229093632.0aa76cd0@elandnews.com> References: <061.64b0ba6d75582bbe683c5919ea3513b2@tools.ietf.org> <6.2.5.6.2.20120229093632.0aa76cd0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #19: RFC 4408: Section 7 Received-SPF examples use incorrect syntax X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 23:30:04 -0000 At 10:38 29-02-2012, S Moonesamy wrote: >>Ticket URL: > >I am going to classify Issue #19 as "Hold for document update". If >there are any objections, please post them to this mailing >list. BTW, the issue may be opened for The incorrect syntax in the examples in Section 7 was fixed in -00. Regards, S. Moonesamy From sm@elandsys.com Mon Jun 25 16:30: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 3670521F85AC for ; Mon, 25 Jun 2012 16:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkdNTF-qGy6d for ; Mon, 25 Jun 2012 16:30:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1431E21F85A8 for ; Mon, 25 Jun 2012 16:30:01 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5PNQlYP008807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jun 2012 16:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340666826; i=@elandsys.com; bh=BY552H+1bzsaaThxeO2fiemhp9lGAfRDH7EPcBQ+7qo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=O4W/GKS6lqfcbKw8CYD+Lxb2fER/eSXcB18uSlbwzJgqz7qwl7jc1HIgclaSvjSKx n+8+RyxN7vWQkod8OgehvyRfvSeJoCY1jFsEjK7EJ38/vurWaBsg5sjD+57UI33+fx LkO7D2u8Vv9n324+TLalkUMIpbaQKmS0aNeeItLM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340666826; i=@elandsys.com; bh=BY552H+1bzsaaThxeO2fiemhp9lGAfRDH7EPcBQ+7qo=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=rS4zUWj/MfJs2sDgCPXLFwv7cL6o7rFd9rNG5paRXxXwQM+orY6zgrwtI/YOw2Z76 rcxDqBO49n5d3IzYl8+S3zura0pkqgpEgOT6iA0i0eWPzOQfWsIrnFHTGvzJI1DGMk XNlfrWRJlW5KeIJ9leBz+BQXdBy9qpQyWEf7WOmc= Message-Id: <6.2.5.6.2.20120625160245.08f36408@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Jun 2012 16:06:49 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <061.8c71528b77bd471c792d11887cb3b78d@tools.ietf.org> References: <061.8c71528b77bd471c792d11887cb3b78d@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 23:30:04 -0000 At 08:10 21-02-2012, spfbis issue tracker wrote: >#18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for >optional PermError >rejections This is the current text in Section 2.5.7 of draft-ietf-spfbis-4408bis-00: A "permerror" result means that the domain's published records could not be correctly interpreted. This signals an error condition that requires manual intervention to be resolved, as opposed to the temperror result. If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 550 and, if supported, the 5.5.2 DSN code. Be aware that if the domain owner uses macros (Section 8), it is possible that this result is due to the checked identities having an unexpected format. Regards, S. Moonesamy From sm@elandsys.com Mon Jun 25 16:30: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 6B65521F85A8 for ; Mon, 25 Jun 2012 16:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibP3mao+MqCd for ; Mon, 25 Jun 2012 16:30:04 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8795911E80BB for ; Mon, 25 Jun 2012 16:30:01 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5PNQlYX008807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jun 2012 16:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340666841; i=@elandsys.com; bh=cIo11lQ23VQO/erUnB/JSSJUKKSvCzEyfizxXcYV7y0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=GzFjL6yj7LiuLHZYhTb5T5bYtpYJtAKrnXZMoiDIRWf01Re93ZgZmrxdXjwikLCr2 Ce9TvyoJRvoxYCpPDB5KQ/JUNp7QSqO/PmEzpMS7o9Jag6gXNQl9bknmjEoJbEIfUb GePLoqLXwVRbCv8CDHoIYO+lGpGsxrQdWPcGR8HM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340666841; i=@elandsys.com; bh=cIo11lQ23VQO/erUnB/JSSJUKKSvCzEyfizxXcYV7y0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=4bK0LzJAeTvy1PqG6k7RR+W12grrk+zpes3f46pIOAG/IyzOyUh24uprgU0lawOU5 dacCHaK/Zj6uR2IpCS852Y02gefV3augZwOE1OyQm6Sr72C3wnmmcFatgVEH9HvaQ9 J8l8268MwzohXBylhf80YQF4R59l1goBAN9osYvE= Message-Id: <6.2.5.6.2.20120625162156.081995d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Jun 2012 16:23:23 -0700 To: Scott Kitterman , spfbis@ietf.org From: S Moonesamy In-Reply-To: <4541043.FAKVWqEuLc@scott-latitude-e6320> References: <061.c05ace881b9d1ba34bcbb6f922d09b7e@tools.ietf.org> <6.2.5.6.2.20120220120125.08d4afe8@elandnews.com> <4541043.FAKVWqEuLc@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #3: RFC 4408 - Errata #99 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 23:30:04 -0000 Hi Scott, At 13:25 20-02-2012, Scott Kitterman wrote: >The I.D. that I prepared as the input document for the working group has the >editorial errata corrected already. It might be simpler to start from that. As there isn't any IESG Note in the draft, we can close this one. Regards, S. Moonesamy From sm@elandsys.com Mon Jun 25 16:30: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 83AA621F85AA for ; Mon, 25 Jun 2012 16:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f98YeKkpGV+0 for ; Mon, 25 Jun 2012 16:30:04 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B256811E8109 for ; Mon, 25 Jun 2012 16:30:01 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5PNQlYZ008807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jun 2012 16:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340666845; i=@elandsys.com; bh=XxoR3528xq5yrz03qHbgOcYy10xhD5SugM5GnHHSkv0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=yEJVfFtY70rHgwvppq1X3aiU2wluoXJ1UC2ZGLN6mP2TjwluX5onoUmbJ1p+4aXiK vSubLohMhi7+V6HITG7sTY0QxmnmFAFZiKNCLaeP4tjcIezv/Z1kb7vxgBi4fFSlQH slTIRGaSjTkYU8or5YqJ1QCVpBvEshUmRN5WILbs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340666845; i=@elandsys.com; bh=XxoR3528xq5yrz03qHbgOcYy10xhD5SugM5GnHHSkv0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=2Pq5UMhV05Dov6opFhC5mnG48vKi8BZoB6pgvp4VvSUgq3qVGjsnz5Sj+qbmFN9AV XI98clVs2Bnd8QDOaDNLKIgtCtb3qQpLPsV+7RZutSNnGW+GNrwq8Me9+Y4+U36GOp kgBiykzVGSjNwGQ9qr1c9xvrzL5yoxrICIstPdWU= Message-Id: <6.2.5.6.2.20120625162357.08199860@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Jun 2012 16:26:11 -0700 To: spfbis@ietf.org, Scott Kitterman From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120229094019.0aa76a40@elandnews.com> References: <061.3a7be166b4161bed289082563f6dd187@tools.ietf.org> <6.2.5.6.2.20120229094019.0aa76a40@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #23: RFC 4408: Typos X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 23:30:04 -0000 Hi Scott, At 10:41 29-02-2012, S Moonesamy wrote: >>Ticket URL: > >I am going to classify Issue #23 as editorial. If there are any >objections, please post them to this mailing list. We can close this one as you already fixed it in the draft. Regards, S. Moonesamy From superuser@gmail.com Mon Jun 25 20:22:52 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 783BB21F847F for ; Mon, 25 Jun 2012 20:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2ljnRc4qBDV for ; Mon, 25 Jun 2012 20:22:50 -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 3586821F8447 for ; Mon, 25 Jun 2012 20:22:50 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so7928739lbb.31 for ; Mon, 25 Jun 2012 20:22:49 -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=qZeIqZdRCVCL8nUbKNH507zL2J1gtHwOzR7MbnUfM+k=; b=lm3GeyZmbvi3YhcmfBhsRxF+fU6Gk7Nd+r1Qiwt93OEsQ21ouylt76aRGbmdQAP0IU q4M9kGxyuvjODvxjx5HcHWpknc0G6TxKd0JAwqzZ9yn3lW4biUIH24LDT7fvg77R5Lsd EVBXUTyBUUZGIfKWrnmS0f8CqtOlKJQ0UBP0F+IXUSEritVKUbRKpQvNW2SLKA9z6cfA B1cg0CEBCtOV0xu96ydTOuZlJMrKBRIvt4zlTcmUB05U0HNDJF6MrrCShU8ihudrH1bZ uRwHzPzBnTN5HipqvOgHvjQ61emN9BS0Wx/0NjXbH8OJhAQQitJ8Do+M0NvsSa9cwiIw ftrA== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr6846240lbn.10.1340680969166; Mon, 25 Jun 2012 20:22:49 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 25 Jun 2012 20:22:49 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120625160245.08f36408@elandnews.com> References: <061.8c71528b77bd471c792d11887cb3b78d@tools.ietf.org> <6.2.5.6.2.20120625160245.08f36408@elandnews.com> Date: Mon, 25 Jun 2012 20:22:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=bcaec554d63cec9e6304c3579c62 Cc: spfbis@ietf.org Subject: Re: [spfbis] #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 03:22:52 -0000 --bcaec554d63cec9e6304c3579c62 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 25, 2012 at 4:06 PM, S Moonesamy wrote: > At 08:10 21-02-2012, spfbis issue tracker wrote: > >> #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional >> PermError >> rejections >> > > This is the current text in Section 2.5.7 of draft-ietf-spfbis-4408bis-00: > > A "permerror" result means that the domain's published records could > not be correctly interpreted. This signals an error condition that > requires manual intervention to be resolved, as opposed to the > temperror result. If the message is rejected during the SMTP > transaction for this reason, the software SHOULD use an SMTP reply > code of 550 and, if supported, the 5.5.2 DSN code. Be aware that if > the domain owner uses macros (Section 8), it is possible that this > result is due to the checked identities having an unexpected format. > > Just curious: What's the logic behind using a permanent error on an SPF record interpretation failure? Isn't this the kind of situation in which a tempfail makes more sense, allowing the publishing domain an opportunity to fix a broken record? -MSK --bcaec554d63cec9e6304c3579c62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jun 25, 2012 at 4:06 PM, S Moonesamy <sm+ietf@elandsys.com= > wrote:
At 08:10 21-02-2012, spfbis issue tracker wrote:
#18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional Perm= Error
rejections

This is the current text in Section 2.5.7 of draft-ietf-spfbis-4408bis-00:<= br>
=A0 A "permerror" result means that the domain's published r= ecords could
=A0 not be correctly interpreted. =A0This signals an error condition that<= br> =A0 requires manual intervention to be resolved, as opposed to the
=A0 temperror result. =A0If the message is rejected during the SMTP
=A0 transaction for this reason, the software SHOULD use an SMTP reply
=A0 code of 550 and, if supported, the 5.5.2 DSN code. =A0Be aware that if=
=A0 the domain owner uses macros (Section 8), it is possible that this
=A0 result is due to the checked identities having an unexpected format.

Just curious: What's the logic behind using a= permanent error on an SPF record interpretation failure?=A0 Isn't this= the kind of situation in which a tempfail makes more sense, allowing the p= ublishing domain an opportunity to fix a broken record?

-MSK

--bcaec554d63cec9e6304c3579c62-- From spf2@kitterman.com Mon Jun 25 20:37:21 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 B066921F847E for ; Mon, 25 Jun 2012 20:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22JP9q3yPlAP for ; Mon, 25 Jun 2012 20:37:21 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 02BA821F8452 for ; Mon, 25 Jun 2012 20:37:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 82A2C20E40FC; Mon, 25 Jun 2012 23:37:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340681840; bh=htjt+zr4LAd/cG7yRi+HzoKZEiLf7ZEmGw3hOkaDbK8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=g/dzN+AWMGR7+w+7ATHyV3Wq/VNGuimN6uoa3XVhYA4RTnojeBoEcRdlviEQ53daH 5KhW3xvbQi7bA1SLX5U+uSQ6zuQPRkEQCz2kiO1Eu/Ib+UfJBcSTm1fhMkDnw8L19t FU/qwp6X1T4g7swI4z5p3njspAbquvyasreEPaaw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 64AC820E409D; Mon, 25 Jun 2012 23:37:20 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Jun 2012 23:37:19 -0400 Message-ID: <4790374.YA5eHke4su@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <061.8c71528b77bd471c792d11887cb3b78d@tools.ietf.org> <6.2.5.6.2.20120625160245.08f36408@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] #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 03:37:21 -0000 On Monday, June 25, 2012 08:22:49 PM Murray S. Kucherawy wrote: > On Mon, Jun 25, 2012 at 4:06 PM, S Moonesamy wrote: > > At 08:10 21-02-2012, spfbis issue tracker wrote: > >> #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional > >> PermError > >> rejections > > > > This is the current text in Section 2.5.7 of draft-ietf-spfbis-4408bis-00: > > A "permerror" result means that the domain's published records could > > not be correctly interpreted. This signals an error condition that > > requires manual intervention to be resolved, as opposed to the > > temperror result. If the message is rejected during the SMTP > > transaction for this reason, the software SHOULD use an SMTP reply > > code of 550 and, if supported, the 5.5.2 DSN code. Be aware that if > > the domain owner uses macros (Section 8), it is possible that this > > result is due to the checked identities having an unexpected format. > > Just curious: What's the logic behind using a permanent error on an SPF > record interpretation failure? Isn't this the kind of situation in which a > tempfail makes more sense, allowing the publishing domain an opportunity to > fix a broken record? temperror is for transient problems that will fix on their own. permerror's need operator intervention to fix. If receivers reject on permerror then the receiver is more inclined to notice (I'm not claiming this is a common practice, just giving the theory) than they would if a message was delayed. Eventually deferred meesages time out of the queue anyway, so temperrors eventually turn into rejects anyway. Scott K From scott@kitterman.com Mon Jun 25 20:34:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B66121F8551 for ; Mon, 25 Jun 2012 20:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLWvuVINPl5h for ; Mon, 25 Jun 2012 20:34:19 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 58EED21F8549 for ; Mon, 25 Jun 2012 20:34:19 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 81A6A20E40FC; Mon, 25 Jun 2012 23:34:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340681658; bh=PXfl49oDC4al/MsS7MsQzqVAgj5QpssJNVnVr57ceIY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=p7yDWqkZxHg6N7OgsLZqeZSoHE3dHM91ogi1Afl5u0ZzgJdqFujwRW90kZfjZsLSM 9YHktONUgm8dyS9cw+jQjeSCAk4LaBmdXV0mY22Rc2Q8d+bwNQuZL4eAd0lfjD6/Mt +oDQHYoh5xNthb9RXbJcyl5FWdLZPpGytjMOA0sQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6232020E409D; Mon, 25 Jun 2012 23:34:18 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 25 Jun 2012 23:34:17 -0400 Message-ID: <6542135.Yx4vvabbRL@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120625151738.093d5f68@elandnews.com> References: <061.bb6af19bdcb2318a15fc28af1a9e8b99@tools.ietf.org> <6.2.5.6.2.20120625151738.093d5f68@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Mon, 25 Jun 2012 22:22:32 -0700 Subject: Re: [spfbis] #15: RFC 4408: Section 2.2 Requirement to check mail from X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 03:34:20 -0000 On Monday, June 25, 2012 03:28:05 PM S Moonesamy wrote: > At 15:14 20-02-2012, spfbis issue tracker wrote: > >#15: RFC 4408: Section 2.2 Requirement to check mail from > > From Section 2.2 of draft-ietf-spfbis-4408bis-00: > > SPF clients MUST check the "MAIL FROM" identity if a completed "HELO" > check. SPF clients check has not reached a definitive policy result. > The "MAIL FROM" identity by applying the check_host() function to the > "MAIL FROM" identity as the As mentioned earlier, I made a bit of a hash of this. What I currently have locally is: SPF clients MUST check the "MAIL FROM" identity if a completed "HELO" check has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the . Scott K From sm@resistor.net Mon Jun 25 23:21:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6147E21F855E for ; Mon, 25 Jun 2012 23:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsxsvZqJYzHI for ; Mon, 25 Jun 2012 23:21:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEC121F855D for ; Mon, 25 Jun 2012 23:21:40 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5Q6LYv1023279 for ; Mon, 25 Jun 2012 23:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340691698; i=@resistor.net; bh=Lz4mxKE4I+QNSrJozea04KunAlYn296THeNGkVg/Ry0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=qbtAVdvIj3HXebSTkz95FcCc8AectBhiqcR/rDRyA3zyOOmaw/EpIABKkYbQuDG+B KbMbdoV1Bs+5hSaLuznMt2bm6IBmgGkurxhqtFOOonDdHOvM/gc/rR00LSDjTsXqLv F3EiYOuVIKpigpf80Va1yhDrCuZVa6MfSMVM+vXg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340691698; i=@resistor.net; bh=Lz4mxKE4I+QNSrJozea04KunAlYn296THeNGkVg/Ry0=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=UxkMhSK++jEIz1RQKDsejYfpR1gdgy2e21aanBF8411CNayDBMj+kP34BNoNsLnjF rGpGCt8M2Fejy6dFLtWmDtJsEUTJaeLdk4XJ2JZxZikSeCy06JT3huP3X6v3dfIrM+ Hpe0DcCA8fSP+AnU69qQeHQx790YqSSLJ+kO/SRs= Message-Id: <6.2.5.6.2.20120625225554.080da220@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 25 Jun 2012 23:15:59 -0700 To: spfbis@ietf.org From: SM In-Reply-To: <4790374.YA5eHke4su@scott-latitude-e6320> References: <061.8c71528b77bd471c792d11887cb3b78d@tools.ietf.org> <6.2.5.6.2.20120625160245.08f36408@elandnews.com> <4790374.YA5eHke4su@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 06:21:42 -0000 The text mentions "DSN code". There is a previous reference to RFC 3464. The usage of "DSN" is incorrect as the code is being generated during a SMTP session. The appropriate reference is RFC 3463 and it's an "enhanced status code". A question which came to my mind as I read the text is why is a "SHOULD" used. Regards, -sm From vesely@tana.it Tue Jun 26 03:47:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B7E21F8606 for ; Tue, 26 Jun 2012 03:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.5 X-Spam-Level: X-Spam-Status: No, score=-4.5 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sudll+YBAO0u for ; Tue, 26 Jun 2012 03:47:57 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4390321F85FF for ; Tue, 26 Jun 2012 03:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1340707674; bh=qQBG1H5XG8mZOiG6qQsEb76ItnfpidNodQH6wMO3EJU=; l=1795; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=BD4RsJfMW0Y+O/0cVu15V3pWYxb2NtgGTH2dxc/5KZJaKCCRNcpG3NQ16JneZag7f Rtf1Z0bZWme3HLf2naKVKC7ZzuYwE0iS5xU6VT7uQGTQYFEyFKoFDSX9Uh2uzaTjIb nB7M5iysoxt6V5ipFkxkADJ6dZkGLWze535k05hM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 26 Jun 2012 12:47:54 +0200 id 00000000005DC033.000000004FE9935A.00002019 Message-ID: <4FE9935A.2070004@tana.it> Date: Tue, 26 Jun 2012 12:47:54 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <1638743.cLUK3D7h0X@scott-latitude-e6320> <4FE84939.4060706@tana.it> <1914453.F4PorWEOV6@scott-latitude-e6320> In-Reply-To: <1914453.F4PorWEOV6@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors, was Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 10:47:58 -0000 On Mon 25/Jun/2012 20:38:29 +0200 Scott Kitterman wrote: > On Monday, June 25, 2012 01:19:21 PM Alessandro Vesely wrote: >>> Ticket #1, RFC 4408 Section 2.5.6 - Temporary errors - language added >> >> Do you mean the text appended to Section 4.4? It looks rather >> obscure, as it tries to convey a complex algorithm using too few >> words. (I don't think that referring to RFC 6555 would be useful, >> since the algorithm described there is about address families.) > > Yes. > > I wasn't trying to specify what I would call an algorithm. There isn't an > interoperability gain associated with everyone doing this identically. All we > need to communicate is "You can treat repeated SERVFAIL for the same domain as > permerror if you prefer." Servers don't have to behave identically, but consistently. The risk of playing sorcerer's apprentice with that is to obtain undesired, non-compliant behavior. But I don't think DNS servers would go off the beaten track by using negative caching parameters far from those specified by RFC 2308. OTOH, it seems to be a good idea for a mail server to keep track of the domain names that it interacts with, in general. This case is so marginal --because both the SPF RRTYPE and reject-on-fail are such-- that it doesn't justify the creation of a database. However, if a server already uses one, it may add a couple of fields for treating this case. > Suggestions welcome on text. Two: s/Alternately/Alternatively/. Add an explanation, such as: That is not intended to save further queries, which MUST be done according to RFC 2308, but to return a permanent negative completion reply code to the client, instead of a transient one, thereby shortening the queue time of messages that cannot be accepted. From vesely@tana.it Tue Jun 26 03:48:50 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 45E0921F85FF for ; Tue, 26 Jun 2012 03:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.518 X-Spam-Level: X-Spam-Status: No, score=-4.518 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7TuXj-eOQGU for ; Tue, 26 Jun 2012 03:48:49 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8059C21F85FD for ; Tue, 26 Jun 2012 03:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1340707729; bh=u82x+lUpr2HuB4b8sc3bh2oCplvY+anEaUjW8vsxfxk=; l=1539; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=YipKrzQy1VP1aoXM+zHbvfIX0e3IyBiLQrFaJN3hFo9j0IrE+037AxMpr0U85QdZq z0bkMgdPyhX0Otp4FOnj49hmQq8zAXVDb2yvL+4lo3HwsjlD8IoMNK5m/Ca+mSJ+I2 z1W3yGFsJkGh9VOt/+I8AZdK5cNTmojQhlai78gw= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 26 Jun 2012 12:48:48 +0200 id 00000000005DC033.000000004FE99390.0000206E Message-ID: <4FE99390.8080106@tana.it> Date: Tue, 26 Jun 2012 12:48:48 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <1638743.cLUK3D7h0X@scott-latitude-e6320> <4FE84939.4060706@tana.it> <13275734.VBPGAXJuIv@scott-latitude-e6320> In-Reply-To: <13275734.VBPGAXJuIv@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] #15: RFC 4408: Section 2.2 Requirement to check mail from, was Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 10:48:50 -0000 On Mon 25/Jun/2012 20:46:26 +0200 Scott Kitterman wrote: > On Monday, June 25, 2012 01:19:21 PM Alessandro Vesely wrote: >> One of the possible interpretations is that a "pass" on helo is >> enough, i.e. that the helo identity prevails, in some sense. That >> works for me. However, the example in the last but two paragraph of >> Section 2.4 ("if the reverse-path was null") seems to imply the opposite. > > That is what I meant to convey. In software I develop one of the few ways I > explicitly deviate from RFC 4408 is to not bother with checking Mail From if > there's already a conclusion to reject based on HELO. It just wastes cycles. You are apparently assuming that the result is failure irrespectively of the result of checking the other identity. We have no provisions for computing a global result from the separate results of checking both identities. IMHO we should. However, the results table looks ugly even if I only put the results for which I have an argument for. Can you fix or complete it? HELO | MAIL FROM | -----------+-----------+----- pass | pass | pass SNN* | pass | pass fail | pass | fail ERR** | pass | ? pass | SNN* | ? SNN* | SNN* | SNN* fail | SNN* | fail ERR** | SNN* | ? pass | fail | fail*** SNN* | fail | fail fail | fail | fail ERR** | fail | ? pass | ERR** | ? SNN* | ERR** | ? fail | ERR** | fail ERR** | ERR** | ERR** * SNN = softfail, neutral, or none ** ERR = temperror or permerror *** this failure shouldn't trigger rejection, IMHO From spf2@kitterman.com Tue Jun 26 06:17: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 E442F21F8642 for ; Tue, 26 Jun 2012 06:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKiDuFeii3J0 for ; Tue, 26 Jun 2012 06:17:55 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 28B1321F85F6 for ; Tue, 26 Jun 2012 06:17:54 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id F004F20E40FC; Tue, 26 Jun 2012 09:17:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340716674; bh=V+BnOPKeE63isJcfQk7cw2RWvip+MYkCoNWWLLXSXtI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=KGpO9AvrdTJvkMuPUvRvQ7WE5AT8em/d95pYN6cDNB0RAdfLS4pgAvIovsVp3xhak Ho4VlIzTpEx0Y2U8wIviJr9ALWcXHpZQq26yIrxX9K5hh+8FNqch6tCAt9Lj4REL+0 eHUxGnq0sBfyVjmiZaaZR83Ke4fBMrv4ZFwFgYxA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D17B620E4091; Tue, 26 Jun 2012 09:17:53 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 26 Jun 2012 09:17:53 -0400 Message-ID: <1729952.sOuomEOuAL@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <1638743.cLUK3D7h0X@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] Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 13:17:56 -0000 On Monday, June 25, 2012 11:12:00 AM Murray S. Kucherawy wrote: > On Sat, Jun 23, 2012 at 10:32 PM, Scott Kitterman wrote: > > I've just submitted the -00, but it won't appear until after a manual > > push. I > > also reviewed the open tickets and statused them below. The ones that > > have > > been incorporated were all either altready done in my pre-WG draft or > > obvious > > fixes/issues that I didn't think were controversial and it the language > > changes > > were easy. I left the fun ones on the table. > > A few cursory observations until I carve out time for a full review: > > RFC4871 is obsolete; should be RFC6376 Removed this entirely as it's not referenced anywhere anymore. > RFC2821 is obsolete; should be RFC5321 > RFC2822 is obsolete; should be RFC5322 > RFC4234 is obsolete; should be RFC5234 Updated. > In 12.1, it's no longer a "new" record type. > > In 12.2, shouldn't the defining document for Received-SPF be RFC4408? Both fixed. Should the information about the modifier registry be copied from RFC 6652 into the IANA considerations for 4408bis and have 4408bis update 6652? > The document refers to messages as "E-Mail". I'll pre-empt Dave by saying > this should probably changed throughout to "email". Done. > A bunch of the terminology around roles in email can probably refer to > RFC5598, especially when it comes to styles of forwarding since that's a > sensitive topic with respect to SPF. For example, Section 9.3 of this > document could make use of some of the terms and discussions in that > document to paint a clear picture of what's going on and why it causes what > are perceived as false negatives. I agree. This will take a bit of work, so we should probably have an issue to track this if it doesn't fit an existing one. Scott K From spf2@kitterman.com Tue Jun 26 06:27:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6202E21F856D for ; Tue, 26 Jun 2012 06:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh7Ou+wEex-0 for ; Tue, 26 Jun 2012 06:27:16 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BDBFF21F853E for ; Tue, 26 Jun 2012 06:27:16 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 52C4720E40FC; Tue, 26 Jun 2012 09:27:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340717236; bh=SDOgVhzsiS+PNpq1tt+wc5U/w1sDYuX24SD7c4A4cgk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=TuEC3AaMzJ5EH2vAQrcxOEAc1OrU9JwjWOkK8T4cW4QQFPJsfEi+jC5W0EDgS+Wjd VJGoS2H0Og6GzpupvW85OXbedO0O62cDbYJQ43aNkmv8Y/akx2gCoGWhIari+JXOq8 69VtnsTCtgsbmZNh1slk7cMwjhwHKR9wTf5eE1A4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 353D520E4091; Tue, 26 Jun 2012 09:27:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 26 Jun 2012 09:27:15 -0400 Message-ID: <1431561.9ffxbEmL34@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120625225554.080da220@resistor.net> References: <061.8c71528b77bd471c792d11887cb3b78d@tools.ietf.org> <4790374.YA5eHke4su@scott-latitude-e6320> <6.2.5.6.2.20120625225554.080da220@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] #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 13:27:17 -0000 On Monday, June 25, 2012 11:15:59 PM SM wrote: > The text mentions "DSN code". There is a previous reference to RFC > 3464. The usage of "DSN" is incorrect as the code is being generated > during a SMTP session. The appropriate reference is RFC 3463 and > it's an "enhanced status code". Fixed. In section 10.5, Untrusted Information Sources, there is reference to DSN as well. Should that be changed to something else and if not should we still have a reference to RFC 3464 (and add it there)? > A question which came to my mind as I read the text is why is a "SHOULD" > used. Common use of status codes (normal and enhanced) promotes interoperability by making the source of email rejection/deferral more understandable to the sender trying to figure out why something failed, so this is something that implementations SHOULD do. I don't think MUST is appropriate since it's to support forensics and not normal operation (consistency in SPF results is a MUST, but not what status code is sent along with it). Scott K From spf2@kitterman.com Tue Jun 26 06:34:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C2C21F85F8 for ; Tue, 26 Jun 2012 06:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+PfIkiIKrFE for ; Tue, 26 Jun 2012 06:34:18 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7074D21F85CE for ; Tue, 26 Jun 2012 06:34:18 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 04A8320E40FC; Tue, 26 Jun 2012 09:34:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340717658; bh=It6hCqsiOhvj5cx3U9Sc7tJ6dgeFzxXYEA0cLgEQtrs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Cu1dDL+eHHqvHXF2lvzROUTc2D2xkJLB3tp/crk1fSXoK10YXDna1H1DUgMKyCbYi 5Lv11YcMRbP0RlmuuZ2LzBxuTcAWXmUS00meigwEpRKrZDeSuPpWMO/KZ68jFG3zo6 21yOw22BhtQhBHSGaRg1C4dE301t62DUQKj61ewc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D9BA420E4091; Tue, 26 Jun 2012 09:34:17 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 26 Jun 2012 09:34:17 -0400 Message-ID: <1641244.uJ4vsDShP5@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FE99390.8080106@tana.it> References: <1638743.cLUK3D7h0X@scott-latitude-e6320> <13275734.VBPGAXJuIv@scott-latitude-e6320> <4FE99390.8080106@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #15: RFC 4408: Section 2.2 Requirement to check mail from, was Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 13:34:19 -0000 On Tuesday, June 26, 2012 12:48:48 PM Alessandro Vesely wrote: > On Mon 25/Jun/2012 20:46:26 +0200 Scott Kitterman wrote: > > On Monday, June 25, 2012 01:19:21 PM Alessandro Vesely wrote: > >> One of the possible interpretations is that a "pass" on helo is > >> enough, i.e. that the helo identity prevails, in some sense. That > >> works for me. However, the example in the last but two paragraph of > >> Section 2.4 ("if the reverse-path was null") seems to imply the opposite. > > > > That is what I meant to convey. In software I develop one of the few ways > > I explicitly deviate from RFC 4408 is to not bother with checking Mail > > From if there's already a conclusion to reject based on HELO. It just > > wastes cycles. > You are apparently assuming that the result is failure irrespectively > of the result of checking the other identity. We have no provisions > for computing a global result from the separate results of checking > both identities. IMHO we should. However, the results table looks > ugly even if I only put the results for which I have an argument for. > Can you fix or complete it? > > HELO | MAIL FROM | > -----------+-----------+----- > pass | pass | pass > SNN* | pass | pass > fail | pass | fail > ERR** | pass | ? > pass | SNN* | ? > SNN* | SNN* | SNN* > fail | SNN* | fail > ERR** | SNN* | ? > pass | fail | fail*** > SNN* | fail | fail > fail | fail | fail > ERR** | fail | ? > pass | ERR** | ? > SNN* | ERR** | ? > fail | ERR** | fail > ERR** | ERR** | ERR** > > * SNN = softfail, neutral, or none > ** ERR = temperror or permerror > *** this failure shouldn't trigger rejection, IMHO This is not by accident. The two sets of results have different semantics and can be used for local policy in different ways. RFC 4408 specified the minimum interaction between the two identities for interoperability (If Mail From is null, use HELO in it's place) and no more. The rest of the integration between the results for the two identities is left to local policy. Unless we decide to go further into receiver policy in 4408bis than RFC 4408 did (and I recommend we don't) then I think specifying the integration of the two identities is not something we should do. It is not unheard of to take different local policy actions for a particular SPF result for Mail From or HELO. As an example, I maintain software that (by default - it's all configurable) will reject on SPF fail for Mail From or on SPF fail/softfail/neutral for HELO/EHLO. An integrated result would be counter- productive for me. Scott K From spf2@kitterman.com Tue Jun 26 06:41:52 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 F332921F85F1 for ; Tue, 26 Jun 2012 06:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QirICVb3slPy for ; Tue, 26 Jun 2012 06:41:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 124D221F860E for ; Tue, 26 Jun 2012 06:41:51 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9CFF420E40FC; Tue, 26 Jun 2012 09:41:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340718110; bh=6gEMfqpFEdpfxKCC6rJQuCaOW190loz4YUQQV8fw8uI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ejjaXayONTZI93lwbJ4VUB2veJTAro7/Qfo+f/Z0j5iwn0aUtb/kY9DoUzozHBwfy mKo1GdM9MUAuqolYmstsppBEqGGa3jbULupH90AYvbYNL5NMzT4VMPscu/QIRyapKi /pv7ehtSY2sOAJx5G/a+E/E71HTjHXxUCRTBZD8g= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7DE8220E4091; Tue, 26 Jun 2012 09:41:50 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 26 Jun 2012 09:41:49 -0400 Message-ID: <1559388.sNHAI3CqZe@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FE9935A.2070004@tana.it> References: <1638743.cLUK3D7h0X@scott-latitude-e6320> <1914453.F4PorWEOV6@scott-latitude-e6320> <4FE9935A.2070004@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #1: RFC 4408 Section 2.5.6 - Temporary errors, was Initial version of draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 13:41:52 -0000 On Tuesday, June 26, 2012 12:47:54 PM Alessandro Vesely wrote: > On Mon 25/Jun/2012 20:38:29 +0200 Scott Kitterman wrote: > > On Monday, June 25, 2012 01:19:21 PM Alessandro Vesely wrote: > >>> Ticket #1, RFC 4408 Section 2.5.6 - Temporary errors - language added > >> > >> Do you mean the text appended to Section 4.4? It looks rather > >> obscure, as it tries to convey a complex algorithm using too few > >> words. (I don't think that referring to RFC 6555 would be useful, > >> since the algorithm described there is about address families.) > > > > Yes. > > > > I wasn't trying to specify what I would call an algorithm. There isn't an > > interoperability gain associated with everyone doing this identically. > > All we need to communicate is "You can treat repeated SERVFAIL for the > > same domain as permerror if you prefer." > > Servers don't have to behave identically, but consistently. The risk > of playing sorcerer's apprentice with that is to obtain undesired, > non-compliant behavior. But I don't think DNS servers would go off > the beaten track by using negative caching parameters far from those > specified by RFC 2308. > > OTOH, it seems to be a good idea for a mail server to keep track of > the domain names that it interacts with, in general. This case is so > marginal --because both the SPF RRTYPE and reject-on-fail are such-- > that it doesn't justify the creation of a database. However, if a > server already uses one, it may add a couple of fields for treating > this case. The difference between temperror deferral and permerror reject is the queue life of the sending MTA in cases where the source of the temperror isn't going to resolve. Since there are cases where SERVFAIL results are effectively permanent, using this option lets the sender know much sooner their message didn't make it. It's not an essential part of the protocol, but opening the options slightly to allow for this efficiency for senders that want to use it. > > Suggestions welcome on text. > > Two: > > s/Alternately/Alternatively/. > > Add an explanation, such as: > > That is not intended to save further queries, which MUST be done > according to RFC 2308, but to return a permanent negative completion > reply code to the client, instead of a transient one, thereby > shortening the queue time of messages that cannot be accepted. Incorporated locally. Thanks, Scott K From sm@resistor.net Tue Jun 26 09:35:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362A021F85B8 for ; Tue, 26 Jun 2012 09:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uArWqnl-h15R for ; Tue, 26 Jun 2012 09:35:55 -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 1737021F85AF for ; Tue, 26 Jun 2012 09:35:54 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5QGZmS9015480; Tue, 26 Jun 2012 09:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340728553; i=@resistor.net; bh=0FfcOZet4wOd9rKdavhFqyNnuloo2hpbeFn0ionzoJ4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=e87jrxmHqYhbcYdlqsymtkPXjcYHPO6g5WHv1+kDA8EGSRW+kW138Ny1nE+yKiJVf Y/4YB4jmhs2NpEFAZkwviRkZD6S6pAzaE9ckN4mGTjkJzVaTnUS+r5yES5yk2jSkwI +HX9sJUirFh52dW3z7m6kLPFFMQSYQsJS0vGFtfA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340728553; i=@resistor.net; bh=0FfcOZet4wOd9rKdavhFqyNnuloo2hpbeFn0ionzoJ4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=JKCu1EzeQrmYXgknriVD43i8ZRjfKQFY8Jt+r+7kA7jP5+qDdtRbyzwzl7xhFtRrR z7mlV+7r+zKTIeoHgtyKjAJqdtrDKYYp09lX5eE/tcAxR7xgrHV13sY+ryJz3xnr0S Nj//jkkhY17bYHKZDMDLp/u7Q1hzuen7QoBAkUyE= Message-Id: <6.2.5.6.2.20120626091654.0a5c0930@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 26 Jun 2012 09:28:09 -0700 To: Scott Kitterman , spfbis@ietf.org From: SM In-Reply-To: <1431561.9ffxbEmL34@scott-latitude-e6320> References: <061.8c71528b77bd471c792d11887cb3b78d@tools.ietf.org> <4790374.YA5eHke4su@scott-latitude-e6320> <6.2.5.6.2.20120625225554.080da220@resistor.net> <1431561.9ffxbEmL34@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] DSN in Section 10.5 (was: #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 16:35:57 -0000 Hi Scott, At 06:27 26-06-2012, Scott Kitterman wrote: >Fixed. In section 10.5, Untrusted Information Sources, there is reference to >DSN as well. Should that be changed to something else and if not should we >still have a reference to RFC 3464 (and add it there)? DSNs are used for notifications such as failed delivery, delayed delivery or successful delivery. Section 10.5 seems to be about "bounces". You could use the term "bounce". If we reference RFC 3464, it would require EHLO and the relevant SMTP extension. I would pick the easy fix unless anyone feels strongly about this. Regards, -sm From sm@elandsys.com Tue Jun 26 10:39:24 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 E0DF821F8606 for ; Tue, 26 Jun 2012 10:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAAcmrO8WjIB for ; Tue, 26 Jun 2012 10:39:20 -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 E600E21F85FD for ; Tue, 26 Jun 2012 10:39:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.50]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5QHd5Bf016063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jun 2012 10:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340732358; i=@elandsys.com; bh=xTlsRrILlcGGbGY5yjBv4ZvZW18zBUG262s21hiEB60=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=Yn+qqqK0BKAAAdb4ePgGBL8O37sFeYHUV33j0odQU7WmTZ1O0bc11GR2QF+MMENi9 X0Cp8wAPyqvmzwpseUd/ol4tH1eO6X40G6LGsqBs7elJFaVXkeYEU8wEhlbhVqkMwz IBWU/+bJHVSVl1Ij+nOp9xYz43RIG7wT5jfp3Ggk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340732358; i=@elandsys.com; bh=xTlsRrILlcGGbGY5yjBv4ZvZW18zBUG262s21hiEB60=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=SYjfr+aRgHpeLhgknHDnJvfxNarla5ft33TzOP0gNAe8I6MGMBP0TPZYdviCrv6Im orvSl0JlFNkpt+qSqkApz5HoxbLuFq8D2Aht3URMdG/KNPyMpDDWNYX4xzqTuK7QxA tuPbnTI8ZL5Dt8PQ+tGXZY0EEtylOkeG2apGoIp8= Message-Id: <6.2.5.6.2.20120626103259.0a7dfe70@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 26 Jun 2012 10:38:32 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <076.3ff34828925ff2ef77b3303a9526a1de@tools.ietf.org> References: <061.e951f4703a6cf669b9e1b4c0208e657d@tools.ietf.org> <076.3ff34828925ff2ef77b3303a9526a1de@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] #7: RFC 4408 Downcase result names in spec text and ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 17:39:24 -0000 At 22:29 17-02-2012, spfbis issue tracker wrote: >#7: RFC 4408 Downcase result names in spec text and ABNF > >Comment (by sm+ietf@=85): > Comment from MARF WG Chairs: > > If SPFbis decides to change all the SPF result codes to all-lowercase > rather than the current camel case, then SPFbis will want to announce= that > it updates draft-ietf-marf-spf-reporting This issue is related to the comment from Scott=20 Kitterman about RFC 6652 (=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg01630.html ). Regards, S. Moonesamy From spf2@kitterman.com Tue Jun 26 10:46:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C7011E808C for ; Tue, 26 Jun 2012 10:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w77gP3Ga7wv1 for ; Tue, 26 Jun 2012 10:46:48 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1B211E8072 for ; Tue, 26 Jun 2012 10:46:48 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B951F20E40FC; Tue, 26 Jun 2012 13:46:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340732807; bh=VPs0fPaudDcG+s97KrUV5CClhV1rmkH6jKdxr+wJSoc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=PLcu0xGuobT0/8N9vNf8jBER7ZNo65LIZyXMQgA85kl53on3jXt/IEWIBcDvjEdfD TNcGrJQQemhg+6sYo1xobH5JFvUr+fbejk+rVdhNsLPUeScj40IYWCFYrf99Pi9fPv GqZ821oQeGWV5fwCNTA7y+wu1gKKt9jiakQxTfdU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9B43B20E4091; Tue, 26 Jun 2012 13:46:47 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 26 Jun 2012 13:46:46 -0400 Message-ID: <8381805.ufklvoxUWC@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120626103259.0a7dfe70@elandnews.com> References: <061.e951f4703a6cf669b9e1b4c0208e657d@tools.ietf.org> <076.3ff34828925ff2ef77b3303a9526a1de@tools.ietf.org> <6.2.5.6.2.20120626103259.0a7dfe70@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #7: RFC 4408 Downcase result names in spec text and ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 17:46:49 -0000 On Tuesday, June 26, 2012 10:38:32 AM S Moonesamy wrote: > At 22:29 17-02-2012, spfbis issue tracker wrote: > >#7: RFC 4408 Downcase result names in spec text and ABNF > > > >Comment (by sm+ietf@=85): > > Comment from MARF WG Chairs: > > =20 > > If SPFbis decides to change all the SPF result codes to all-lowerc= ase > > rather than the current camel case, then SPFbis will want to annou= nce > > that > > it updates draft-ietf-marf-spf-reporting >=20 > This issue is related to the comment from Scott > Kitterman about RFC 6652 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01630.html ). I don't get this issue. The result names are, and have always been, ca= se=20 insensitive, so I think the downcasing is purely stylistic. Why does 4= 408bis=20 need to update 6652 for this? I do wonder if it makes sense to replicate the IANA registry informatio= n in=20 6652 into 4408bis and then have 4408bis update 6652, but that's (AFAICT= )=20 unrelated to the downcasing question. Scott K From sm@elandsys.com Tue Jun 26 11:26: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 CAD1E21F85D0 for ; Tue, 26 Jun 2012 11:26:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wapDJohYoJXb for ; Tue, 26 Jun 2012 11:26:13 -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 6098021F85C0 for ; Tue, 26 Jun 2012 11:26:13 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.50]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5QIPujo018441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jun 2012 11:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340735169; i=@elandsys.com; bh=WWCTAWz+N7HuxdHyFI/P50Yd06xcBpKemxBZqlzyS6c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xfgOQAiMmOKAKlxaFREXesHKmOXbqE5sOykzf1oY1cRC+9qUTAxLOfuKIofRmdU9C qk5OACmiQyUQ5JfsgZPgyoqoIjoGKkyinBpJ/uRbWk3388Ro0sIyPE/doFRgMLzo0G ixcZO5S3f5BBx6PLJYCSBNQoc6toVkIlr0SSULWQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340735169; i=@elandsys.com; bh=WWCTAWz+N7HuxdHyFI/P50Yd06xcBpKemxBZqlzyS6c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vZ07OSZb90xs/d/L353Y+EJDf2e3RJ73Gd6Mznc+gl2PCRKIz25tWeHWA/HfNz5KI fccunuozLtsATq9gMzHgOxuO44yuhYc1Q7vIzZaETZjcHHe2zJiEC06NexTlaBJNZJ AQ9Xi+j2uCiLQpLvkyGnHcJ9LhbtHnF43D06CMbs= Message-Id: <6.2.5.6.2.20120626110149.0a7df430@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 26 Jun 2012 11:19:31 -0700 To: Scott Kitterman , spfbis@ietf.org From: S Moonesamy In-Reply-To: <8381805.ufklvoxUWC@scott-latitude-e6320> References: <061.e951f4703a6cf669b9e1b4c0208e657d@tools.ietf.org> <076.3ff34828925ff2ef77b3303a9526a1de@tools.ietf.org> <6.2.5.6.2.20120626103259.0a7dfe70@elandnews.com> <8381805.ufklvoxUWC@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Murray S. Kucherawy" Subject: Re: [spfbis] #7: RFC 4408 Downcase result names in spec text and ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 18:26:13 -0000 Hi Scott, At 10:46 26-06-2012, Scott Kitterman wrote: >I don't get this issue. The result names are, and have always been, case >insensitive, so I think the downcasing is purely stylistic. Why does 4408bis >need to update 6652 for this? That was a comment from Murray Kucherawy as MARF WG Chair during the work on RFC 6652. >I do wonder if it makes sense to replicate the IANA registry information in >6652 into 4408bis and then have 4408bis update 6652, but that's (AFAICT) >unrelated to the downcasing question. The Modifier Names registry has already been created. I suggest waiting for Murray to comment as he may have a better recollection of the discussion in MARF. Regards, S. Moonesamy From spf2@kitterman.com Tue Jun 26 12:03: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 0CA0D21F8579 for ; Tue, 26 Jun 2012 12:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KieJsIAqCIdi for ; Tue, 26 Jun 2012 12:03:54 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 735FC21F8570 for ; Tue, 26 Jun 2012 12:03:54 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D88E420E40FC; Tue, 26 Jun 2012 15:03:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340737433; bh=rPkFWBrEQXvvnmSl7k19ne0z4IkBO3sqKZJaGY1+WQ8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=k+rhKA1LnsA++qG0kQDc9m6NtvULxM7VdoVKNZ3Nd4PA+AEz/Q6ETStL7Z9L4PVVA obXWVYtHtoZ8K2v01fK7YxYrwEPsk+UTi1wFDt758d0b4DzDdATP4gPHu+KqIdHbAX F06ZtqUTMR6fpHGSg1p1UKxSynJslDN3yNEgU19E= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BB52D20E4091; Tue, 26 Jun 2012 15:03:53 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 26 Jun 2012 15:03:53 -0400 Message-ID: <3945570.FETRVMUN5u@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120626091654.0a5c0930@resistor.net> References: <061.8c71528b77bd471c792d11887cb3b78d@tools.ietf.org> <1431561.9ffxbEmL34@scott-latitude-e6320> <6.2.5.6.2.20120626091654.0a5c0930@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] DSN in Section 10.5 (was: #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 19:03:55 -0000 On Tuesday, June 26, 2012 09:28:09 AM SM wrote: > Hi Scott, > > At 06:27 26-06-2012, Scott Kitterman wrote: > >Fixed. In section 10.5, Untrusted Information Sources, there is reference > >to DSN as well. Should that be changed to something else and if not > >should we still have a reference to RFC 3464 (and add it there)? > > DSNs are used for notifications such as failed delivery, delayed > delivery or successful delivery. Section 10.5 seems to be about > "bounces". You could use the term "bounce". If we reference RFC > 3464, it would require EHLO and the relevant SMTP extension. I would > pick the easy fix unless anyone feels strongly about this. Thanks. Changed to bounce locally. Scott K From superuser@gmail.com Tue Jun 26 13:03: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 61DF621F85FD for ; Tue, 26 Jun 2012 13:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A70MzkFv-deE for ; Tue, 26 Jun 2012 13:03:54 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 95E8021F85F7 for ; Tue, 26 Jun 2012 13:03:54 -0700 (PDT) Received: by bkty8 with SMTP id y8so356405bkt.31 for ; Tue, 26 Jun 2012 13:03:53 -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=isGzHRxePZ16sJYumv07yflbFT8ELakBIAG7G5usgvY=; b=F0x60jroP8M8nVPG/ntAkumkrWaVc4wlmUgN+nQZ/p1cqusEKEpt0d9Px/pkkFV/Pr Oik9d4cldmk6l4tUGk7S4X76GBAy3jUeGEYvTP484nbS4LCoDcxqLzGB7H+Muuf+43+0 L1mmm74rUpKO8TJFAnGV2G2uTXM1rQRzvhEErDwT8QgihEtHRva9GzvId+4+5wKFQJjs l2DLX32SSdNYTZkIdnDHBX4kHfN2jAWMI0rOFJyvjJw9iqnUn0aBwaGlX85TAiE22HVP cBh5XS+7Dk1qbx/VonlD7SoYoQNVJBbcVK1NRfKHAv3zR9e4n3a5sLJO34zHo+a0HZuJ 2i/A== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr17390998lab.47.1340741033600; Tue, 26 Jun 2012 13:03:53 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Tue, 26 Jun 2012 13:03:53 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120626110149.0a7df430@resistor.net> References: <061.e951f4703a6cf669b9e1b4c0208e657d@tools.ietf.org> <076.3ff34828925ff2ef77b3303a9526a1de@tools.ietf.org> <6.2.5.6.2.20120626103259.0a7dfe70@elandnews.com> <8381805.ufklvoxUWC@scott-latitude-e6320> <6.2.5.6.2.20120626110149.0a7df430@resistor.net> Date: Tue, 26 Jun 2012 13:03:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d0435c1d20b25c504c36599d2 Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] #7: RFC 4408 Downcase result names in spec text and ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 20:03:55 -0000 --f46d0435c1d20b25c504c36599d2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 26, 2012 at 11:19 AM, S Moonesamy wrote: > Hi Scott, > > At 10:46 26-06-2012, Scott Kitterman wrote: > >> I don't get this issue. The result names are, and have always been, case >> insensitive, so I think the downcasing is purely stylistic. Why does >> 4408bis >> need to update 6652 for this? >> > > That was a comment from Murray Kucherawy as MARF WG Chair during the work > on RFC 6652. > > > I do wonder if it makes sense to replicate the IANA registry information >> in >> 6652 into 4408bis and then have 4408bis update 6652, but that's (AFAICT) >> unrelated to the downcasing question. >> > > The Modifier Names registry has already been created. I suggest waiting > for Murray to comment as he may have a better recollection of the > discussion in MARF. > > It is entirely stylistic. Things like Authentication-Results and even Received-SPF use all-lowercase, so I thought it might be good to be consistent even if the documents also say matching is to be case-insensitive. In particular, I think presenting in documents things in mixed case suggests that case is important more than all-caps and all-lowercase do. -MSK --f46d0435c1d20b25c504c36599d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 11:19 AM, S Moonesamy <sm+ietf@elandsys.com= > wrote:
Hi Scott,

At 10:46 26-06-2012, Scott Kitterman wrote:
I don't get this issue. =A0The result names are, and have always been, = case
insensitive, so I think the downcasing is purely stylistic. =A0Why does 440= 8bis
need to update 6652 for this?

That was a comment from Murray Kucherawy as MARF WG Chair during the work o= n RFC 6652.


I do wonder if it makes sense to replicate the IANA registry information in=
6652 into 4408bis and then have 4408bis update 6652, but that's (AFAICT= )
unrelated to the downcasing question.

The Modifier Names registry has already been created. =A0I suggest waiting = for Murray to comment as he may have a better recollection of the discussio= n in MARF.


It is entirely stylistic.=A0 Things like Authenti= cation-Results and even Received-SPF use all-lowercase, so I thought it mig= ht be good to be consistent even if the documents also say matching is to b= e case-insensitive.

In particular, I think presenting in documents things in mixed case sug= gests that case is important more than all-caps and all-lowercase do.
-MSK

--f46d0435c1d20b25c504c36599d2-- From superuser@gmail.com Tue Jun 26 13:15: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 8EEFD11E80E0 for ; Tue, 26 Jun 2012 13:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEXVmcPm0-7J for ; Tue, 26 Jun 2012 13:15:48 -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 9FDE111E80CF for ; Tue, 26 Jun 2012 13:15:47 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so576762lbb.31 for ; Tue, 26 Jun 2012 13:15:46 -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=J8v2QVhUWjgjAXIJVJFOeVsZ9eqdRY5/E04oC/yydb4=; b=Hv5DInwau8MiAfWcij+d35O1rH74r7VKQ5PREtAHYfnsuLoBNWesvNv2Y1zarNoTkN D6g9uis4sMbe669EvHQu3RtTH2PR+XQd7KgMjas+vTdItiFUCbzVOMfV1OL+LBxpxCIa iotu27eBQpbQVr+WzjQ+TSIm9xwkgoQxNpqjof19TKvDG8Yql7u3nS3XLOih8IhCRk4T VkuBDKvTKgMvPpUM1a60unTcmpxVPP8DK5sdEH8RLNXxfARiXeYkr8crBqqBQNVzLKZs Pc5stV+WijNyLD+lVnaC6cXsTcHEkFOY84WFABbsoTd7NHdpUUTRGuhCwUhHGzeBBfz0 Fziw== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr17875642lab.9.1340741746340; Tue, 26 Jun 2012 13:15:46 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Tue, 26 Jun 2012 13:15:46 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120626091654.0a5c0930@resistor.net> References: <061.8c71528b77bd471c792d11887cb3b78d@tools.ietf.org> <4790374.YA5eHke4su@scott-latitude-e6320> <6.2.5.6.2.20120625225554.080da220@resistor.net> <1431561.9ffxbEmL34@scott-latitude-e6320> <6.2.5.6.2.20120626091654.0a5c0930@resistor.net> Date: Tue, 26 Jun 2012 13:15:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: multipart/alternative; boundary=e89a8f22c41186b48c04c365c359 Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] DSN in Section 10.5 (was: #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 20:15:48 -0000 --e89a8f22c41186b48c04c365c359 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 26, 2012 at 9:28 AM, SM wrote: > Hi Scott, > At 06:27 26-06-2012, Scott Kitterman wrote: > >> Fixed. In section 10.5, Untrusted Information Sources, there is >> reference to >> DSN as well. Should that be changed to something else and if not should >> we >> still have a reference to RFC 3464 (and add it there)? >> > > DSNs are used for notifications such as failed delivery, delayed delivery > or successful delivery. Section 10.5 seems to be about "bounces". You > could use the term "bounce". If we reference RFC 3464, it would require > EHLO and the relevant SMTP extension. I would pick the easy fix unless > anyone feels strongly about this. > > Section 2.5.4 already references RFC3464. I don't think we actually define "bounce" in either document, so I suggest we use "bounce" but parenthetically define it as a DSN with an Action value of "failed". Interestingly, even RFC5598 avoids defining "bounce". -MSK --e89a8f22c41186b48c04c365c359 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jun 26, 2012 at 9:28 AM, SM <sm@resistor.net> wrote:
Hi Scott,
At 06:27 26-06-2012, Scott Kitterman wrote:
Fixed. =A0In section 10.5, Untrusted Information Sources, there is referenc= e to
DSN as well. =A0Should that be changed to something else and if not should = we
still have a reference to RFC 3464 (and add it there)?

DSNs are used for notifications such as failed delivery, delayed delivery o= r successful delivery. =A0Section 10.5 seems to be about "bounces"= ;. =A0You could use the term "bounce". =A0If we reference RFC 346= 4, it would require EHLO and the relevant SMTP extension. =A0I would pick t= he easy fix unless anyone feels strongly about this.


Section 2.5.4 already references RFC3464. I don&#= 39;t think we actually define "bounce" in either document, so I s= uggest we use "bounce" but parenthetically define it as a DSN wit= h an Action value of "failed".

Interestingly, even RFC5598 avoids defining "bounce".

= -MSK
--e89a8f22c41186b48c04c365c359-- From johnl@iecc.com Tue Jun 26 13:59:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D006811E80DB for ; Tue, 26 Jun 2012 13:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.998 X-Spam-Level: X-Spam-Status: No, score=-110.998 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAOpz0K8oIJ4 for ; Tue, 26 Jun 2012 13:59:40 -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 D52BA11E80D6 for ; Tue, 26 Jun 2012 13:59:39 -0700 (PDT) Received: (qmail 80387 invoked from network); 26 Jun 2012 20:59:38 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Jun 2012 20:59:38 -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=4fea22ba.xn--hew.k1206; i=johnl@user.iecc.com; bh=jiVHD5rCuTrc2wwC/Gi7gc+av4zJmzVvu1apQxhlwPI=; b=itt0JE3+mNVAj59l1V6Pi0jjoRYLvVSeKi/bMOR9lcHH0RA3edOM2nQCwQK0omL6IQccHsiunPy74zVjvpG1vNkp0Ps1EL6wcUa+bRoDqg3fNkTSgoAji58TPz13V9weXL1PQWX2BQniQAk1V1kDDZ3qH7HYPzv2LRy9+irPuL0= 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=4fea22ba.xn--hew.k1206; olt=johnl@user.iecc.com; bh=jiVHD5rCuTrc2wwC/Gi7gc+av4zJmzVvu1apQxhlwPI=; b=SOmd+hAUbWfYCJ4Exa/qNtd8NpbYRg0o4UK0JXHJvwGhALmo/VrsIbbqZk5Yeh981J6Sx8V1QJUVDVFxf0DPEow4LtjEs74v7vxrd1Yq/EFt6YZe859xY58ItcVsqcoF72VHnQlNio47HATWe14fca4XmORAYSND1CUEASl+ECk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 26 Jun 2012 20:59:16 -0000 Message-ID: <20120626205916.52922.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: superuser@gmail.com Subject: Re: [spfbis] DSN in Section 10.5 (was: #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 20:59:40 -0000 >Section 2.5.4 already references RFC3464. I don't think we actually define >"bounce" in either document, so I suggest we use "bounce" but >parenthetically define it as a DSN with an Action value of "failed". I see a couple of references to bounce address, two uses in sec 9.3 on page 37 where it's confusingly used to mean forwarded, and in 9.5 where it means a nondelivery notice. I'd be OK using a DSN as an example of a bounce message, but there are still plenty of MTAs that send bounce messages that aren't NDN. Since it's only that one place, how about taking out the word bounce change "rather than bounced" to "rather than sending a failure report." And please rewrite it out of section 9.3: OLD: This means that mail bounced from the external mailbox will have to be re-bounced by the forwarding service. NEW: This means that mail forwarded from the external mailbox will have to be remailed by the forwarding service. R's, John From spf2@kitterman.com Tue Jun 26 14:28: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 CA11021F859A for ; Tue, 26 Jun 2012 14:28: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA5cyNLbnM8g for ; Tue, 26 Jun 2012 14:28:53 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 342CA21F8599 for ; Tue, 26 Jun 2012 14:28:53 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 78DAA20E40FC; Tue, 26 Jun 2012 17:28:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340746132; bh=yBcsoTS2Bxxpt0AowtHK3M4bm/UY/xF9Id80p1pE9cU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=AnAVO7RoUIws/bUJYR/oQzsqBIBmtEeus7u0HvFrKo1NOUD6rnHRyvJnn4d42YVAe k/Q6W0FRROZRxx+nEgCWJTHpFd8Hgv1WwFq9F8wzZ8zjepsLPq6h+L9lDIkvPdwTfA B9tj6t5Ewn16X/H2d8P3aJvm+hUHTVG8oclTXmfo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5A34720E4091; Tue, 26 Jun 2012 17:28:52 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 26 Jun 2012 17:28:51 -0400 Message-ID: <4102366.kimKXhns18@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <061.8c71528b77bd471c792d11887cb3b78d@tools.ietf.org> <6.2.5.6.2.20120626091654.0a5c0930@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] DSN in Section 10.5 (was: #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 21:28:53 -0000 On Tuesday, June 26, 2012 01:15:46 PM Murray S. Kucherawy wrote: > On Tue, Jun 26, 2012 at 9:28 AM, SM wrote: > > Hi Scott, > > > > At 06:27 26-06-2012, Scott Kitterman wrote: > >> Fixed. In section 10.5, Untrusted Information Sources, there is > >> reference to > >> DSN as well. Should that be changed to something else and if not should > >> we > >> still have a reference to RFC 3464 (and add it there)? > > > > DSNs are used for notifications such as failed delivery, delayed delivery > > or successful delivery. Section 10.5 seems to be about "bounces". You > > could use the term "bounce". If we reference RFC 3464, it would require > > EHLO and the relevant SMTP extension. I would pick the easy fix unless > > anyone feels strongly about this. > > Section 2.5.4 already references RFC3464. I don't think we actually define > "bounce" in either document, so I suggest we use "bounce" but > parenthetically define it as a DSN with an Action value of "failed". I switched this to RFC3463 already based on SM's comment. I'm taking John's suggested approach of avoiding the word and we can revisit if needed after I publish the next update. > Interestingly, even RFC5598 avoids defining "bounce". All the more reason not to try and do it here. Scott K From spf2@kitterman.com Tue Jun 26 14:36:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF80C21F85C0 for ; Tue, 26 Jun 2012 14:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEZ76XR+b1LM for ; Tue, 26 Jun 2012 14:36:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 912BC21F85BD for ; Tue, 26 Jun 2012 14:35:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C6EEB20E40FC; Tue, 26 Jun 2012 17:35:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340746555; bh=91pBohRjOfiqInXbEwFP6S8S7q4Qz56AO4WlpF4t6X0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=m4IGdn+Nomrz86WzvgEtX9sjP4sOTGP+0pWMwnGZGnk+GAVWxpcqaQobYwJAZlbkW V0jw6mKUxFCP4iuBPrybQr4vYAes1iirDAQfyosVFqDybRxYNBHcc01Wt29jPN0vt8 cMM9gQmwuiCOdScyNPt4Q6/OG2uTt4zeWDUW1ow8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ADD9320E4091; Tue, 26 Jun 2012 17:35:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 26 Jun 2012 17:35:55 -0400 Message-ID: <3413793.BBKSB1rrpE@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120626205916.52922.qmail@joyce.lan> References: <20120626205916.52922.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] DSN in Section 10.5 (was: #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 21:36:00 -0000 On Tuesday, June 26, 2012 08:59:16 PM John Levine wrote: > >Section 2.5.4 already references RFC3464. I don't think we actually define > >"bounce" in either document, so I suggest we use "bounce" but > >parenthetically define it as a DSN with an Action value of "failed". > > I see a couple of references to bounce address, two uses in sec 9.3 > on page 37 where it's confusingly used to mean forwarded, and in > 9.5 where it means a nondelivery notice. > > I'd be OK using a DSN as an example of a bounce message, but > there are still plenty of MTAs that send bounce messages that > aren't NDN. Since it's only that one place, how about taking > out the word bounce change "rather than bounced" to "rather > than sending a failure report." > > And please rewrite it out of section 9.3: > > OLD: > This means that mail > bounced from the external mailbox will have to be re-bounced > by the forwarding service. > > NEW: > This means that mail > forwarded from the external mailbox will have to be remailed > by the forwarding service. I removed it from both locally. The term bounce also appears in section 10.5 (several times). If someone wants to take a shot at rewriting that, I'd appreciate it. Scott K From sm@resistor.net Tue Jun 26 15:31:09 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 CF31811E808E for ; Tue, 26 Jun 2012 15:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTn0a-rr-ztm for ; Tue, 26 Jun 2012 15:31:07 -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 BB4F111E8087 for ; Tue, 26 Jun 2012 15:31:07 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5QMUtJj006802; Tue, 26 Jun 2012 15:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340749865; bh=mIM3NtRk/sFPsMaGq6PiKvyDeCpj23/BoRbq+i6CNrQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=eby6GWDMCzo3cOEJBGe+aJ6Lr2nRwzPVH4kpKj2p2Eff5qO34Q6kY9Y2bvvbGU77o ORPf51haWf5/j/UKVu+oVz0a1ZmE3M05D0bA7dw/R9k2afG2kX3c8v1JczWWBzzsEU Ngh8S0vfYzhYoI3Td46Q3sGKNLmacFaHSMvIgZhg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340749865; i=@resistor.net; bh=mIM3NtRk/sFPsMaGq6PiKvyDeCpj23/BoRbq+i6CNrQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WNkIVkwA0WSddmy1S5blZv+PnU32xkoXQ8jl4BnDhl+8qZW4Ed8+hF4b4dzvQQByk KgDnkG3YTJZFaDPLFe/jBys+bOFBrdYPA/5S1jhAaHzxcb2qx9eRYMKaZkBsVFsRev zzDUexp01nSBJZxV0rs4LMwIZsafr5ded8R/+OcM= Message-Id: <6.2.5.6.2.20120626144212.0a428c48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 26 Jun 2012 15:29:03 -0700 To: Scott Kitterman From: SM In-Reply-To: <3413793.BBKSB1rrpE@scott-latitude-e6320> References: <20120626205916.52922.qmail@joyce.lan> <3413793.BBKSB1rrpE@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] DSN in Section 10.5 (was: #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 26 Jun 2012 22:31:09 -0000 Hi Scott, At 14:35 26-06-2012, Scott Kitterman wrote: >I removed it from both locally. The term bounce also appears in section 10.5 >(several times). If someone wants to take a shot at rewriting that, I'd >appreciate it. Please not that I do not have a strong opinion about this. The last paragraph of Section 10.5 has: "As long as the DSN is not redirected to someone other than the actual sender, the only people who see malicious explanation strings are people whose messages claim to be from domains that publish such strings in their SPF records. In practice, DSNs can be misdirected, such as when an MTA accepts an E-Mail and then later generates a DSN to a forged address, or when an E-Mail forwarder does not direct the DSN back to the original sender." Suggested text as a starting point (it needs editing): As long as messages are only bounced (returned with non-delivery notification) to domains which publish malicious explanation strings in their SPF records, the only people affected are those associated with those domains. In practice, bounces can be misdirected to a forged email address or when a mail forwarder does not generate a bounce for the original sender. Regards, -sm From spf2@kitterman.com Tue Jun 26 22:17: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 5E76F11E8102 for ; Tue, 26 Jun 2012 22:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg4dhR6CIBQR for ; Tue, 26 Jun 2012 22:17:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7A39711E80C5 for ; Tue, 26 Jun 2012 22:17:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7012F20E40FC; Wed, 27 Jun 2012 01:17:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340774263; bh=CEBjIllThVKoTGy6aQGFgE25NfETxYZRnZ12Z87pgpQ=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=EnMKT83EFgNVA8INjaelvWxIyFCqGirohHej4tw+fymvSXbMsGXTUgDKUuBjQYZVT IxgS5Y8cy+XNeMyokogtdE3YvUp+IHRHIJksnm14Mh0cQIbKEBSrTHgiXiSGJb2ByG z6Ua4WiBs1CZc0+gGEaPLQbqbsCAoGd1WK3Gv1eo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 526C420E4091; Wed, 27 Jun 2012 01:17:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 27 Jun 2012 01:17:42 -0400 Message-ID: <1597913.R5sRxLnjiq@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120626144212.0a428c48@resistor.net> References: <20120626205916.52922.qmail@joyce.lan> <3413793.BBKSB1rrpE@scott-latitude-e6320> <6.2.5.6.2.20120626144212.0a428c48@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] DSN in Section 10.5 (was: #18: RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional PermError rejections) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Jun 2012 05:17:45 -0000 On Tuesday, June 26, 2012 03:29:03 PM SM wrote: > Hi Scott, > > At 14:35 26-06-2012, Scott Kitterman wrote: > >I removed it from both locally. The term bounce also appears in section > >10.5 (several times). If someone wants to take a shot at rewriting that, > >I'd appreciate it. > > Please not that I do not have a strong opinion about this. > > The last paragraph of Section 10.5 has: > > "As long as the DSN is not redirected to someone other than the > actual sender, the only people who see malicious explanation > strings are people whose messages claim to be from domains that > publish such strings in their SPF records. In practice, DSNs can > be misdirected, such as when an MTA accepts an E-Mail and then > later generates a DSN to a forged address, or when an E-Mail > forwarder does not direct the DSN back to the original sender." > > Suggested text as a starting point (it needs editing): > > As long as messages are only bounced (returned with non-delivery > notification) > to domains which publish malicious explanation strings in their > SPF records, > the only people affected are those associated with those > domains. In practice, > bounces can be misdirected to a forged email address or when a > mail forwarder > does not generate a bounce for the original sender. Thanks. I updated this section based in part on your input and an input I received offlist. Scott K From internet-drafts@ietf.org Tue Jun 26 22:19: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 E29AD11E8108; Tue, 26 Jun 2012 22:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzOZJEWz-yEp; Tue, 26 Jun 2012 22:19:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D9B11E80C5; Tue, 26 Jun 2012 22:19:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2012 22:19:27 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 05:19:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Dom= ains in Email, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-01.txt Pages : 54 Date : 2012-06-26 Abstract: E-mail 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 reverse-path 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 a domain can explicitly authorize the hosts that are allowed to use its domain name, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Tue Jun 26 22:22:25 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 834AD21F84A5 for ; Tue, 26 Jun 2012 22:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6p5vvF5987l0 for ; Tue, 26 Jun 2012 22:22:24 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8D73021F849B for ; Tue, 26 Jun 2012 22:22:24 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C218920E40FC; Wed, 27 Jun 2012 01:22:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340774543; bh=o1E4+oaTAIqwzlrac/Hj7koYUntgicw9CQAVviblkv0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=mghMOnUzCj08jp785UIsQtUi23u60L/wl0jVi2/pf685L5C54oKuKdOWpUTUJUwK+ JtuSYIP8TeyYdXKYtpt1MDNDGSIoZLrz7xYCktfXWlzEfNYx9Qx04IBxA7JMTr3ZV2 1+96xULSsdZ0pnifsKW426NLH8mtQK1aRf/p9P90= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A31BD20E4091; Wed, 27 Jun 2012 01:22:23 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 27 Jun 2012 01:22:23 -0400 Message-ID: <1946853.36BUztoKUg@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 05:22:25 -0000 Since there have been a fair number of changes already since the 00 draft and I'll be offline most of tomorrow, I wanted to leave you with the current state of the work to consider. In addition to the updated draft, there's an rfcdiff at http://kitterman.com/spfbis/draft-ietf-spfbis-4408bis-01-from-0.diff.html. I made a few minor changes beyond the ones discussed on the list. Mostly to try to make idnits happier. Scott K On Tuesday, June 26, 2012 10:19:27 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the SPF Update Working Group of > the IETF. > > Title : Sender Policy Framework (SPF) for Authorizing Use of > Domains in Email, Version 1 Author(s) : Scott Kitterman > Filename : draft-ietf-spfbis-4408bis-01.txt > Pages : 54 > Date : 2012-06-26 > > Abstract: > E-mail 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 reverse-path 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 a domain can > explicitly authorize the hosts that are allowed to use its domain > name, and a receiving host can check such authorization. This > document obsoletes RFC4408. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-01 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From superuser@gmail.com Tue Jun 26 22:41:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F8D21F861A for ; Tue, 26 Jun 2012 22:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-xclis3sAtw for ; Tue, 26 Jun 2012 22:41:25 -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 017D121F85F0 for ; Tue, 26 Jun 2012 22:41:24 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1127336lbb.31 for ; Tue, 26 Jun 2012 22:41:23 -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 :content-type; bh=6Q3+nnHtCn+B0O/w85Sg49TEDsDbBC9a6FeJV2axq24=; b=dbKneQc9ybnFxi6zwpYcUCT3fAEytKPEqmXF1i4vF+ZNeJKLReh76huf8yNSqHhMl1 bTiCHXmPefqBJFraPeJDgRLbXfjNTJA9cmR70Kh4pUjG1eGmHJPdGh/BfEVCyrB0PE4P NK9gvJenuKzZDJGbM2SOSIDo1OkubR1gMHO4wVRx6H5mxpA3311/Wba2rAmCfDps13Bw vnqjlPLseJCVTcMU0mNpl4WA1uZG7vdLLXmayuW0dyNMpEiYVDJ0uv9BbjieOMzr3FEj z09B5kqJpAkqjX4DA0HIPBo5JqRc2lTxJmiz5xeq9/v1YkPsUlvlkf1gchSluWYZQv86 +Khw== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr18845260lab.47.1340775683673; Tue, 26 Jun 2012 22:41:23 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Tue, 26 Jun 2012 22:41:23 -0700 (PDT) In-Reply-To: <20120627053744.31778.94514.idtracker@ietfa.amsl.com> References: <20120627053744.31778.94514.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2012 22:41:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: spfbis@ietf.org Content-Type: multipart/alternative; boundary=f46d0435c1d2594c5404c36daa13 Subject: [spfbis] Fwd: New Version Notification for draft-kucherawy-rfc5451bis-00.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 05:41:26 -0000 --f46d0435c1d2594c5404c36daa13 Content-Type: text/plain; charset=ISO-8859-1 RFC5451 has been a Proposed Standard long enough and is in widespread enough use to qualify for advancement to Internet Standard. I've posted a first revision of it now. It's outside of the spfbis charter, so this is just to bring it to people's attention. It is of at least peripheral interest since one of our open tracker items has to do with making greater use of Authentication-Results in RFC4408bis. I haven't gone through the submitted errata yet; that's next. -MSK ---------- Forwarded message ---------- From: Date: Tue, Jun 26, 2012 at 10:37 PM Subject: New Version Notification for draft-kucherawy-rfc5451bis-00.txt To: superuser@gmail.com A new version of I-D, draft-kucherawy-rfc5451bis-00.txt has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository. Filename: draft-kucherawy-rfc5451bis Revision: 00 Title: Message Header Field for Indicating Message Authentication Status Creation date: 2012-06-26 WG ID: Individual Submission Number of pages: 42 URL: http://www.ietf.org/internet-drafts/draft-kucherawy-rfc5451bis-00.txt Status: http://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis Htmlized: http://tools.ietf.org/html/draft-kucherawy-rfc5451bis-00 Abstract: This memo specifies a header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. This document is a candidate for Internet Standard status. [RFC Editor: Please delete this notation, as I imagine it will be indicated some other way.] The IETF Secretariat --f46d0435c1d2594c5404c36daa13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RFC5451 has been a Proposed Standard long enough and is in widespread enoug= h use to qualify for advancement to Internet Standard.=A0 I've posted a= first revision of it now.=A0 It's outside of the spfbis charter, so th= is is just to bring it to people's attention.=A0 It is of at least peri= pheral interest since one of our open tracker items has to do with making g= reater use of Authentication-Results in RFC4408bis.

I haven't gone through the submitted errata yet; that's next.
-MSK

---------- Forwarded message -= ---------
From: <= ;internet-drafts@ietf.org&g= t;
Date: Tue, Jun 26, 2012 at 10:37 PM
Subject: New Version Notification fo= r draft-kucherawy-rfc5451bis-00.txt
To: superuser@gmail.com



A new version of I-D, draft-kucherawy-rfc5451bis-00.txt
has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-kucherawy-rfc5451bis
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Message Header Field for Indicating Message Auth= entication Status
Creation date: =A0 2012-06-26
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 42
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/i= nternet-drafts/draft-kucherawy-rfc5451bis-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dr= aft-kucherawy-rfc5451bis
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-kuche= rawy-rfc5451bis-00


Abstract:
=A0 This memo specifies a header field for use with electronic mail
=A0 messages to indicate the results of message authentication efforts. =A0 Any receiver-side software, such as mail filters or Mail User Agents =A0 (MUAs), may use this message header field to relay that information =A0 in a convenient way to users or to make sorting and filtering
=A0 decisions.

=A0 This document is a candidate for Internet Standard status. =A0[RFC
=A0 Editor: Please delete this notation, as I imagine it will be
=A0 indicated some other way.]




The IETF Secretariat

--f46d0435c1d2594c5404c36daa13-- From barryleiba.mailing.lists@gmail.com Wed Jun 27 06:55: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 0E76C21F8771 for ; Wed, 27 Jun 2012 06:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.951 X-Spam-Level: X-Spam-Status: No, score=-102.951 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Twj1XbzMPK0 for ; Wed, 27 Jun 2012 06:55:12 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35AD521F8770 for ; Wed, 27 Jun 2012 06:55:12 -0700 (PDT) Received: by bkty8 with SMTP id y8so1051692bkt.31 for ; Wed, 27 Jun 2012 06:55:11 -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=YTYHtOcRG9wKQeUntQpR93chIvpYJNGK9mZ9ProMpXc=; b=W0yFQoZj04eXbzjdMxsJGY4LyiIDVfngwv69fNl9dNtdyuAuq9/WJSWTzQR7gaWfop x/Wz9TrjjLqMRXaCirHdXG3L3c6s//dKRZTcSR7Wm/rfaR/CWDOh2hVogVeN/gwb9rxT Q4QGBWVbY9qhI8o3/o9PSKnAovDd/tgGS2XN5nfTs82wd3zJZaQZv/tRiUo5ARimR4QR E7QcJBlCUNrng5065VFVpYeuL+QgBfCypgegVfKr3d4NZBMdpiiwnahdsq7E3XXRYCTb 7Tm6cdKd01J8vBJBS9KhwHIroHr8Vbrh+MGMCapdn/WuG2Mc7wpaFCm2zYDkxScfNwjz LR5w== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr20479965lab.40.1340805311047; Wed, 27 Jun 2012 06:55:11 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Wed, 27 Jun 2012 06:55:10 -0700 (PDT) In-Reply-To: References: <061.e951f4703a6cf669b9e1b4c0208e657d@tools.ietf.org> <076.3ff34828925ff2ef77b3303a9526a1de@tools.ietf.org> <6.2.5.6.2.20120626103259.0a7dfe70@elandnews.com> <8381805.ufklvoxUWC@scott-latitude-e6320> <6.2.5.6.2.20120626110149.0a7df430@resistor.net> Date: Wed, 27 Jun 2012 09:55:10 -0400 X-Google-Sender-Auth: s_puWUulBsAqOXUCcTCHfuJJfqU Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, S Moonesamy , Scott Kitterman Subject: Re: [spfbis] #7: RFC 4408 Downcase result names in spec text and ABNF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 27 Jun 2012 13:55:13 -0000 > In particular, I think presenting in documents things in mixed case suggests that > case is important more than all-caps and all-lowercase do. I think that is absolutely true. For example, when I used "IMAPSieve" as a keyword in draft-ietf-sieve-imap-sieve, I got multiple comments that because that syntax element is defined as case-insensitive, I should make it "imapsieve". When I reminded them that "case-insensitive" means that both are fine, people thought that the mixed-case version invited confusion. Barry From dhc@dcrocker.net Wed Jun 27 08:18:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2C921F8763 for ; Wed, 27 Jun 2012 08:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN+MmScWgddB for ; Wed, 27 Jun 2012 08:18:25 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CA51F21F8736 for ; Wed, 27 Jun 2012 08:18:25 -0700 (PDT) Received: from [192.168.1.9] (adsl-67-127-55-201.dsl.pltn13.pacbell.net [67.127.55.201]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q5RFIOO1017922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jun 2012 08:18:25 -0700 Message-ID: <4FEB243F.50007@dcrocker.net> Date: Wed, 27 Jun 2012 08:18:23 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> In-Reply-To: <1946853.36BUztoKUg@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 27 Jun 2012 08:18:25 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:18:26 -0000 On 6/26/2012 10:22 PM, Scott Kitterman wrote: > I made a few minor changes beyond the ones discussed on the list. Mostly to > try to make idnits happier. Small typo: > This alternate, is not intended to save further queries, which MUST > be done according to RFC 2308, but to return a permanent negative > completion reply code to the client, instead of a transient one, > thereby shortening the queue time of messages that cannot be > accepted. remove the first comma. Howevever, for better readability and clarity, it would be a bit cleaner to break the sentence up, along the lines of: This alternative is intended to shorten the queue time of messages that cannot be accepted, by returning a permanent negative completion reply code to the client, instead of a transient one. Saving queries is accomplished according to [RFC2308]. (side point: there's no real need for a normative MUST here; it's not really specifying basic DNS behavior, but instead pointing to a spec that does.) -- Dave Crocker Brandenburg InternetWorking bbiw.net From iesg-secretary@ietf.org Wed Jun 27 08:26:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3759721F879D; Wed, 27 Jun 2012 08:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imf6GnNZq45c; Wed, 27 Jun 2012 08:26:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC4E21F87A1; Wed, 27 Jun 2012 08:26:43 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120627152643.22919.44886.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 08:26:43 -0700 Cc: spfbis mailing list , spfbis chair , RFC Editor Subject: [spfbis] Document Action: 'Resolution of The SPF and Sender ID Experiments' to Informational RFC (draft-ietf-spfbis-experiment-11.txt) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:26:44 -0000 The IESG has approved the following document: - 'Resolution of The SPF and Sender ID Experiments' (draft-ietf-spfbis-experiment-11.txt) as Informational RFC This document is the product of the SPF Update Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment/ Technical Summary In 2006 the IETF published a suite of protocol documents comprising SPF and Sender ID, two proposed email authentication protocols with Experimental status. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. Working Group Summary The SPFBIS working group had a difficult task ahead as it was not clear how to conclude the SPF and Sender ID Experiments and how to address the IESG Notes in RFC 4405, RFC4406, RFC4407, and RFC4408. There were discussions about how to proceed. Only one proposal was submitted and it was adopted by the working group. The discussions about the RRTYPE 99 DNS Resource Record were controversial. The issue was resolved. There was consensus that Sender ID re-use of SPF DNS Resource Records does not have to be called out in the document. This document represents a best effort by the SPFBIS working group to conclude the experiments which were documented in the above-mentioned RFCs. Document Quality The document does not specify a protocol. The document was reviewed by the SPFBIS working group. Barry Leiba, as an individual, and Dave Crocker performed a thorough review of the document. Personnel S. Moonesamy is the Document Shepherd for this document. Pete Resnick is the Responsible Area Director. From sm@resistor.net Wed Jun 27 10:15:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E38521F8675 for ; Wed, 27 Jun 2012 10:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjrdYXmSXEoI for ; Wed, 27 Jun 2012 10:15:42 -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 D5F9C21F866B for ; Wed, 27 Jun 2012 10:15:42 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5RHFYdH007158; Wed, 27 Jun 2012 10:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340817340; bh=+N/jqbweaJ6hjloPXARmoK+0NzOqh61RKyuSsd/AluQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=07VvsjJ4j0nuz1L2kF4FPyWy3hoHmbT1DNBSQFzTic20CTCKwqkfxqfvcjgelIvfa 0XpMa2f4VmM+IW9ATmoiSJvfdWSp2yD2Fn7K7TMJm0u2MMYuGKaJ4QM82PFluZpneT bpJxhfXeQ91fcz5A1egIbPmND+JQbkmKlQbNvxjM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340817340; i=@resistor.net; bh=+N/jqbweaJ6hjloPXARmoK+0NzOqh61RKyuSsd/AluQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oWU54Sl6PZghjh4eAsh+zYNYmhs1Sf+3hQLHzswB2jrkElzxZocNxYtgYrFZ66h+N ox87SqiOcVq/VtiV43Vx35bhShXVTtip3gS6SY1G6I4+kMgSH3Sx86g6WJvAOdcXTx y/pGVv6XdUA2j2IQCnfEbjSOOAggT/HeAF3UKbyA= Message-Id: <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Jun 2012 10:08:51 -0700 To: Scott Kitterman From: SM In-Reply-To: <1946853.36BUztoKUg@scott-latitude-e6320> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 17:15:47 -0000 Hi Scott, At 22:22 26-06-2012, Scott Kitterman wrote: >Since there have been a fair number of changes already since the 00 draft and >I'll be offline most of tomorrow, I wanted to leave you with the >current state >of the work to consider. In addition to the updated draft, there's an rfcdiff I'll raise a few points to start the discussion. Some of them might be outside the scope of the charter. I suggest opening them as new issues if you consider it as appropriate. In Section 2.5.5: 'The domain owner wants to discourage the use of this host and thus desires limited feedback when a "softfail" result occurs. For example, the recipient's Mail User Agent (MUA) could highlight the "softfail" status, or the receiving MTA could give the sender a message using a technique called "greylisting" whereby the MTA can issue an SMTP reply code of 451 (4.3.0 enhanced status code) with a note the first time the message is received, but accept it the second time.' The SMTP reply code is incorrect. It should be a 450. In Section 5.0: "When any mechanism fetches host addresses to compare with , when is an IPv4 address, A records are fetched, when is an IPv6 address, AAAA records are fetched. Even if the SMTP connection is via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section 2.5.5) MUST still be considered an IPv4 address and MUST be evaluated using IPv4 mechanisms (i.e. "ip4" and "a")." The reference for RFC 3513 should be updated to RFC 4291. In Section 5.4: 'Note regarding implicit MXs: If the has no MX records, check_host() MUST NOT pretend the target is its single MX, and MUST NOT default to an A lookup on the directly. This behavior breaks with the legacy "implicit MX" rule. See [RFC5321], Section 5. If such behavior is desired, the publisher should specify an "a" directive.' This should also cover IPv6 as RFC 5321 kept the implicit MX rule. Section 5.5 lists "ptr" as deprecated. That's issue #27. As a stylistic comment, this could be moved to an appendix. In Section 8.1: "i p = the validated domain name of (deprecated)" The should be p. In Section 9.3: "Note that due to the 63-character limit for domain labels, this approach only works reliably if the localpart signature scheme is guaranteed either to only produce localparts with a maximum of 63 characters or to gracefully handle truncated localparts." That should be 63-octet limit. "63 characters" should be "63 octets". Section 1.2 should be removed. I suggest leaving Section 12.2 until the issue is resolved. Regards, -sm From hsantos@isdg.net Wed Jun 27 14:46:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C91021F85C5 for ; Wed, 27 Jun 2012 14:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVvGgkx+9DxR for ; Wed, 27 Jun 2012 14:46:11 -0700 (PDT) Received: from winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6BE21F85BB for ; Wed, 27 Jun 2012 14:46:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1585; t=1340833569; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=D9vjKGERU8ZUdU1ECOFX92WTsjM=; b=dBc5TtZ3HSrTPrCFNxtX pDWY1kSMQ+RgMn1Su9DbDLb0mSoAn9JVmjHwSxKAUBzeykLFOk21bHQYjr7Iu4qV d0r9I8a4TGxxdnZQ/4NRQVpxi4cjQdAmxY4mPf8C31PG15Pfdu/f7aL+GxNbOcQe nBJv7zmsTrnD1H9buUQPVDw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 27 Jun 2012 17:46:09 -0400 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 1150387432.1600.5588; Wed, 27 Jun 2012 17:46:08 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1585; t=1340833473; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=eTUa2iU pqxOk9FLtbCfTV8Dg8g5fhZAoYTnCpPkhr+0=; b=o0PYd099vLe3DFP0Ora0PIZ do52AsPle87tg+G/xbPhYwGkQQb5Q/lIwirBckW/ct4JXnwiHN/TdbNcqs8cMq2g TcdbNbV0UoSTKJDf/84rLJp/UXSEKpTYI5RFHy+5FFpE/SPleNiJvj7EAMjuZpQQ uOj65qmwe3CrJ4ATRoBw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 27 Jun 2012 17:44:33 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1749239473.9.3620; Wed, 27 Jun 2012 17:44:33 -0400 Message-ID: <4FEB7F1F.1060704@isdg.net> Date: Wed, 27 Jun 2012 17:46:07 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> In-Reply-To: <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 21:46:12 -0000 SM wrote: > Hi Scott, > I'll raise a few points to start the discussion. Some of them might be > outside the scope of the charter. I suggest opening them as new issues > if you consider it as appropriate. > > In Section 2.5.5: > > 'The domain owner wants to discourage the use of this host and thus > desires limited feedback when a "softfail" result occurs. For > example, the recipient's Mail User Agent (MUA) could highlight the > "softfail" status, or the receiving MTA could give the sender a > message using a technique called "greylisting" whereby the MTA can > issue an SMTP reply code of 451 (4.3.0 enhanced status code) with a > note the first time the message is received, but accept it the second > time.' > > The SMTP reply code is incorrect. It should be a 450. Incorrect would be incorrect. If it was, than you would be suggesting a MUST I believe. I agree the text can be cleaned up, perhaps also add examples of both should be provided. 451 is already in play (especially for non-extended-code SMTP deployments) and at the end of the (SPF WG) day, backward compatibility is more important. Stating something (like this) as incorrect leads to (invites) throwing the SPF-BIS book at people who in my view, will take a while before they pencil in the time to update their wares with the presumption there is not going to be any breakage or labeling of non-compliance. I just wanted to point out I am not expecting that the update to SPF to become a requirement nor becomes an venue to make existing SPF systems non-compliant. -- HLS From sm@resistor.net Wed Jun 27 16:39:25 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 B606221F85CD for ; Wed, 27 Jun 2012 16:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfhcUIqfJHUR for ; Wed, 27 Jun 2012 16:39:15 -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 CF04D11E812C for ; Wed, 27 Jun 2012 16:25:32 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5RNPJxe005247; Wed, 27 Jun 2012 16:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340839531; bh=nKxUMqmlEphFYSp1X6U6FDmZPBmpJSVAS6SkOLQJCO4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cTH4YUTkcJdqBDzEpNr2jeJ+t3URhqyeGxHmas3Moyc7pVfFsxVQPgK37s/KmEI/D dkEY+NYBnOPjWFz6kWLxCLkgbp7REtw4UuBQCU38nlH+ipwts+zz+9c99r6gC5DM2P pkiaSSA325e9GdEy9ghySNt4chyfGHhkjhrTuoXs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340839531; i=@resistor.net; bh=nKxUMqmlEphFYSp1X6U6FDmZPBmpJSVAS6SkOLQJCO4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=crQMCo9j1hwuv7NHSSI4xGq6/WgiSD77rNBbXvz7M44I52zab1BiKxsn0eFdO5Hwj g7NM0ha1qPeYgSq4ucWqft0PuJPywHhgq1arZxnCRdJ+4vnCjBZvGw4JQt2pebHmjS DbP5+wD3tZ87LaevtK1kE30GfOAjL/n7YA8B2R/I= Message-Id: <6.2.5.6.2.20120627162003.08c2fc98@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Jun 2012 16:24:37 -0700 To: Hector Santos From: SM In-Reply-To: <4FEB7F1F.1060704@isdg.net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> <4FEB7F1F.1060704@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 23:39:26 -0000 Hi Hector, At 14:46 27-06-2012, Hector Santos wrote: >Incorrect would be incorrect. If it was, than you would be >suggesting a MUST I believe. No, I only make suggestions. As I mentioned previously, it's to start the discussion. I don't have a strong opinion about the points raised. Regards, -sm From spf2@kitterman.com Wed Jun 27 17:01:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA5011E810D for ; Wed, 27 Jun 2012 17:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mDSKmyizBHJ for ; Wed, 27 Jun 2012 17:01:58 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D611911E80E6 for ; Wed, 27 Jun 2012 17:01:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 693CA20E40FC; Wed, 27 Jun 2012 20:01:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340841717; bh=KbWyX+uX3inmOcmVgrSLVVYw/E82sCgTNby5/iizmdA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Ufd0lru4fn5OsLuvu0wMiHqvfX3ivwe6nPutHVV+mdkDI/OIeUu1eoerkLejP+ncc 22f6JYRCcFSFcWr/WCl0ASWwJ2A/6W7xZ04vEMgXwayg/ZqiNhYh/aVZih3Un8Lzod yU7TAZYyd4w0aBy+kqgGzxZ49ICr4JtUaWxXc9OI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4BD5320E4064; Wed, 27 Jun 2012 20:01:57 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 27 Jun 2012 20:01:56 -0400 Message-ID: <1836077.uHDR9kK743@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 00:01:58 -0000 On Wednesday, June 27, 2012 10:08:51 AM SM wrote: > In Section 5.0: > > "When any mechanism fetches host addresses to compare with , when > is an IPv4 address, A records are fetched, when is an IPv6 > address, AAAA records are fetched. Even if the SMTP connection is > via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section > 2.5.5) MUST still be considered an IPv4 address and MUST be evaluated > using IPv4 mechanisms (i.e. "ip4" and "a")." > > The reference for RFC 3513 should be updated to RFC 4291. Agreed. Done locally. Scott K From spf2@kitterman.com Wed Jun 27 17:25:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C0F21F8554 for ; Wed, 27 Jun 2012 17:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBHxaVKHi1Sf for ; Wed, 27 Jun 2012 17:25:41 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AEF3B21F8551 for ; Wed, 27 Jun 2012 17:25:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 421E620E40FC; Wed, 27 Jun 2012 20:25:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340843141; bh=3kD1QQF9FdLt7lKP/Cm1A+F3V/wQvC3n15mNz6qSkMY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=iQkx2bhaJe1pAfIajFmvYaGvfocYk656TCy1Iwqa7mq4/vgMtp8XeHVkC33mUAhXZ 93XRdFTbqRfLKdjKPPqcphuGCA/p/468fsud9m0t1ZD0Rp6krrbp43uQ5k5UfyTidd GHQQtqxYNTEcVLrhrvydQ//mwesGe+W0PfJO/sa4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 283C020E4064; Wed, 27 Jun 2012 20:25:40 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 27 Jun 2012 20:25:40 -0400 Message-ID: <4405525.H8myQJqHLQ@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 00:25:42 -0000 On Wednesday, June 27, 2012 10:08:51 AM SM wrote: > In Section 5.4: > > 'Note regarding implicit MXs: If the has no MX records, > check_host() MUST NOT pretend the target is its single MX, and MUST > NOT default to an A lookup on the directly. This > behavior breaks with the legacy "implicit MX" rule. See [RFC5321], > Section 5. If such behavior is desired, the publisher should specify > an "a" directive.' > > This should also cover IPv6 as RFC 5321 kept the implicit MX rule. Agreed. I changed A to A or AAAA locally. I think that's sufficient. Scott K From spf2@kitterman.com Wed Jun 27 17:32:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AB111E8135 for ; Wed, 27 Jun 2012 17:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kn5BBHQInKE for ; Wed, 27 Jun 2012 17:32:58 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B069E11E8133 for ; Wed, 27 Jun 2012 17:32:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4130F20E40FC; Wed, 27 Jun 2012 20:32:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340843578; bh=ntFSPQKoqky4fKgW7lI/HWnMLsrr8qkcA4skmQQIbgs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=R4plFxv/CHWlNXWHs2PLHQwzNQTIEqX7jZW+nvdKdEbnEYt79jZieHJFa9qzmh9pl w9WTl7O06/liNRyYFXkDTT74MkQ2ymYzp7EwAsxJaAfdmE8yVyvTGvqPwRtb3yHyYs N+8TzvsQ4JEllTC/AW+VSm93z+/oD9mUz7udbOoE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 23AEF20E4064; Wed, 27 Jun 2012 20:32:57 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 27 Jun 2012 20:32:57 -0400 Message-ID: <1838572.kCaEqzDGts@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 00:32:59 -0000 On Wednesday, June 27, 2012 10:08:51 AM SM wrote: > Section 5.5 lists "ptr" as deprecated. That's issue #27. As a > stylistic comment, this could be moved to an appendix. We aren't removing this (that would be outside the scope of the charter, since it's in use. I think moving it away from the rest of the text about mechanism just reduces understandability. Scott K From superuser@gmail.com Wed Jun 27 18:24: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 C98B021F84EF for ; Wed, 27 Jun 2012 18:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR42AKhs7B+g for ; Wed, 27 Jun 2012 18:24:13 -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 24B1821F85E3 for ; Wed, 27 Jun 2012 17:49:20 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2507657obb.31 for ; Wed, 27 Jun 2012 17:49:19 -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=uN8u46OAjCvGb4JbXcstiEDGeuOAj1oNk4IxviROKvc=; b=gP0CDTXVQ0cxyXUz1PVk3o2rqkQIRAz52F3w9EGVViYHuZL8EqK4YEWQoWJ4asSRTu brNsnIBXGu6OoomL7j4NGEt9AOpBPCYJ9XQj3FkLz/Mu9Dyznw8vOYLz0NIYA9CYIh4E LlZmOWBqy3J5CraTVxb51+oe8KrbyigJrGCKngen1r0SJkZBV3/B0J+NSfdON7eNONiT WklmtB3ccG7uicGBEOyBAB2+arz5neosJygZIPIvZCIFCi4RfX5HaW4K+/hYm8FP7ZbM bvGcJqGLnh84+IIPRHCwe+fS1HU2Z1x3XUrIDFG5LllT7w9JHu6yhG0tjZJTuMRUox7G ut0Q== MIME-Version: 1.0 Received: by 10.182.164.102 with SMTP id yp6mr22691770obb.66.1340844559559; Wed, 27 Jun 2012 17:49:19 -0700 (PDT) Received: by 10.182.66.201 with HTTP; Wed, 27 Jun 2012 17:49:19 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120627162003.08c2fc98@resistor.net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> <4FEB7F1F.1060704@isdg.net> <6.2.5.6.2.20120627162003.08c2fc98@resistor.net> Date: Wed, 27 Jun 2012 17:49:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: multipart/alternative; boundary=e89a8f64354aabed4404c37db33c Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 01:24:13 -0000 --e89a8f64354aabed4404c37db33c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 4:24 PM, SM wrote: > Hi Hector, > > At 14:46 27-06-2012, Hector Santos wrote: > >> Incorrect would be incorrect. If it was, than you would be suggesting a >> MUST I believe. >> > > No, I only make suggestions. As I mentioned previously, it's to start the > discussion. I don't have a strong opinion about the points raised. > > I agree that 450 is the correct code, per RFC5321 Section 4.2.2. We should change it. -MSK --e89a8f64354aabed4404c37db33c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2012 at 4:24 PM, SM <sm@resistor.net> wrote:
Hi Hector,

At 14:46 27-06-2012, Hector Santos wrote:
Incorrect would be incorrect. If it was, than you would be suggesting a MUS= T I believe.

No, I only make suggestions. =A0As I mentioned previously, it's to star= t the discussion. =A0I don't have a strong opinion about the points rai= sed.


I agree that 450 is the correct code, per RFC5321= Section 4.2.2.=A0 We should change it.

-MSK

--e89a8f64354aabed4404c37db33c-- From spf2@kitterman.com Wed Jun 27 18:29:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A07411E808E for ; Wed, 27 Jun 2012 18:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Kr6PbSL5iOG for ; Wed, 27 Jun 2012 18:29:17 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 816F611E8152 for ; Wed, 27 Jun 2012 16:55:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9BF3820E40FC; Wed, 27 Jun 2012 19:55:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340841356; bh=mEuLQr1bopVhAFYAxBt45qUVeI/O1jMYiD8WfXfC18M=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=PaH6MZVcMRX3SpqmpUgQ0+RcbIsJpN9HCz3TuKDF8ndnvJUe6Naqs4FboHtkoURDW hKxc4cJ/dvS0taXKFrz8GJxhwYhmmFD5ihCrVffSfJ0I55gtQHCqZCnklOtOR8c8WD XhISqL0ig0GSZh/5jqR+F1hPGAHgdM69kieUaLvE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8202F20E4064; Wed, 27 Jun 2012 19:55:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 27 Jun 2012 19:55:56 -0400 Message-ID: <8086675.vs2DN6LpnB@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 01:29:17 -0000 On Wednesday, June 27, 2012 10:08:51 AM SM wrote: > In Section 2.5.5: > > 'The domain owner wants to discourage the use of this host and thus > desires limited feedback when a "softfail" result occurs. For > example, the recipient's Mail User Agent (MUA) could highlight the > "softfail" status, or the receiving MTA could give the sender a > message using a technique called "greylisting" whereby the MTA can > issue an SMTP reply code of 451 (4.3.0 enhanced status code) with a > note the first time the message is received, but accept it the second > time.' > > The SMTP reply code is incorrect. It should be a 450. I disagree. This is exemplary text and one could do that. However, since we have a shiny new RFC about greylisting, it would probably be better to refer to it instead of trying to re-explain greylisting here. Scott K From hsantos@isdg.net Wed Jun 27 18:47:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4290A11E8177 for ; Wed, 27 Jun 2012 18:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.922 X-Spam-Level: X-Spam-Status: No, score=-101.922 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsHngViRmxc8 for ; Wed, 27 Jun 2012 18:47:22 -0700 (PDT) Received: from catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 31EDE11E8176 for ; Wed, 27 Jun 2012 18:47:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1174; t=1340848038; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=UhuYj7UVKxYefHnAbgpal96uBJA=; b=W3aRYSsQixG9Rs0zAf+S vEvuDQTF5+/ppBuO5jLw86Ang+nVGke/1KwcThuoeuZn3nbIP/vXz4CS5fZIjOI7 3SKXjR7F6h5jbPhUJ4kFp880m4v/3Oi///8IaGjJ+NfwreD/Lw47LyDlHG6QtrxC c3wR1jwLrjGBKXvamezPjXk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 27 Jun 2012 21:47:18 -0400 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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1164857757.1600.2340; Wed, 27 Jun 2012 21:47:18 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1174; t=1340847944; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=cWC2+BS nP/vNznDUhX4XzCUIl7TWICU2nOkXgE8MXSQ=; b=l6F079FcBCya+8K32pIdFyT 765VQkditDsGAw3JARX2Z193JkIYPXv72ZKY++pWWVq86R44LXQBMj96bbKD02JA vPNMOpecSpnmxThcbtXDsGn8Kedl3lurqrtbkTs2G76HVyWY3wExGF214PMDL6RY Ci4BhWyULp8O0kDPCdXw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 27 Jun 2012 21:45:44 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1763710191.9.2084; Wed, 27 Jun 2012 21:45:44 -0400 Message-ID: <4FEBB7A7.30407@isdg.net> Date: Wed, 27 Jun 2012 21:47:19 -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: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> <4FEB7F1F.1060704@isdg.net> <6.2.5.6.2.20120627162003.08c2fc98@resistor.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 01:47:23 -0000 But it won't reflect reality per its GREYLISTING mentioning. In addition, the grub was the usage of incorrect - it is not incorrect to use any 45z temporary failure code - there are recommendations which MUST also consider the reality not all systems support extended-code responses. Changing it is to add the recommendation for consistency, not to make any current system non-compliant. Thanks 'Murray S. Kucherawy wrote: > On Wed, Jun 27, 2012 at 4:24 PM, SM wrote: > >> Hi Hector, >> >> At 14:46 27-06-2012, Hector Santos wrote: >> >>> Incorrect would be incorrect. If it was, than you would be suggesting a >>> MUST I believe. >>> >> No, I only make suggestions. As I mentioned previously, it's to start the >> discussion. I don't have a strong opinion about the points raised. >> >> > I agree that 450 is the correct code, per RFC5321 Section 4.2.2. We should > change it. > > -MSK > > > > ------------------------------------------------------------------------ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- HLS From spf2@kitterman.com Wed Jun 27 21:01:14 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 BB9E511E81C9 for ; Wed, 27 Jun 2012 21:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiHVgvhtH5rh for ; Wed, 27 Jun 2012 21:01:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1075E11E81C6 for ; Wed, 27 Jun 2012 21:01:13 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2AAB220E40FC; Thu, 28 Jun 2012 00:01:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340856073; bh=HryfvA1gpFdwJDx96Kcc5h0yVS6u16n9jRO660ikH7g=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Y1j4GXnQ1S0SXh1ZWruBY2+FmpAAZjmA0P3OEDVbq3Hf+3lKo52Nput6qd3Yz5S34 0z8iLzWhay6dnZl13q0jd1rpzevddenvj3DCEEyKQWW9i6bBZsSR0KJyclEPpTB6uB 1o+8cHCrIlIOGGephYRbSXA+fTtRzMr3ArRHeMrM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1166820E4064; Thu, 28 Jun 2012 00:01:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 28 Jun 2012 00:01:12 -0400 Message-ID: <1624807.1ZucCtmeVm@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FEBB7A7.30407@isdg.net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <4FEBB7A7.30407@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 04:01:14 -0000 On Wednesday, June 27, 2012 09:47:19 PM Hector Santos wrote: > But it won't reflect reality per its GREYLISTING mentioning. In > addition, the grub was the usage of incorrect - it is not incorrect to > use any 45z temporary failure code - there are recommendations which > MUST also consider the reality not all systems support extended-code > responses. Changing it is to add the recommendation for consistency, > not to make any current system non-compliant. It's not normative text. No change to it can make something compliant or non- compliant (whatever that means in these terms). Scott K From sm@elandsys.com Wed Jun 27 22:39:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10A821F876C for ; Wed, 27 Jun 2012 22:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RLLCS0IuQ-6 for ; Wed, 27 Jun 2012 22:39:16 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 828D911E8097 for ; Wed, 27 Jun 2012 22:27:08 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.142]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5S5QrQF027088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Jun 2012 22:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340861225; bh=by7MilaaXvh7eu6Z0bXs9fRja8YJlsWnsNTmJn+gG8A=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=EelsAPiQUy42w/6CTRswJ8DTk/0ZiwwuRfN5pYNhUZxUJa/1qzwhoJiV63ytkKgS8 dx4sib5xnHlxIW5AqAmVTUBCWK59PdjjM/kxKHqFj1iQJO7YP3GdqFxzgYF795KO01 GCZsWU0FqmICGEyWCcR/NOfuUurZkG7wEDgh7RHQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340861225; i=@elandsys.com; bh=by7MilaaXvh7eu6Z0bXs9fRja8YJlsWnsNTmJn+gG8A=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=r6fheZ9QcorEpbYLDunLKP+VEzz6wTurn/AxagBJKkWnl6bjxUfpT84Q1krq9je7r az7T5TeXSmuQSmn3b5yyArGlzO0WcEvasado8kSO412zoLH6v07blnE6/LlwwjT76+ +0rJAh3imnEqyHJHoiaBFU13hUisG3Hd9TVVXrTg= Message-Id: <6.2.5.6.2.20120627205044.0a8b5120@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Jun 2012 22:17:17 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <8086675.vs2DN6LpnB@scott-latitude-e6320> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> <8086675.vs2DN6LpnB@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Arguing for or against a change (was: I-D Action: draft-ietf-spfbis-4408bis-01.txt) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 05:39:20 -0000 Hello, I'll comment to provide a perspective of what questions might be raised during reviews from outside the working group. I have done that type of review for other drafts. If the reviewer is diligent, he or she might raise the SMTP codes as an issue. The argument that it can be done because it is "exemplary text" might not be strong enough unless it represents the view of a working group. The interoperability argument is better as long as it can be explained clearly. RFC 4408 has not been reviewed by the IETF. I would only pass such a document to the Responsible Area Director with a disclaimer that it represents working group consensus. My opinion is that there would be a number of issues raised during IESG Evaluation. The working group will have to resolve those issues. It will be more work for everyone. Regards, S. Moonesamy From sm@resistor.net Thu Jun 28 02:44:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6BC21F8746 for ; Thu, 28 Jun 2012 02:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwa9swCMdOkV for ; Thu, 28 Jun 2012 02:44:21 -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 D297711E815B for ; Wed, 27 Jun 2012 23:24:39 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5S6OYDK012319 for ; Wed, 27 Jun 2012 23:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340864679; bh=wY1lafwu/u6ihEErs3Uu6RbQxb+tMI9WUhUp/wvXI0k=; h=Date:To:From:Subject:Cc; b=rh55H1daeYRc8myOeWNSTt6sXUCH6az3k8Iy3TTxlPIUzulLtziMnIQybgMdWv9gi 76+YzbX2lhuvqe+nKejxT7ieYNWRTVS9ijw37z/puUl6yaTAMf7Q956HECu66CSKI1 M+45q3ZQOisjkws6MQJAQz3nhNEK27UGcKp1idFw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340864679; i=@resistor.net; bh=wY1lafwu/u6ihEErs3Uu6RbQxb+tMI9WUhUp/wvXI0k=; h=Date:To:From:Subject:Cc; b=EliA/sLYP4q6J7t1FThVLK3elavJWZtwFxF6nVXz2MxlkD+QIrcWv8CaGH5Yu4KWt EcD1LbSGAthJzYNz5FLhoQo5gT0r28iKquhaH34G9cEsbbPQ0LazVx+a7njeFshh7N XCyTx46WTmm5A7q+NemdBAf794B9/8o9Sf3zqhx0= Message-Id: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Jun 2012 23:23:34 -0700 To: spfbis@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 09:44:26 -0000 Hello, Here's a few nits about the references in draft-ietf-spfbis-4408bis-01. The reference to RFC 4409 should be changed to RFC 6409. RFC 2440 should be changed to RFC 4880. RFC 2554 should be changed to RFC 4954. RFC 3851 should be changed to RFC 5751. The reference to RFC 3696 may have to be changed. This will have to be a normative reference. How do existing implementations handle the restriction for TLDs in Section 8.1? Regards, -sm From WebMaster@Commerco.Net Thu Jun 28 03:09: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 7B54621F8796 for ; Thu, 28 Jun 2012 03:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ryxqz3iC63PH for ; Thu, 28 Jun 2012 03:09:10 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id AB22911E80C0 for ; Wed, 27 Jun 2012 21:34:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=tOUJhYFddtbLhziwkF0p/K9+G8ojEtnqK6FwbmR5f3NmzPm+pZu9SrdAacthuGTk2TV/UwtaZ9+A0xwC5hFVtwGfP6gyOwjAXopLZ/l+4XGzuhKHJxZCs/hBQXqnxZ4cgV1D+Jd/IKqJICz7519WqawAtyI4xpypZflkpEM1S0c= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Thu, 28 Jun 2012 04:34:22 +0000 Message-ID: <4FEBDEC7.6040507@Commerco.Net> Date: Wed, 27 Jun 2012 22:34:15 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> <4FEB7F1F.1060704@isdg.net> <6.2.5.6.2.20120627162003.08c2fc98@resistor.net> <4FEBB7A7.30407@isdg.net> In-Reply-To: <4FEBB7A7.30407@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:09:11 -0000 I tend to agree with your point of view on this issue. But, when you think about it, 450 or 451 pretty much both describe an appropriate response to mail servers wanting to defer reception of a message. RFC 821 describes 450 and 451 responses as follows: 450 Requested mail action not taken: mailbox unavailable [E.g., mailbox busy] 451 Requested action aborted: local error in processing Thinking further about it, I think that 451 seems probably the better of the two, but both appear fine to use. Though, if I were running a huge email server farm for a large client base, I'd probably want the 451 used as it could be taken as a more systemic return from a receiver over the 450 return, which is clearly mailbox focused. Polite senders probably would want to respect the 451 as systemic and back off on sending any other messages to that receiver which they might have to send when the receiver issues the 451. That probably would make the grey listing routines on the receiver a bit happier (or minimally the network admin, as it also implies reduced traffic from junk retries by the sender until the greylist period on the receiver ends). Also, as Scott K mentioned in another response, the new RFC regarding greylisting should probably become the place pointed to for the authoritative answer on the matter going forward. Alan M. On 6/27/2012 7:47 PM, Hector Santos wrote: > But it won't reflect reality per its GREYLISTING mentioning. In > addition, the grub was the usage of incorrect - it is not incorrect to > use any 45z temporary failure code - there are recommendations which > MUST also consider the reality not all systems support extended-code > responses. Changing it is to add the recommendation for consistency, not > to make any current system non-compliant. > > Thanks > > 'Murray S. Kucherawy wrote: >> On Wed, Jun 27, 2012 at 4:24 PM, SM wrote: >> >>> Hi Hector, >>> >>> At 14:46 27-06-2012, Hector Santos wrote: >>> >>>> Incorrect would be incorrect. If it was, than you would be suggesting a >>>> MUST I believe. >>>> >>> No, I only make suggestions. As I mentioned previously, it's to start >>> the >>> discussion. I don't have a strong opinion about the points raised. >>> >>> >> I agree that 450 is the correct code, per RFC5321 Section 4.2.2. We >> should >> change it. >> >> -MSK >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis > From superuser@gmail.com Thu Jun 28 07:10:01 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 1763321F8518 for ; Thu, 28 Jun 2012 07:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWxhg7q6g5TF for ; Thu, 28 Jun 2012 07:10:00 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E18DD21F853A for ; Thu, 28 Jun 2012 07:09:56 -0700 (PDT) Received: by bkty8 with SMTP id y8so2207868bkt.31 for ; Thu, 28 Jun 2012 07:09:56 -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=Pwkddl56/fghNWkxvvP6b8PF2i7xGha1XZDuoU5bTGo=; b=gU3H9OCtmq2GAeIBG+lWmmCaYoSR55JC8X5uSXdxlKB+vEER9aRJfDRkcrDOuQkl7f lAdtRi3XglJqITA8JISAndxmR0ny1qx6qnS7vnCUXjMpeZJvTdczN1I73JU7zlWk5Wxz krabSz3eKGe4oGLzAytKazY2lrWBaMy6CE0cDYg0SWRjPdP5Aid/rWTkG1yaK11oLNdV r+rkawXbA6j8Bvpxxd9CAip8cCigKMiKU2l2PAe2vavIYACbUVJSGVis3LdyKBHsXimK 6mhiLCOiBVx9WsB+oWBWMz1LeIRSN/uq4aTdUGJ3dN0Lb79xjcY5vyN1uU1bR0zH8nKW Izww== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr2309042lab.40.1340892595844; Thu, 28 Jun 2012 07:09:55 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 28 Jun 2012 07:09:55 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120627205044.0a8b5120@resistor.net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> <8086675.vs2DN6LpnB@scott-latitude-e6320> <6.2.5.6.2.20120627205044.0a8b5120@resistor.net> Date: Thu, 28 Jun 2012 07:09:55 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d040838d3db743f04c388e24e Cc: spfbis@ietf.org Subject: Re: [spfbis] Arguing for or against a change (was: I-D Action: draft-ietf-spfbis-4408bis-01.txt) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 14:10:01 -0000 --f46d040838d3db743f04c388e24e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 10:17 PM, S Moonesamy wrote: > I'll comment to provide a perspective of what questions might be raised > during reviews from outside the working group. I have done that type of > review for other drafts. If the reviewer is diligent, he or she might > raise the SMTP codes as an issue. The argument that it can be done because > it is "exemplary text" might not be strong enough unless it represents the > view of a working group. The interoperability argument is better as long > as it can be explained clearly. > The working group should expect and welcome those reviews, as they only strengthen our position once we consider the feedback they provide. I would even seek some of them out. Without those reviews, the IESG would be within their rights to ask more questions. We always have a stronger position if we can show that the document has had more broad review than if it has not. > > RFC 4408 has not been reviewed by the IETF. I would only pass such a > document to the Responsible Area Director with a disclaimer that it > represents working group consensus. My opinion is that there would be a > number of issues raised during IESG Evaluation. The working group will > have to resolve those issues. It will be more work for everyone. > > That's not a disclaimer, it's a requirement. We can't send documents from working groups to the IESG that don't have at least rough consensus. The stronger that consensus is, and the more it's clear we've done due diligence on all major points in the document, the easier the ride is through IESG evaluation. Thus, we should resolve those issues before they get to the IESG, not after. -MSK --f46d040838d3db743f04c388e24e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 27, 2012 at 10:17 PM, S Moonesamy <sm+ietf@elandsys.com> wrote:
I'll comment to provide a perspective of what questions might be raised= during reviews from outside the working group. =A0I have done that type of= review for other drafts. =A0If the reviewer is diligent, he or she might r= aise the SMTP codes as an issue. =A0The argument that it can be done becaus= e it is "exemplary text" might not be strong enough unless it rep= resents the view of a working group. =A0The interoperability argument is be= tter as long as it can be explained clearly.

The working group should expect and welcome those rev= iews, as they only strengthen our position once we consider the feedback th= ey provide.=A0 I would even seek some of them out.=A0 Without those reviews= , the IESG would be within their rights to ask more questions.=A0 We always= have a stronger position if we can show that the document has had more bro= ad review than if it has not.
=A0

RFC 4408 has not been reviewed by the IETF. =A0I would only pass such a doc= ument to the Responsible Area Director with a disclaimer that it represents= working group consensus. =A0My opinion is that there would be a number of = issues raised during IESG Evaluation. =A0The working group will have to res= olve those issues. =A0It will be more work for everyone.


That's not a disclaimer, it's a requireme= nt.=A0 We can't send documents from working groups to the IESG that don= 't have at least rough consensus.=A0 The stronger that consensus is, an= d the more it's clear we've done due diligence on all major points = in the document, the easier the ride is through IESG evaluation.=A0 Thus, w= e should resolve those issues before they get to the IESG, not after.

-MSK
--f46d040838d3db743f04c388e24e-- From superuser@gmail.com Thu Jun 28 07:18:07 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 D92CF21F84DC for ; Thu, 28 Jun 2012 07:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm9VBvWcY-2w for ; Thu, 28 Jun 2012 07:18:06 -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 BB6B821F84C5 for ; Thu, 28 Jun 2012 07:17:59 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3447452lbb.31 for ; Thu, 28 Jun 2012 07:17:58 -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=7yqY9YSJ1+DPFn5uQdGp0PCi2+Z0G2nbuI515/GYfHc=; b=q0lGdWN3d4eBOUfUbZlO4hT1RMNNDRVg03SNYFS+0VG1A6eNP9l2As9KTzk2GqqS1Y q+QhhjKqXw37KkKA/rjjHhjlzEaht6CKMG0nKEiLqnQdqvh9mQ97xq3nyjHx6daGiiyP gFFDl1T2FXaoK+Y8jVuaO1m5OMgcx793xePqfUpuIRf00GVYAY7+zr7jgE0DkC5GRG1y cjUGBHpjlGyGFfnr0yMfirZh9OfA4IlKwd+izXOa7Lm8HMVYMSwmV6BuDHPxrbMJ6WqA n3pXzkvmw92Psdi18ACtJxgW5WUyMHLU630/GuxB2ifliFvjgTCLMxCce1583l2+RJqG cfag== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr2453710lab.9.1340893078611; Thu, 28 Jun 2012 07:17:58 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 28 Jun 2012 07:17:58 -0700 (PDT) In-Reply-To: <4FEBDEC7.6040507@Commerco.Net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> <4FEB7F1F.1060704@isdg.net> <6.2.5.6.2.20120627162003.08c2fc98@resistor.net> <4FEBB7A7.30407@isdg.net> <4FEBDEC7.6040507@Commerco.Net> Date: Thu, 28 Jun 2012 07:17:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: Commerco WebMaster Content-Type: multipart/alternative; boundary=e89a8f22c411a1e68704c388ff97 Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 14:18:08 -0000 --e89a8f22c411a1e68704c388ff97 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 9:34 PM, Commerco WebMaster wrote: > I tend to agree with your point of view on this issue. But, when you > think about it, 450 or 451 pretty much both describe an appropriate > response to mail servers wanting to defer reception of a message. > > RFC 821 describes 450 and 451 responses as follows: > 450 Requested mail action not taken: mailbox unavailable > [E.g., mailbox busy] > 451 Requested action aborted: local error in processing > RFC5321 is the current SMTP specification. Operationally, I'm sure they're identical. But by the specs, 451 is wrong. An SPF failure or a decision to grey list result in policy actions, not local errors. The greylisting RFC (RFC6647) also recommends 450 if the MTA is not going to drop the connection. I think the idea that people have implemented an expectation of 451 to mean "SPF failure" would be a hack, because (a) it's wrong and (b) does anyone actually look at the third digit, much less the second? (Except maybe passing the whole thing to atoi(), and then checking if it's between 400 and 499.) We don't need to write RFCs to support things like that. Or are we saying that people actually treat 451 specially? -MSK --e89a8f22c411a1e68704c388ff97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 27, 2012 at 9:34 PM, Commerco WebMaster <<= a href=3D"mailto:WebMaster@commerco.net" target=3D"_blank">WebMaster@commer= co.net> wrote:
I tend to agree with your point of view on this issue. =A0But, when you thi= nk about it, 450 or 451 pretty much both describe an appropriate response t= o mail servers wanting to defer reception of a message.

RFC 821 describes 450 and 451 responses as follows:
450 Requested mail action not taken: mailbox unavailable
=A0 [E.g., mailbox busy]
451 Requested action aborted: local error in processing

RFC5321 is the current SMTP specification.=A0

Operationally, = I'm sure they're identical.=A0 But by the specs, 451 is wrong.=A0 A= n SPF failure or a decision to grey list result in policy actions, not loca= l errors.

The greylisting RFC (RFC6647) also recommends 450 if the MTA is not goi= ng to drop the connection.
=A0
I think the idea that people have impl= emented an expectation of 451 to mean "SPF failure" would be a ha= ck, because (a) it's wrong and (b) does anyone actually look at the thi= rd digit, much less the second?=A0 (Except maybe passing the whole thing to= atoi(), and then checking if it's between 400 and 499.)=A0 We don'= t need to write RFCs to support things like that.

Or are we saying that people actually treat 451 specially?

-MSK
--e89a8f22c411a1e68704c388ff97-- From spf2@kitterman.com Thu Jun 28 08:22:39 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 A416121F847C for ; Thu, 28 Jun 2012 08:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0IVLpcW878V for ; Thu, 28 Jun 2012 08:22:38 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6184621F8474 for ; Thu, 28 Jun 2012 08:22:37 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6842720E40FC; Thu, 28 Jun 2012 11:22:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340896956; bh=fm3VnhR3ntBvuCaHVOjJaJKbH9X29DNOTtTHuc8rRqA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=V/J6uUwVvp/ZJaK7NBTjn1+MgmqXG+3MWYFEVvGtg0KjOTgGbgSothniVCbD4XIei wEP0tzn9rqLveW0VTupKYTNbO1S5zrLrQ/HSM9TZqK4pn8K82Jdl8vKlWDh/yhGUp+ dQ7IpaqXtCfn4St5frE3Qrx5svd+rzpgQ2N6qA1U= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4AD7920E403E; Thu, 28 Jun 2012 11:22:36 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 28 Jun 2012 11:22:35 -0400 Message-ID: <31935435.16CnW35jdf@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <4FEBDEC7.6040507@Commerco.Net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:22:39 -0000 On Thursday, June 28, 2012 07:17:58 AM Murray S. Kucherawy wrote: > On Wed, Jun 27, 2012 at 9:34 PM, Commerco WebMaster > > wrote: > > I tend to agree with your point of view on this issue. But, when you > > think about it, 450 or 451 pretty much both describe an appropriate > > response to mail servers wanting to defer reception of a message. > > > > RFC 821 describes 450 and 451 responses as follows: > > 450 Requested mail action not taken: mailbox unavailable > > > > [E.g., mailbox busy] > > > > 451 Requested action aborted: local error in processing > > RFC5321 is the current SMTP specification. > > Operationally, I'm sure they're identical. But by the specs, 451 is > wrong. An SPF failure or a decision to grey list result in policy actions, > not local errors. > > The greylisting RFC (RFC6647) also recommends 450 if the MTA is not going > to drop the connection. > > I think the idea that people have implemented an expectation of 451 to mean > "SPF failure" would be a hack, because (a) it's wrong and (b) does anyone > actually look at the third digit, much less the second? (Except maybe > passing the whole thing to atoi(), and then checking if it's between 400 > and 499.) We don't need to write RFCs to support things like that. > > Or are we saying that people actually treat 451 specially? I don't think they do and I agree that if they do, they are wrong. Since RFC 6647 already tells us which color to paint the bikeshed, here's the change I'm made locally. Are there objections: example, the recipient's Mail User Agent (MUA) could highlight the "softfail" status, or the receiving MTA could give the sender a - message using a technique called "greylisting" whereby the MTA can - issue an SMTP reply code of 451 (4.3.0 enhanced status code) with a - note the first time the message is received, but accept it the second - time. + message using greylisting, [RFC6647], with a note the first time + the message is received, but accept it the second time. Scott K From WebMaster@Commerco.Net Thu Jun 28 09:29:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1672E21F8585 for ; Thu, 28 Jun 2012 09:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-FgMV6xTiGo for ; Thu, 28 Jun 2012 09:29:58 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 59C2A21F8539 for ; Thu, 28 Jun 2012 09:29:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=hdkC16qfj44ppt+UoYWTPaAsvxaMxyY3wTDR7P86z5Mmcttl8ygWOBzlRVKbcFymL2EpFepl2LYEaFFdrg+taC9XE563BywJV3uL73rXP+i4mQK+h+oVlbfB+BuxpaeSYz9GU6dv+sDonvAt50bLdrXeIPivpCax0Kef6vKVsKU= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]); Thu, 28 Jun 2012 16:29:53 +0000 Message-ID: <4FEC867A.8090301@Commerco.Net> Date: Thu, 28 Jun 2012 10:29:46 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1946853.36BUztoKUg@scott-latitude-e6320> <6.2.5.6.2.20120627091630.0a89baf8@resistor.net> <4FEB7F1F.1060704@isdg.net> <6.2.5.6.2.20120627162003.08c2fc98@resistor.net> <4FEBB7A7.30407@isdg.net> <4FEBDEC7.6040507@Commerco.Net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:29:59 -0000 On 6/28/2012 8:17 AM, Murray S. Kucherawy wrote: > On Wed, Jun 27, 2012 at 9:34 PM, Commerco WebMaster > > wrote: > > I tend to agree with your point of view on this issue. But, when > you think about it, 450 or 451 pretty much both describe an > appropriate response to mail servers wanting to defer reception of a > message. > > RFC 821 describes 450 and 451 responses as follows: > 450 Requested mail action not taken: mailbox unavailable > [E.g., mailbox busy] > 451 Requested action aborted: local error in processing > > > RFC5321 is the current SMTP specification. True, but I only referred to 821 because it was the base for SMTP and over the many years I have observed these working group lists, most all of them desire to maintain interoperability with the older RFCs. Thus, my leap back to the very beginning. RFC 5321 describes 450 and 451 responses as follows: 450 Requested mail action not taken: mailbox unavailable (e.g., mailbox busy or temporarily blocked for policy reasons) 451 Requested action aborted: local error in processing > > Operationally, I'm sure they're identical. But by the specs, 451 is > wrong. An SPF failure or a decision to grey list result in policy > actions, not local errors. > > The greylisting RFC (RFC6647) also recommends 450 if the MTA is not > going to drop the connection. > > I think the idea that people have implemented an expectation of 451 to > mean "SPF failure" would be a hack, because (a) it's wrong and (b) does > anyone actually look at the third digit, much less the second? (Except > maybe passing the whole thing to atoi(), and then checking if it's > between 400 and 499.) We don't need to write RFCs to support things > like that. > > Or are we saying that people actually treat 451 specially? I would also agree that a percentage (perhaps a large percentage) of folks may not code to the third digit to address greylisting, but that said, I don't know that to be true. Perhaps I am a bit weird that way, but I do look at each send and return as specified in an RFC as discrete and different events in anything I code to work with an RFC described protocol. I also depend upon backward compatibility within the same protocol. My point, however, was that a systemic response, rather than a per box response, arguably might make it easier on the receivers. Bottom line, I am entirely neutral on what 45x error is used. RFC 6647 recommends 450? So be it (although I think that point requiring the MTA not dropping the connection could lead to some foreseeable resource [dos] style attacks by forcing a receiver to keep sockets open). > > -MSK > Alan M. From spf2@kitterman.com Thu Jun 28 09:33:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4397221F852D for ; Thu, 28 Jun 2012 09:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs8TyBtOLi6u for ; Thu, 28 Jun 2012 09:32:53 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8E72F21F84D1 for ; Thu, 28 Jun 2012 09:32:53 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CDCDD20E40FC; Thu, 28 Jun 2012 12:32:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340901172; bh=38YvUClPhbcb+ZZKS+W6xtfbVgEJRD6qF/1Ssm6kXqI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=BaLRDnGIq8xHh6kjbeeHRktGFkntrVyeKq2lO4PQxuGKm3rkFGLdfuzBrNiuhHzlx OztLv1hsWEsSfS4EtkJ8DGJTUg/1HXAZa/9AkfKSp6cS0tLy5m7HBWuv4XJy73tToI CL4OpujJwVPHIyBj83Hi2gHKdD5lTryFU1sQ+Sjw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B03D420E403E; Thu, 28 Jun 2012 12:32:52 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 28 Jun 2012 12:32:52 -0400 Message-ID: <121909424.1Q2iX6uX2m@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> References: <6.2.5.6.2.20120627230533.09253e18@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] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 16:33:00 -0000 On Wednesday, June 27, 2012 11:23:34 PM SM wrote: > Hello, > > Here's a few nits about the references in > draft-ietf-spfbis-4408bis-01. The reference to > RFC 4409 should be changed to RFC 6409. RFC 2440 should be changed > to RFC 4880. RFC 2554 should be changed to RFC 4954. RFC 3851 > should be changed to RFC 5751. I've been working through the nits page for the latest draft. I'm trying to address all the reference and ABNF nits (added a section on imported definitions. These are all fixed. Nits also whines about possible downref to US-ASCII. Can I assume that complaint is safe to ignore? > The reference to RFC 3696 may have to be changed. This will have to > be a normative reference. How do existing implementations handle the > restriction for TLDs in Section 8.1? For pyspf, the implemented test is fairly basic. The TLD can't be all numeric or start/end with a hyphen. I think 3696 is informational. I looked at some other related RFCs. The current DKIM RFC points at 5321 for domain name and it says: Domain = sub-domain *("." sub-domain) sub-domain = Let-dig [Ldh-str] Given that the underlying email protocol we're building on doesn't specify special treatment for TLD naming, I think that the reference to 3696 is a helpful hint for implementors that may want to get local efficiencies. Reference to it isn't essential for interoperability. Scott K From WebMaster@Commerco.Net Thu Jun 28 09:44:25 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 C247521F8526 for ; Thu, 28 Jun 2012 09:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWEntwmLtzLo for ; Thu, 28 Jun 2012 09:44:25 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id D656221F850D for ; Thu, 28 Jun 2012 09:44:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=SlKfckYtr/56WkSWtCCBq6w3sM0VLOIDBXi7iegY8slO9wdLoPgXWSBSJczvD/OzId/0Fn9rcboMbKBKc/L06N1Z0ku7uP3tI+j5hEj/0wNwYT+JI+SLUGeCkEpNDF1qh24vmY1ZRUVhtsMwFMO2XxiVA4PB0Td/xoh8CvrwQKw= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]); Thu, 28 Jun 2012 16:44:20 +0000 Message-ID: <4FEC89DD.9080203@Commerco.Net> Date: Thu, 28 Jun 2012 10:44:13 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Scott Kitterman References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <4FEBDEC7.6040507@Commerco.Net> <31935435.16CnW35jdf@scott-latitude-e6320> In-Reply-To: <31935435.16CnW35jdf@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:44:25 -0000 On 6/28/2012 9:22 AM, Scott Kitterman wrote: > On Thursday, June 28, 2012 07:17:58 AM Murray S. Kucherawy wrote: >> On Wed, Jun 27, 2012 at 9:34 PM, Commerco WebMaster >> >> wrote: >>> I tend to agree with your point of view on this issue. But, when you >>> think about it, 450 or 451 pretty much both describe an appropriate >>> response to mail servers wanting to defer reception of a message. >>> >>> RFC 821 describes 450 and 451 responses as follows: >>> 450 Requested mail action not taken: mailbox unavailable >>> >>> [E.g., mailbox busy] >>> >>> 451 Requested action aborted: local error in processing >> >> RFC5321 is the current SMTP specification. >> >> Operationally, I'm sure they're identical. But by the specs, 451 is >> wrong. An SPF failure or a decision to grey list result in policy actions, >> not local errors. >> >> The greylisting RFC (RFC6647) also recommends 450 if the MTA is not going >> to drop the connection. >> >> I think the idea that people have implemented an expectation of 451 to mean >> "SPF failure" would be a hack, because (a) it's wrong and (b) does anyone >> actually look at the third digit, much less the second? (Except maybe >> passing the whole thing to atoi(), and then checking if it's between 400 >> and 499.) We don't need to write RFCs to support things like that. >> >> Or are we saying that people actually treat 451 specially? > > I don't think they do and I agree that if they do, they are wrong. Since RFC > 6647 already tells us which color to paint the bikeshed, here's the change I'm > made locally. Are there objections: > > example, the recipient's Mail User Agent (MUA) could highlight the > "softfail" status, or the receiving MTA could give the sender a > - message using a technique called "greylisting" whereby the MTA can > - issue an SMTP reply code of 451 (4.3.0 enhanced status code) with a > - note the first time the message is received, but accept it the second > - time. > + message using greylisting, [RFC6647], with a note the first time > + the message is received, but accept it the second time. > > Scott K Existing greylisting implementations differ. Given that reality, I'm not sure that one can demand the server arbitrarily accept the message the second time it is sent. That strategy could be abused in foreseeable ways, thus effectively defeating the purpose of greylisting. Rather I would submit employing the logic implied in regular mail delivery: Attempt, fail, back off some period of time. Reattempt, fail, back off some larger period of time. Reattempt as in the prior step until either the send attempts maximum value of the sender applies or the message is delivered. Perhaps this more vague wording which allows the receiver more latitude might suffice: + message using greylisting, [RFC6647], with a note when + the message is received, but accept on a later attempt + as defined by the receiver. Alan M. From spf2@kitterman.com Thu Jun 28 09:48:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A4721F8513 for ; Thu, 28 Jun 2012 09:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZF1tpxOEf4G8 for ; Thu, 28 Jun 2012 09:48:41 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D037F21F850D for ; Thu, 28 Jun 2012 09:48:40 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3480720E40FC; Thu, 28 Jun 2012 12:48:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340902119; bh=fodZ7X5hDhWslpUj0kEUFd2w+XHmB6lC843DP4LR6Pk=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=DGHhhecyjHVYD0I1k+S/M1wVr7U0K5l3tsQx4rIzlGXfQD462/BAjqjBIFIg53ARj w8+EQJTzxSQsPWvqrOSKhb+dZjfyp5rHnr1DqIDvnRD2N3B60IvsJObPzbeu2MNMUp Ad0bJxxuZf3GDwWh5CEE0LDskNw8QtzCaeBqJ7yY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1720820E403E; Thu, 28 Jun 2012 12:48:38 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 28 Jun 2012 12:48:38 -0400 Message-ID: <1404637.xT9T34QnEg@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FEC89DD.9080203@Commerco.Net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <31935435.16CnW35jdf@scott-latitude-e6320> <4FEC89DD.9080203@Commerco.Net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:48:42 -0000 On Thursday, June 28, 2012 10:44:13 AM Commerco WebMaster wrote: > On 6/28/2012 9:22 AM, Scott Kitterman wrote: > > On Thursday, June 28, 2012 07:17:58 AM Murray S. Kucherawy wrote: > >> On Wed, Jun 27, 2012 at 9:34 PM, Commerco WebMaster > >> > >> wrote: > >>> I tend to agree with your point of view on this issue. But, when you > >>> think about it, 450 or 451 pretty much both describe an appropriate > >>> response to mail servers wanting to defer reception of a message. > >>> > >>> RFC 821 describes 450 and 451 responses as follows: > >>> 450 Requested mail action not taken: mailbox unavailable > >>> > >>> [E.g., mailbox busy] > >>> > >>> 451 Requested action aborted: local error in processing > >> > >> RFC5321 is the current SMTP specification. > >> > >> Operationally, I'm sure they're identical. But by the specs, 451 is > >> wrong. An SPF failure or a decision to grey list result in policy > >> actions, > >> not local errors. > >> > >> The greylisting RFC (RFC6647) also recommends 450 if the MTA is not going > >> to drop the connection. > >> > >> I think the idea that people have implemented an expectation of 451 to > >> mean > >> "SPF failure" would be a hack, because (a) it's wrong and (b) does anyone > >> actually look at the third digit, much less the second? (Except maybe > >> passing the whole thing to atoi(), and then checking if it's between 400 > >> and 499.) We don't need to write RFCs to support things like that. > >> > >> Or are we saying that people actually treat 451 specially? > > > > I don't think they do and I agree that if they do, they are wrong. Since > > RFC 6647 already tells us which color to paint the bikeshed, here's the > > change I'm> > > made locally. Are there objections: > > example, the recipient's Mail User Agent (MUA) could highlight the > > "softfail" status, or the receiving MTA could give the sender a > > > > - message using a technique called "greylisting" whereby the MTA can > > - issue an SMTP reply code of 451 (4.3.0 enhanced status code) with a > > - note the first time the message is received, but accept it the second > > - time. > > + message using greylisting, [RFC6647], with a note the first time > > + the message is received, but accept it the second time. > > > > Scott K > > Existing greylisting implementations differ. Given that reality, I'm > not sure that one can demand the server arbitrarily accept the message > the second time it is sent. That strategy could be abused in > foreseeable ways, thus effectively defeating the purpose of greylisting. > Rather I would submit employing the logic implied in regular mail > delivery: > > Attempt, fail, back off some period of time. > > Reattempt, fail, back off some larger period of time. > > Reattempt as in the prior step until either the send attempts maximum > value of the sender applies or the message is delivered. > > Perhaps this more vague wording which allows the receiver more latitude > might suffice: > + message using greylisting, [RFC6647], with a note when > + the message is received, but accept on a later attempt > + as defined by the receiver. Keep in mind this is an example. It's totally non-normative. I'm fine either way, but I don't think it merits a lot of discussion. Scott K From sm@elandsys.com Thu Jun 28 10:33:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78FE21F8458 for ; Thu, 28 Jun 2012 10:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gijyLIu-uyzy for ; Thu, 28 Jun 2012 10:33:38 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FEE21F8504 for ; Thu, 28 Jun 2012 10:33:38 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.142]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5SHXHii011173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Jun 2012 10:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340904816; bh=ForMWQPdoZATDu0R0UnJxHp7hOfFjb/5M4MXVUI+zE4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=ISHSSL2D2ZC2apAuOUaIkuA1D06O+F0mtam+YrRGTatTz7teRTeTmBH4t3d0o7tix LzRbv6puZnBCP6Hr9GudkJc3j/bzXE9iolbHYnG8dtnT0Ni5QmSExwIYhNxakix7SG sY7hPBJT9EP5Upui3ID98lc9m3EbJD750REsoFBw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340904816; i=@elandsys.com; bh=ForMWQPdoZATDu0R0UnJxHp7hOfFjb/5M4MXVUI+zE4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=t8OtqoK9kJTHopTtjrk27fp1ui30BudKPCELjS72bKCFbAeDnXVQJxLOyFF6wVHNX t7MU9CUFNkRoEtNnFArZIvNC0Uaxf43EWE3kVU3OJZF90sx/bnbk2fzwGt0oKBkILO AB42vqD0KdTrOb+2z8LRhsLlyYYJhNDy6lC2cLZo= Message-Id: <6.2.5.6.2.20120628094142.0a649fd8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Jun 2012 10:18:03 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <121909424.1Q2iX6uX2m@scott-latitude-e6320> References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <121909424.1Q2iX6uX2m@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 17:33:41 -0000 Hi Scott, At 09:32 28-06-2012, Scott Kitterman wrote: >I've been working through the nits page for the latest draft. I'm trying to >address all the reference and ABNF nits (added a section on imported >definitions. These are all fixed. Thanks. >Nits also whines about possible downref to US-ASCII. Can I assume that >complaint is safe to ignore? Yes, the US-ACII reference is correct. >I think 3696 is informational. I looked at some other related RFCs. The RFC 3696 is not an IETF RFC. >current DKIM RFC points at 5321 for domain name and it says: > >Domain = sub-domain *("." sub-domain) >sub-domain = Let-dig [Ldh-str] Some specifications use that. >Given that the underlying email protocol we're building on doesn't specify >special treatment for TLD naming, I think that the reference to 3696 is a >helpful hint for implementors that may want to get local efficiencies. >Reference to it isn't essential for interoperability. Appendix A is normative. RFC 4408 has the following for the TLD: toplabel = ( *alphanum ALPHA *alphanum ) / ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ; LDH rule plus additional TLD restrictions ; (see [RFC3696], Section 2) The implementation of the the specification has to parse "toplabel" for syntax with the above and the additional TLD restrictions. Regards, S. Moonesamy From spf2@kitterman.com Thu Jun 28 11:11:24 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 BC73321F850D for ; Thu, 28 Jun 2012 11:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYUgwWIubIzl for ; Thu, 28 Jun 2012 11:11:19 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4665121F85AA for ; Thu, 28 Jun 2012 11:11:19 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9AFAD20E40FC; Thu, 28 Jun 2012 14:11:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340907078; bh=BTRdNko1SsoAQflvJPhMOIogIEZvchQUII9TiRQVwFw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=aFrBbSW4BYrMsh5MCyvGmfxf4uGtiyQMP7hUrEdDuDpTKlzqadb4XTI8hN4Y4Vda5 w4wRAH2TtYxomlLhTLPe9EqCXkKDEuHor9a47jFXEe5bEfJdo7gkV8FINnMoWYlS2c YIIvvvseUxNNeevjvjkpukVkBTvpBKps++lFlGaI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8060E20E403E; Thu, 28 Jun 2012 14:11:18 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 28 Jun 2012 14:11:17 -0400 Message-ID: <1572146.ZK696AIlyj@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120628094142.0a649fd8@resistor.net> References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <121909424.1Q2iX6uX2m@scott-latitude-e6320> <6.2.5.6.2.20120628094142.0a649fd8@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] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 18:11:24 -0000 On Thursday, June 28, 2012 10:18:03 AM S Moonesamy wrote: > Hi Scott, > > At 09:32 28-06-2012, Scott Kitterman wrote: > >I've been working through the nits page for the latest draft. I'm trying > >to address all the reference and ABNF nits (added a section on imported > >definitions. These are all fixed. > > Thanks. > > >Nits also whines about possible downref to US-ASCII. Can I assume that > >complaint is safe to ignore? > > Yes, the US-ACII reference is correct. > > >I think 3696 is informational. I looked at some other related RFCs. The > > RFC 3696 is not an IETF RFC. > > >current DKIM RFC points at 5321 for domain name and it says: > > > >Domain = sub-domain *("." sub-domain) > >sub-domain = Let-dig [Ldh-str] > > Some specifications use that. > > >Given that the underlying email protocol we're building on doesn't specify > >special treatment for TLD naming, I think that the reference to 3696 is a > >helpful hint for implementors that may want to get local efficiencies. > >Reference to it isn't essential for interoperability. > > Appendix A is normative. RFC 4408 has the following for the TLD: > > toplabel = ( *alphanum ALPHA *alphanum ) / > ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) > ; LDH rule plus additional TLD restrictions > ; (see [RFC3696], Section 2) > > The implementation of the the specification has to parse "toplabel" > for syntax with the above and the additional TLD restrictions. The operative bit of Section 2 is: The LDH rule, as updated, provides that the labels (words or strings separated by periods) that make up a domain name must consist of only the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen. No other symbols or punctuation characters are permitted, nor is blank space. If the hyphen is used, it is not permitted to appear at either the beginning or end of a label. There is an additional rule that essentially requires that top-level domain names not be all- numeric. Which is, If I read it correctly, what the toplabel ABNF definition already tells you. RFC3696 has additional information and context for the definition, but it's not required for implementation. The current text may be a bit confusing because it could be read to mean consult 3696 for additional restrictions, but the additional restrictions are already in the ABNF. Perhaps it would be clearer if we changed the comment to: ; LDH rule plus additional TLD restrictions ; (see [RFC3696], Section 2 for background ; information) Is there some information in 3696 that isn't in 4408 that an implementer needs? Scott K From spf2@kitterman.com Thu Jun 28 11:14:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903B521F85AA for ; Thu, 28 Jun 2012 11:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSzpzSi7250N for ; Thu, 28 Jun 2012 11:14:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1117621F8582 for ; Thu, 28 Jun 2012 11:14:51 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9C04020E40FC; Thu, 28 Jun 2012 14:14:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340907290; bh=plun55ZYYsx+YQ2wRIsvlZrUHX7WIdZscGB84s2ppp4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=pe8boVi6tu/KJ6Sr+z7Va/7QplDC3cxiY83MvNchpen/X6+reCV8xPucIEOf3dWgH VhAHUJtl/NfLBPw1AAR/2vgvf/9MWkvXiv0mZdYuc2daqcpTbbCrIJSTtm13nEA34H PnnyIhCpil8aQfZEcHsFY9HwE1TvR9ZxRVJhnEm8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7D23720E403E; Thu, 28 Jun 2012 14:14:50 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 28 Jun 2012 14:14:50 -0400 Message-ID: <3575560.235YcPF08O@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FEC89DD.9080203@Commerco.Net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <31935435.16CnW35jdf@scott-latitude-e6320> <4FEC89DD.9080203@Commerco.Net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 18:14:58 -0000 On Thursday, June 28, 2012 10:44:13 AM Commerco WebMaster wrote: > + the message is received, but accept on a later attempt > + as defined by the receiver. Done, slightly differently as: with a note the first time the message is received, but accept it on a later attempt based on receiver policy. Scott K From superuser@gmail.com Thu Jun 28 11:19:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ACE21F85D0 for ; Thu, 28 Jun 2012 11:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yu5ghyBun98k for ; Thu, 28 Jun 2012 11:19:46 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F95821F85CE for ; Thu, 28 Jun 2012 11:19:45 -0700 (PDT) Received: by bkty8 with SMTP id y8so2504963bkt.31 for ; Thu, 28 Jun 2012 11:19:45 -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=i99mp7J4Sf3qnr5J/Xjg8qLgP97BKsQk4UmZnzw9/Bg=; b=tjCRevaCSAskpmqX/SiUgUakQNuWmbL12oofobCUVB0ZaSC4458eMfcms1/xxx38zb XhaF/5STNy8NSP4l1dxQKq8uraAwy2Z/7MGumrldMH1ECDBYJAW/YQzZMET36/TwitD3 lS/uveWGDv5RHqXLhL//m6WlsQZ3ce0vavMJ/rua6jAsGMO/60HZgHc/6wY37HRIkoub wgWk88Mj/+2+Ckac75KRSv84DsPFUO/mLVcMXgXmmsMYfyd6Ajj+Bs5+TO3KDe/7KOvp czUEPu9OToBVzV19zoDeLDVaLtR2/crPiy+1U8B+OIKr5+HhQap18HS5mViVOUL8ytrc ay3A== MIME-Version: 1.0 Received: by 10.152.147.33 with SMTP id th1mr3331134lab.9.1340907584952; Thu, 28 Jun 2012 11:19:44 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 28 Jun 2012 11:19:44 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120628094142.0a649fd8@resistor.net> References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <121909424.1Q2iX6uX2m@scott-latitude-e6320> <6.2.5.6.2.20120628094142.0a649fd8@resistor.net> Date: Thu, 28 Jun 2012 11:19:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=e89a8f22c41147186804c38c6057 Cc: spfbis@ietf.org Subject: Re: [spfbis] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 18:19:47 -0000 --e89a8f22c41147186804c38c6057 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 28, 2012 at 10:18 AM, S Moonesamy wrote: > > I think 3696 is informational. I looked at some other related RFCs. The >> > > > RFC 3696 is not an IETF RFC. Sorry; can you elaborate? I don't know what "not an IETF RFC" means. > > current DKIM RFC points at 5321 for domain name and it says: >> >> Domain = sub-domain *("." sub-domain) >> sub-domain = Let-dig [Ldh-str] >> > > Some specifications use that. I think we'd be quite safe re-using that, and keeping it simple. -MSK --e89a8f22c41147186804c38c6057 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 28, 2012 at 10:18 AM, S Moonesamy <sm+ietf@elandsys.com= > wrote:

I think 3696 is informational. =A0I looked at some other related RFCs. =A0T= he


RFC 3696 is not an IETF RFC.

Sorry; can you elaborate?= =A0 I don't know what "not an IETF RFC" means.
=A0

current DKIM RFC points at 5321 for domain name and it says:

Domain =A0 =A0 =A0 =A0 =3D sub-domain *("." sub-domain)
sub-domain =A0 =A0 =3D Let-dig [Ldh-str]

Some specifications use that.

I think we'd be quit= e safe re-using that, and keeping it simple.

-MSK
--e89a8f22c41147186804c38c6057-- From barryleiba.mailing.lists@gmail.com Thu Jun 28 11:23:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D24C21F85FD for ; Thu, 28 Jun 2012 11:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dBtHHOSYLHW for ; Thu, 28 Jun 2012 11:23:43 -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 1FBAE21F85D8 for ; Thu, 28 Jun 2012 11:23:40 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3741173lbb.31 for ; Thu, 28 Jun 2012 11:23:40 -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 :content-transfer-encoding; bh=88qDtRquky57/DMoku6cTzDVB/K5lLOUJXjk5V2iUOA=; b=c2oJFD+Xp9trEACdP/l5Vb1SxwM+IrGB63SgWn8ww1cyyT6idv7OTEl67g0sI+0HK2 chcuw1Hj5kW/hFncrL40ugMd2BvP5hl02/iAz6H2zBXHHx1z6TKqFY2X1Uf3cP+gEspJ Z2BPvxNxBfm+WID5rb1zjxsHcMs4GHXbsjHafwC0pxmU+dHpbuIhLXgsXm2P2ahUHQ38 ahPCa/lgV1ENSBKjonJ+dNn9r1ybTWozUjAo5LiqjHsAWz6H4IM+MlBiipOvzug/W2nG UXvl8T4KpKGGGu4qQnl6ngnj0izhLd2EBrFETC11eUsbXOg4CLWKvZEm2vUiwZZw2rJE Bliw== MIME-Version: 1.0 Received: by 10.112.42.164 with SMTP id p4mr1615073lbl.54.1340907820025; Thu, 28 Jun 2012 11:23:40 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Thu, 28 Jun 2012 11:23:39 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <121909424.1Q2iX6uX2m@scott-latitude-e6320> <6.2.5.6.2.20120628094142.0a649fd8@resistor.net> Date: Thu, 28 Jun 2012 14:23:39 -0400 X-Google-Sender-Auth: ZdfzzJswmrKRa-sPQlL4RNbyDoA Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, S Moonesamy Subject: Re: [spfbis] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 18:23:44 -0000 >> RFC 3696 is not an IETF RFC. > > Sorry; can you elaborate?=A0 I don't know what "not an IETF RFC" means. He means that it's not published in the IETF Stream (today it's marked as in the Independent Stream, which didn't exist at the time). Barry From superuser@gmail.com Thu Jun 28 11:26: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 D295B21F8615 for ; Thu, 28 Jun 2012 11:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdzJf9Tecu9H for ; Thu, 28 Jun 2012 11:26:36 -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 AD72A21F860E for ; Thu, 28 Jun 2012 11:26:35 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3744712lbb.31 for ; Thu, 28 Jun 2012 11:26:34 -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=+kcdxvV8T9DO0lz3GJTknvXcuTlP6xANA104ffnisZQ=; b=DA1Im9EHvwGdzGMzzPha/EBHGvA487OLjzFBiCPqguv2D9514/Yw9CikVyg3cdla+u 4g0oV9tMeKFFQzaDna3255KetHwWwWAkMkqzN56UzDjEssAIweuuXCmDPG6P86J9UuUw 78r7ZTEOYT8fTmfc2KUs51GQ3W+sUTq16VMEwSYCYsUuZBMRuqfC7nQmP69QcVpdBM+W hOo75RqCmwOlHEIwlbg7/mH6Pe7+1s8/Ut2swCaUrY0rLRRdcepsCiYDI0Q0dJsUB0wx BU2QPJTe55BbYD2EDTTUVy7bqeuWq3fPMhb3LYgy1ooZKDtoGSFOxFvZBfcwFWTJM2PA enmQ== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr1635783lbn.10.1340907994444; Thu, 28 Jun 2012 11:26:34 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 28 Jun 2012 11:26:34 -0700 (PDT) In-Reply-To: <4FEC89DD.9080203@Commerco.Net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <4FEBDEC7.6040507@Commerco.Net> <31935435.16CnW35jdf@scott-latitude-e6320> <4FEC89DD.9080203@Commerco.Net> Date: Thu, 28 Jun 2012 11:26:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: Commerco WebMaster Content-Type: multipart/alternative; boundary=bcaec554d63caf73de04c38c787f Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 18:26:37 -0000 --bcaec554d63caf73de04c38c787f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 28, 2012 at 9:44 AM, Commerco WebMaster wrote: > > > Existing greylisting implementations differ. Given that reality, I'm not > sure that one can demand the server arbitrarily accept the message the > second time it is sent. That strategy could be abused in foreseeable ways, > thus effectively defeating the purpose of greylisting. Rather I would > submit employing the logic implied in regular mail delivery: > > Attempt, fail, back off some period of time. > > Reattempt, fail, back off some larger period of time. > > Reattempt as in the prior step until either the send attempts maximum > value of the sender applies or the message is delivered. > > Perhaps this more vague wording which allows the receiver more latitude > might suffice: > + message using greylisting, [RFC6647], with a note when > + the message is received, but accept on a later attempt > + as defined by the receiver. > > RFC6647 is an Applicability Statement, which bascially means it's a consensus statement about how to achieve a particular capability based on a technical specification. In this case, it's basically "How to use SMTP to implement greylisting." That doesn't mean variations are not allowed; it's merely a consensus statement. I imagine, though, that we're drifting from RFC4408bis quite a bit here. The right place to discuss this further might be ietf-smtp or apps-discuss. -MSK --bcaec554d63caf73de04c38c787f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 28, 2012 at 9:44 AM, Commerco WebMaster <<= a href=3D"mailto:WebMaster@commerco.net" target=3D"_blank">WebMaster@commer= co.net> wrote:


Existing greylisting implementations differ. =A0Given that reality, I'm= not sure that one can demand the server arbitrarily accept the message the= second time it is sent. =A0That strategy could be abused in foreseeable wa= ys, thus effectively defeating the purpose of greylisting. =A0Rather I woul= d submit employing the logic implied in regular mail delivery:

Attempt, fail, back off some period of time.

Reattempt, fail, back off some larger period of time.

Reattempt as in the prior step until either the send attempts maximum value= of the sender applies or the message is delivered.

Perhaps this more vague wording which allows the receiver more latitude mig= ht suffice:
+ =A0 message using greylisting, [RFC6647], with a note when
+ =A0 the message is received, but accept on a later attempt
+ =A0 as defined by the receiver.


RFC6647 is an Applicability Statement, which basc= ially means it's a consensus statement about how to achieve a particula= r capability based on a technical specification.=A0 In this case, it's = basically "How to use SMTP to implement greylisting."=A0 That doe= sn't mean variations are not allowed; it's merely a consensus state= ment.

I imagine, though, that we're drifting from RFC4408bis quite a bit = here.=A0 The right place to discuss this further might be ietf-smtp or apps= -discuss.

-MSK
--bcaec554d63caf73de04c38c787f-- From superuser@gmail.com Thu Jun 28 11:29:01 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 001A821F8474 for ; Thu, 28 Jun 2012 11:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UfgA0hnq5Ux for ; Thu, 28 Jun 2012 11:29:00 -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 219F121F8472 for ; Thu, 28 Jun 2012 11:28:59 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3747730lbb.31 for ; Thu, 28 Jun 2012 11:28:59 -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=gSsIjUrQ7eGo5QJV2q0JEv0CLm5OJqDn9aZuCmi68i0=; b=pmWxqg+lSKlroimNlIexpD14NiWjwwPzzGqLy+MpQ3fGjT9mYy8DHIqTmmhpwjTuDw aOEU6TryCsrkTXyOaFN6PwbObLNbhxsDkJryVwgYlcjl7yRXlUboHQrUzBuM8LLdh2hJ s8ysxDWUqPDMxH82HGZcGI7JGexn9LyzuY+76cl9ofhl6LHEQnBCHtmMwo3M0nK0sDRd mj+ywIhY2sBlKSCAJcOKqd4AGEiKiaZdPM5XdnJ4uAqmEovV22EJYfvnHPVwOsyXW5hZ o8MT2Ad4yq5+8hFO8w0ubDvcdTZUq1InjMInAZ33+ywXLm/d0VZRoNjRwy9twm51shOD qhFg== MIME-Version: 1.0 Received: by 10.152.104.171 with SMTP id gf11mr3347467lab.5.1340908139114; Thu, 28 Jun 2012 11:28:59 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 28 Jun 2012 11:28:59 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <121909424.1Q2iX6uX2m@scott-latitude-e6320> <6.2.5.6.2.20120628094142.0a649fd8@resistor.net> Date: Thu, 28 Jun 2012 11:28:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=f46d04083de74eefc604c38c81a6 Cc: spfbis@ietf.org, S Moonesamy Subject: Re: [spfbis] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 18:29:01 -0000 --f46d04083de74eefc604c38c81a6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 28, 2012 at 11:23 AM, Barry Leiba wrote: > >> RFC 3696 is not an IETF RFC. > > > > Sorry; can you elaborate? I don't know what "not an IETF RFC" means. > > He means that it's not published in the IETF Stream (today it's marked > as in the Independent Stream, which didn't exist at the time). > > Barry > That still makes it an Informative reference, though, correct? That is, I don't see how it's an important distinction in this context. -MSK --f46d04083de74eefc604c38c81a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 28, 2012 at 11:23 AM, Barry Leiba <barryleiba@computer.o= rg> wrote:
>> RFC 3696 is not an IETF RFC.
>
> Sorry; can you elaborate?=A0 I don't know what "not an IETF R= FC" means.

He means that it's not published in the IETF Stream (today it'= ;s marked
as in the Independent Stream, which didn't exist at the time).

Barry

That still makes it an Informative ref= erence, though, correct?

That is, I don't see how it's an im= portant distinction in this context.

-MSK
--f46d04083de74eefc604c38c81a6-- From spf2@kitterman.com Thu Jun 28 11:38:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D1E21F858F for ; Thu, 28 Jun 2012 11:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPjdXRYsUTq9 for ; Thu, 28 Jun 2012 11:38:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EA66021F8585 for ; Thu, 28 Jun 2012 11:38:10 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 441D120E40FC; Thu, 28 Jun 2012 14:38:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340908690; bh=YuI4ikT6DSaFLmqYgYwQqDnqNOYUrfBJWbMQX5LMe9g=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=JzWlsSeABk7lmYeXie338BcJid2itHTLlGKeG+8/wvX6ACilsrjrSZHZNusxclY7s DfyK3SBuqA21XYweGAzFBRxkhHbJNRW5/FxcjBXJ4q8/Sr/lrbijjcmZ3ePq7TuwJ/ RAhEd1mCUeyhMuWGp/yk8uOvp/fZ20OGnXgFAVA0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 25E2020E403E; Thu, 28 Jun 2012 14:38:09 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 28 Jun 2012 14:38:09 -0400 Message-ID: <2880642.TSmuuEms4s@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <6.2.5.6.2.20120628094142.0a649fd8@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] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 18:38:12 -0000 On Thursday, June 28, 2012 11:19:44 AM Murray S. Kucherawy wrote: > On Thu, Jun 28, 2012 at 10:18 AM, S Moonesamy wrote: > > I think 3696 is informational. I looked at some other related RFCs. The > > > > > > > > RFC 3696 is not an IETF RFC. > > Sorry; can you elaborate? I don't know what "not an IETF RFC" means. > > > current DKIM RFC points at 5321 for domain name and it says: > >> Domain = sub-domain *("." sub-domain) > >> sub-domain = Let-dig [Ldh-str] > > > > Some specifications use that. > > I think we'd be quite safe re-using that, and keeping it simple. Does that change the design? Domain = sub-domain *("." sub-domain) sub-domain = Let-dig [Ldh-str] Let-dig = ALPHA / DIGIT Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig My naive reading of that (ABNF is not really my thing) is that's different than what's in RFC 4408: toplabel = ( *alphanum ALPHA *alphanum ) / ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ; LDH rule plus additional TLD restrictions ; (see [RFC3696], Section 2) alphanum = ALPHA / DIGIT I don't think we should change definitions because the definition that was used before is in an inconvenient place. Scott K From superuser@gmail.com Thu Jun 28 11:59:01 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 8A26721F853D for ; Thu, 28 Jun 2012 11:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiF3qcZqWo9a for ; Thu, 28 Jun 2012 11:59:00 -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 64DED21F851C for ; Thu, 28 Jun 2012 11:59:00 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3781734lbb.31 for ; Thu, 28 Jun 2012 11:58:59 -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=tg6AkYupu4GdkmoW0vAXUUhcJD5wp6HA+dUBfvJdOrA=; b=FdsB64VnoO0AXaaabeskH49MyWeFS/75mq8/NgTG8He9ZNWLLw2EivQH2FjksS4PcC vByIpuivUj3H9Hv+M+32GpzTgdhKe5NYhwUp+nMotMgFRt7YHy0bSBwUa74t6hOiSa1b gsvYSuqb1VnimAL58gOlkxKBwq32/WaHT1gUyGiicglZA3RFppKs49Uv/m3XfAt1k7BQ g3PvkOXmtvQ2y17t2s+GYGPgZOFF53HdRAwyUZC65trx54jZ+ux3hYKsW95RmDdtYm+m VglMSSdmF3eCFgXSYjo+lRDpu+Ny+thJ707vnjI9ElKU8iZOEYSS5w4WeUmUeaI5mG4X dlaA== MIME-Version: 1.0 Received: by 10.112.83.169 with SMTP id r9mr1626205lby.66.1340909939370; Thu, 28 Jun 2012 11:58:59 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 28 Jun 2012 11:58:59 -0700 (PDT) In-Reply-To: <2880642.TSmuuEms4s@scott-latitude-e6320> References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <6.2.5.6.2.20120628094142.0a649fd8@resistor.net> <2880642.TSmuuEms4s@scott-latitude-e6320> Date: Thu, 28 Jun 2012 11:58:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0401fc439cac0504c38cec6b Cc: spfbis@ietf.org Subject: Re: [spfbis] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 18:59:01 -0000 --f46d0401fc439cac0504c38cec6b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 28, 2012 at 11:38 AM, Scott Kitterman wrote: > On Thursday, June 28, 2012 11:19:44 AM Murray S. Kucherawy wrote: > > On Thu, Jun 28, 2012 at 10:18 AM, S Moonesamy > wrote: > > > I think 3696 is informational. I looked at some other related RFCs. > The > > > > > > RFC 3696 is not an IETF RFC. > > > > Sorry; can you elaborate? I don't know what "not an IETF RFC" means. > > > > > current DKIM RFC points at 5321 for domain name and it says: > > >> Domain = sub-domain *("." sub-domain) > > >> sub-domain = Let-dig [Ldh-str] > > > > > > Some specifications use that. > > > > I think we'd be quite safe re-using that, and keeping it simple. > > Does that change the design? > > Domain = sub-domain *("." sub-domain) > sub-domain = Let-dig [Ldh-str] > Let-dig = ALPHA / DIGIT > Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig > > My naive reading of that (ABNF is not really my thing) is that's different > than > what's in RFC 4408: > > toplabel = ( *alphanum ALPHA *alphanum ) / > ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) > ; LDH rule plus additional TLD restrictions > ; (see [RFC3696], Section 2) > alphanum = ALPHA / DIGIT > > I don't think we should change definitions because the definition that was > used > before is in an inconvenient place. > > Since the latter is in RFC4408, I'm not clear on what you mean by "inconvenient place". It's certainly simple enough to make reference to external ABNFs. What I don't understand is the need for the complexity of what's in RFC4408. -MSK --f46d0401fc439cac0504c38cec6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 28, 2012 at 11:38 AM, Scott Kitterman <spf2@kitterman.com= > wrote:
On Thursday, June 28, 2012 11:19:44= AM Murray S. Kucherawy wrote:
> On Thu, Jun 28, 2012 at 10:18 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:
> > I think 3696 is informational. =A0I looked at some other related = RFCs. =A0The
> >
> > RFC 3696 is not an IETF RFC.
>
> Sorry; can you elaborate? =A0I don't know what "not an IETF R= FC" means.
>
> > =A0current DKIM RFC points at 5321 for domain name and it says: > >> Domain =A0 =A0 =A0 =A0 =3D sub-domain *("." sub-dom= ain)
> >> sub-domain =A0 =A0 =3D Let-dig [Ldh-str]
> >
> > Some specifications use that.
>
> I think we'd be quite safe re-using that, and keeping it simple.
Does that change the design?

Domain =A0 =A0 =A0 =A0 =3D sub-domain *("." sub-domain)
sub-domain =A0 =A0 =3D Let-dig [Ldh-str]
Let-dig =A0 =A0 =A0 =A0=3D ALPHA / DIGIT
Ldh-str =A0 =A0 =A0 =A0=3D *( ALPHA / DIGIT / "-" ) Let-dig

My naive reading of that (ABNF is not really my thing) is that's differ= ent than
what's in RFC 4408:

toplabel =A0 =A0 =A0 =A0 =3D ( *alphanum ALPHA *alphanum ) /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0( 1*alphanum "-" *( a= lphanum / "-" ) alphanum )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0; LDH rule plus additional TLD = restrictions
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0; (see [RFC3696], Section 2)
alphanum =A0 =A0 =A0 =A0 =3D ALPHA / DIGIT

I don't think we should change definitions because the definition that = was used
before is in an inconvenient place.

=A0
Since the latter is in RFC4408, I'm not cl= ear on what you mean by "inconvenient place".=A0 It's certain= ly simple enough to make reference to external ABNFs.

What I don'= ;t understand is the need for the complexity of what's in RFC4408.

-MSK
--f46d0401fc439cac0504c38cec6b-- From spf2@kitterman.com Thu Jun 28 12:08:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B5521F85D2 for ; Thu, 28 Jun 2012 12:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY9guUhdmkVr for ; Thu, 28 Jun 2012 12:08:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD3821F85A0 for ; Thu, 28 Jun 2012 12:08:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BB44220E40FC; Thu, 28 Jun 2012 15:08:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340910494; bh=NijN1diFxr2SOtzc5oOZXGxd93eF1aiTw+H6bjziSqI=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=fPz6PeHXMbqxwDxjw4d+cbkc1/zzVSl+nakRAvcn4J+ZEkdYWDfRnoyeomPSVh/S6 q+2zitfNPptCONR8xJA3beMMaE20b97x9dinarQU9GVMTY8IrgmHXeyS+csNoZbm+/ Qs/AacH+5/4iqg9p5MWt1iBFT1HDQSXjk6Jiv+nQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9DEF620E403E; Thu, 28 Jun 2012 15:08:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 28 Jun 2012 15:08:14 -0400 Message-ID: <12311249.DGmbNY97JX@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <2880642.TSmuuEms4s@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] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 19:08:16 -0000 On Thursday, June 28, 2012 11:58:59 AM Murray S. Kucherawy wrote: > On Thu, Jun 28, 2012 at 11:38 AM, Scott Kitterman wrote: > > On Thursday, June 28, 2012 11:19:44 AM Murray S. Kucherawy wrote: > > > On Thu, Jun 28, 2012 at 10:18 AM, S Moonesamy > > > > wrote: > > > > I think 3696 is informational. I looked at some other related RFCs. > > > > The > > > > > > RFC 3696 is not an IETF RFC. > > > > > > Sorry; can you elaborate? I don't know what "not an IETF RFC" means. > > > > > > > current DKIM RFC points at 5321 for domain name and it says: > > > >> Domain = sub-domain *("." sub-domain) > > > >> sub-domain = Let-dig [Ldh-str] > > > > > > > > Some specifications use that. > > > > > > I think we'd be quite safe re-using that, and keeping it simple. > > > > Does that change the design? > > > > Domain = sub-domain *("." sub-domain) > > sub-domain = Let-dig [Ldh-str] > > Let-dig = ALPHA / DIGIT > > Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig > > > > My naive reading of that (ABNF is not really my thing) is that's different > > than > > what's in RFC 4408: > > > > toplabel = ( *alphanum ALPHA *alphanum ) / > > > > ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) > > ; LDH rule plus additional TLD restrictions > > ; (see [RFC3696], Section 2) > > > > alphanum = ALPHA / DIGIT > > > > I don't think we should change definitions because the definition that was > > used > > before is in an inconvenient place. > > Since the latter is in RFC4408, I'm not clear on what you mean by > "inconvenient place". It's certainly simple enough to make reference to > external ABNFs. That was a reference to the discussion about if we could reference 3696. > What I don't understand is the need for the complexity of what's in RFC4408. I don't recall precisely, but I believe it was intended to exclude address literals. In retrospect we probably could have not worried about it and combined ip4/ip6/a into a single mechanism, but that's not the design we've got. I'm not aware of the current ABNF causing any problems, so I think it ought to stay as it is. Scott K From sm@elandsys.com Thu Jun 28 13:31:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175EF11E80BB for ; Thu, 28 Jun 2012 13:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDq3QhuVasPP for ; Thu, 28 Jun 2012 13:31:22 -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 2C41E21F84EE for ; Thu, 28 Jun 2012 13:31:22 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.142]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5SKUvo7029632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 13:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340915480; bh=S188Xd0axZjVstFnr+SShX0HAlLejzF1LWO155HQkgM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=l9M6wk8k3LP7i9IVSB+B1wIXgkqg7DSaL/W9nkRNdnpBZlcwsSiUV81AiN0HVOuWH XdKnMvesy3D4eIKdXl9Rkk6+ZS+CLw8uQNSK+tCVjFrjoF3aucrJ3wejl7eGygTVhX RIsRomg35Xw1sQLK89oLljhzRVIdcKb1R/hhOxhY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340915480; i=@elandsys.com; bh=S188Xd0axZjVstFnr+SShX0HAlLejzF1LWO155HQkgM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cKmyoEXArfsCIS1qhVy9oJw9lckpW5qP+lRwJ0Me2eYUMAxOVfdrmUnjcsXt71PBO MiVaKZskVJcO5Yu72jc6Kkv904pCypt6RAOzBDyS2sPjdXBuB4wTTsggCR2yfmkcJj kzcgdQX883xK7QC7jfvMSe8q7v8gKnkrE4LGtrkM= Message-Id: <6.2.5.6.2.20120628122825.0a710fa8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Jun 2012 13:13:06 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <1572146.ZK696AIlyj@scott-latitude-e6320> References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <121909424.1Q2iX6uX2m@scott-latitude-e6320> <6.2.5.6.2.20120628094142.0a649fd8@resistor.net> <1572146.ZK696AIlyj@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 20:31:27 -0000 Hi Scott, At 11:11 28-06-2012, Scott Kitterman wrote: >The operative bit of Section 2 is: > > The LDH rule, as updated, provides that the labels (words or strings > separated by periods) that make up a domain name must consist of only > the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen. > No other symbols or punctuation characters are permitted, nor is > blank space. If the hyphen is used, it is not permitted to appear at > either the beginning or end of a label. There is an additional rule > that essentially requires that top-level domain names not be all- > numeric. > >Which is, If I read it correctly, what the toplabel ABNF definition already >tells you. RFC3696 has additional information and context for the >definition, Now I see what you mean. You are referring to that section for the LDH rule and the additional rule. In general that's RFC 952 with the RFC 1123 update. Murray Kucherawy commented on using the ABNF from RFC 5321. That's another way to tackle the issue. >but it's not required for implementation. The current text may be a bit >confusing because it could be read to mean consult 3696 for additional >restrictions, but the additional restrictions are already in the ABNF. >Perhaps it would be clearer if we changed the comment to: > > ; LDH rule plus additional TLD restrictions > ; (see [RFC3696], Section 2 for background > ; information) > >Is there some information in 3696 that isn't in 4408 that an implementer >needs? That is a question for working group participants to address. You turned the RFC 3696 reference into an informative one. :-) The ABNF mentions "LDH rule plus additional TLD restrictions". An "external" reviewer would ask where to find the additional TLD restrictions. We would also be changing the ABNF. Given that the ABNF is normative in this draft I consider such a change as substantive. I would like to get more input on this from other WG participants. Regards, S. Moonesamy SPFBIS WG co-chair From sm@elandsys.com Thu Jun 28 13:31:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732B721F84EE for ; Thu, 28 Jun 2012 13:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JI7RtY9QR7p for ; Thu, 28 Jun 2012 13:31:23 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 099AB11E80A2 for ; Thu, 28 Jun 2012 13:31:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.142]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5SKUvo5029632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 13:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340915476; bh=5HoMWm2/O+1MVedmhoa+iQyQasg0yOyT7pNlEM38CAc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=f2f8QDCGd8LKBPvqY9LStc2922n2Y0Q32trkmZQWU46F4Mf/y5zvvZw4GUcWZP80f sWQZ9DGSXxYEpIoHOOio6zskCtV2a84sq4HgWOaZ0ASGaT6sHpcoUpsVADYB53wrbk ypmkpGTU9brUlLNUKfCA8jZ6syGae6mzFbVdojco= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340915476; i=@elandsys.com; bh=5HoMWm2/O+1MVedmhoa+iQyQasg0yOyT7pNlEM38CAc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=B97XIvHvBw3FxzrJDHq3w+LA/tjyTZfIgfePmWU7IyGpHF7GOxHevZKPU/2jPkjY4 8s61EHtZF85tIgxN9Z+84oaZe3GVP7zdC+60cf0pn+Eysbt7+WFmgFqIZ7bBgcHa+o NROVJ8bjd/DiJjfoK6fCvFyRxvEz5eBMqsrEMADQ= Message-Id: <6.2.5.6.2.20120628113529.0a64ecb8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Jun 2012 12:26:06 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <121909424.1Q2iX6uX2m@scott-latitude-e6320> <6.2.5.6.2.20120628094142.0a649fd8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 20:31:27 -0000 Hi Murray, At 11:28 28-06-2012, Murray S. Kucherawy wrote: >That still makes it an Informative reference, though, correct? The RFC can be used as a reference. According to my reading of the draft it would have to be normative. >That is, I don't see how it's an important distinction in this context. I am looking at this as a specification which explains what is expected of the syntax parser. I'll elaborate with an example. Let's say that X is a "string" which is a valid domain name. We all know what a domain name is. If we write code, we have to figure out what is actually a domain name. Is there any limit on the number of octets for the "string"? Is there any octet limit for (DNS) labels? What about LDH? If there is a normative reference to RFC 1035, we look at that specification to find the answers. That RFC does not provide all the details about "TLD restrictions". Now we have to go and find a specification to derive the "rules" for that. Which specification can we use? Would the IETF consider the reference as a good one? I cannot say: "this is a RFC; it is good enough". Did I do any research to see whether there is a RFC published in the IETF Stream which is considered as authoritative on that subject? This is where AD tells me that I wasn't diligent in reviewing the work before requesting the AD review. This is also about "did you think about it" so that you don't have to be the deer in the headlights when the issue is raised. Regards, S. Moonesamy From sm@elandsys.com Thu Jun 28 13:32:50 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 A0E2321F8513 for ; Thu, 28 Jun 2012 13:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vrRx3GUMLTM for ; Thu, 28 Jun 2012 13:32:46 -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 4B63721F850D for ; Thu, 28 Jun 2012 13:32:46 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.142]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5SKUvoB029632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 13:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340915488; bh=A0aaXS0DVIwu6oe1msfFCiC9Ddp+oN/n3Oibycm5hZQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FkE11Nfb+F0/U7Yw7Wr9C3UqkQmckzFEBNxCMkg6Gv9l+Jyndevxaszk3py9HD7wk m4nw4Vh1nF/5mkJaAuzaUiXdXyduLxQTYj6ISPDqURH+prHOE+QEHHs/JaSzPazXWm rB0VGd/qddbWg+NMwT/JugFNwsuqz03p8s5IZSPk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340915488; i=@elandsys.com; bh=A0aaXS0DVIwu6oe1msfFCiC9Ddp+oN/n3Oibycm5hZQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BjSnqSlHnnrpkozVC3XWP+8c15KODWax4VuL9il000YsobwgbmguDVCy0JOm+UwZ6 Byap/igxKRWXTDve9qjbFBtezq/bbZmVmR7PaDDB4xblF11lGlK7oepDlBnQqaoAfF wXpEhfxrsqs2b/1adAvyXG7DkuIK2HlqeUeXXZKo= Message-Id: <6.2.5.6.2.20120628132227.0ce4a398@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Jun 2012 13:28:37 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120628200220.21961.43683.idtracker@ietfa.amsl.com> References: <20120628200220.21961.43683.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] spfbis - Requested session has been scheduled for IETF 84 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 20:32:50 -0000 Hello, The WG session at IETF 84 is scheduled as follows: spfbis Session 1 (0:30:00) Tuesday, Afternoon Session III 1700-1830 Room Name: Georgia A Please note that the WG Chairs would prefer not to have a session unless there are substantive issues which require face-to-face discussion. I don't see any issue which qualify for that at the moment. Regards, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Thu Jun 28 13:49:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17C221F852D for ; Thu, 28 Jun 2012 13:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxbBwG9sy-W9 for ; Thu, 28 Jun 2012 13:49:16 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E9C9621F8526 for ; Thu, 28 Jun 2012 13:49:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2BB8A20E40FC; Thu, 28 Jun 2012 16:49:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340916555; bh=X/XOqdgT5SoYco2ttwle/CUrmp3W1XNmpDk5mQIF19g=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=pQbZvIOipnEdlKU/JjW0soqNXNX5c2zD16X8IgZczQIiiFhYUAximLt8ud2Ik0nuV 2aHvcgzjxIHqTuMf25t08Q4eWrT7kBq8ff8YM8i68u1VWAOjINnXaHie/nCRupv4DI jVv93xxE1Z9C1w+4r2yxpObMssSbRe6S9LvG1sIg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0A6B720E403E; Thu, 28 Jun 2012 16:49:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 28 Jun 2012 16:49:14 -0400 Message-ID: <6747592.4CmXrOD8P9@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120628105417.0a64dfe8@resistor.net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1404637.xT9T34QnEg@scott-latitude-e6320> <6.2.5.6.2.20120628105417.0a64dfe8@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 20:49:17 -0000 On Thursday, June 28, 2012 11:27:11 AM S Moonesamy wrote: > Hi Scott, > > At 09:48 28-06-2012, Scott Kitterman wrote: > >Keep in mind this is an example. It's totally non-normative. I'm fine > >either way, but I don't think it merits a lot of discussion. > > The text is part of the specification. If it was raised as an issue > after ample discussion, we might be able to get away by saying that > it is non-normative. There hasn't be much discussion. There can be > a DISCUSS on this and it will block publication of the document. > > The current level of review is quite low. A document editor also has > to identify the issues and propose a resolution. If there isn't > ample discussion we end up with text which doesn't really address the > issues. The issue raised was using 451 instead of 450. I resolved that by referring to RFC6647 instead of specifying it. so I believe that issue is resolved locally and will be in -02spfb. Scott K From spf2@kitterman.com Thu Jun 28 13:52:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A7D11E80A4 for ; Thu, 28 Jun 2012 13:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-upUV-XT8th for ; Thu, 28 Jun 2012 13:52:07 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7266C11E808F for ; Thu, 28 Jun 2012 13:52:07 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 04A7320E40FC; Thu, 28 Jun 2012 16:52:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340916727; bh=Ky141TTii5j4vwffcTQssNwmjmuICFi7IIopEmsgYpY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=nIjXb84tGuvqFUZwwpyRDnEpk031Uz4SQDXv/Y+CpKy46Lw7ocil4Be22z+UxnQol V8k36oRr3cDAtYU5yYvDxd1dNSpItxjN3SDBkscmI3hD+JxDryIU14wBC/DaH3JrpF NN6Uajb9RoYhU0AgZOjjibta4TSCkJtOfxlcLJ8Q= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DB02520E403E; Thu, 28 Jun 2012 16:52:06 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 28 Jun 2012 16:52:06 -0400 Message-ID: <2004729.3kEZ6yBfcV@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120628122825.0a710fa8@resistor.net> References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <1572146.ZK696AIlyj@scott-latitude-e6320> <6.2.5.6.2.20120628122825.0a710fa8@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] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 28 Jun 2012 20:52:10 -0000 On Thursday, June 28, 2012 01:13:06 PM S Moonesamy wrote: > Hi Scott, > > At 11:11 28-06-2012, Scott Kitterman wrote: > >The operative bit of Section 2 is: > > The LDH rule, as updated, provides that the labels (words or strings > > separated by periods) that make up a domain name must consist of only > > the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen. > > No other symbols or punctuation characters are permitted, nor is > > blank space. If the hyphen is used, it is not permitted to appear at > > either the beginning or end of a label. There is an additional rule > > that essentially requires that top-level domain names not be all- > > numeric. > > > >Which is, If I read it correctly, what the toplabel ABNF definition already > >tells you. RFC3696 has additional information and context for the > >definition, > > Now I see what you mean. You are referring to that section for the > LDH rule and the additional rule. In general that's RFC 952 with the > RFC 1123 update. Murray Kucherawy commented on using the ABNF from > RFC 5321. That's another way to tackle the issue. > > >but it's not required for implementation. The current text may be a bit > >confusing because it could be read to mean consult 3696 for additional > >restrictions, but the additional restrictions are already in the ABNF. > > > >Perhaps it would be clearer if we changed the comment to: > > ; LDH rule plus additional TLD restrictions > > ; (see [RFC3696], Section 2 for background > > ; information) > > > >Is there some information in 3696 that isn't in 4408 that an implementer > >needs? > > That is a question for working group participants to address. > > You turned the RFC 3696 reference into an informative one. :-) The > ABNF mentions "LDH rule plus additional TLD restrictions". An > "external" reviewer would ask where to find the additional TLD restrictions. > > We would also be changing the ABNF. Given that the ABNF is normative > in this draft I consider such a change as substantive. I would like > to get more input on this from other WG participants. No. I didn't. It's already an informative one. All I'm saying is that 4408 is correct and there's no reference deficiency to correct. If we need to clarify the comment to make that more clear, I don't think that actually changes anything. Scott K From sm@elandsys.com Thu Jun 28 16:25:14 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 7DF4211E809B for ; Thu, 28 Jun 2012 16:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbWl15+dk6sR for ; Thu, 28 Jun 2012 16:25:10 -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 484F311E8088 for ; Thu, 28 Jun 2012 16:25:10 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.175]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5SNOs0R005758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 16:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340925908; bh=JPplhi53EV/UPsb5SIgDymsWjUf8RESUGLHFLTNQq4I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SaU4NdgMoyLaO8+uJZI3DtZIj6JgEehupgSjQoIphWZXxYrxlqxa9FijN6FGy9oX4 tVM5QeJaQl4ty06luFTV1shKDUm18BYnLHK8dXNdsY7dFKGPto3s1aC+9KqnIjoAN6 bKMBfo9tg0UgHdlgd7du2692EBEoapAJVO8lPRDQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340925908; i=@elandsys.com; bh=JPplhi53EV/UPsb5SIgDymsWjUf8RESUGLHFLTNQq4I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Xz/8f3JulECoabjJFSr7D6Whv0dveSiUFPN/Ehs3Gk9Wmq638wsMkb3YB/kXbb+D6 PeW2mhKG5yRiIXPvKRm2NJch89fietHT0IvypiFWjYvQw92PBDwur/OTphRHHErBIQ LNXu3MCBr8tvI1ybvSBETc3RTR7Zjat+aL7zotoQ= Message-Id: <6.2.5.6.2.20120628161803.063558c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 28 Jun 2012 16:23:02 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <6747592.4CmXrOD8P9@scott-latitude-e6320> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <1404637.xT9T34QnEg@scott-latitude-e6320> <6.2.5.6.2.20120628105417.0a64dfe8@resistor.net> <6747592.4CmXrOD8P9@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 23:25:14 -0000 Hi Scott, At 13:49 28-06-2012, Scott Kitterman wrote: >The issue raised was using 451 instead of 450. I resolved that by referring >to RFC6647 instead of specifying it. so I believe that issue is resolved >locally and will be in -02spfb. Could you please post the text changes you plan to make for the issue mentioned above? The message at http://www.ietf.org/mail-archive/web/spfbis/current/msg01667.html has a diff for Section 2.5.5 only. Regards, S. Moonesamy From spf2@kitterman.com Thu Jun 28 20:26:21 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 EFB1D11E812C for ; Thu, 28 Jun 2012 20:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fXGxgZ9LPMP for ; Thu, 28 Jun 2012 20:26:20 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DCF7E11E811C for ; Thu, 28 Jun 2012 20:26:19 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DD5FC20E40FC; Thu, 28 Jun 2012 23:26:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340940378; bh=ijZ+7yZ/AqkfYG3RU0FetLsNpqOOxfghHmTq1ky0vyc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Epc45j7cDJJpBH/dfD9Vg5gGKscXM2RUKn9aLsK7T7Li/9U6KYO30/Fv5jrbrdufF DCx+OE0f7USqVkAoirrCS1vSDMt9fzIQTYb+EM2BtOu3td3hnYK+Nd1rFUXZSV3dFc AnpQWNGD/E2UxjZIJz7E1x0htRojV9/yhOe2HbIU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C2EC020E403E; Thu, 28 Jun 2012 23:26:18 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 28 Jun 2012 23:26:18 -0400 Message-ID: <7180122.qjqJa4HyJa@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120628161803.063558c0@resistor.net> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <6747592.4CmXrOD8P9@scott-latitude-e6320> <6.2.5.6.2.20120628161803.063558c0@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 03:26:21 -0000 On Thursday, June 28, 2012 04:23:02 PM S Moonesamy wrote: > Hi Scott, > > At 13:49 28-06-2012, Scott Kitterman wrote: > >The issue raised was using 451 instead of 450. I resolved that by > >referring to RFC6647 instead of specifying it. so I believe that issue is > >resolved locally and will be in -02spfb. > > Could you please post the text changes you plan to make for the issue > mentioned above? The message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg01667.html has > a diff for Section 2.5.5 only. The issue was only posed in reference to 2.5.5. I have: The domain owner wants to discourage the use of this host and thus desires limited feedback when a "softfail" result occurs. For example, the recipient's Mail User Agent (MUA) could - highlight the "SoftFail" status, or the receiving MTA could give - the sender a message using a technique called "greylisting" - whereby the MTA can issue an SMTP reply code of 451 (4.3.0 DSN - code) with a note the first time the message is received, but - accept it the second time. + highlight the "softfail" status, or the receiving MTA could give + the sender a message using greylisting, , + with a note the first time the message is received, but accept it + on a later attempt based on receiver policy. Are there other places you think it should be changed? Scott K From sm@elandsys.com Fri Jun 29 00:10:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03711E80EB for ; Fri, 29 Jun 2012 00:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnAuUrEzt2n8 for ; Fri, 29 Jun 2012 00:10:56 -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 6B37111E8109 for ; Fri, 29 Jun 2012 00:10:56 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.175]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5T7AcG5021638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jun 2012 00:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340953852; bh=8UoDBZDMWqlRdETA/gq1+ZxK2mJyjMqBNe8cdX+CIl4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=bJ6/YoRD32ACVLbP8a7mA9WHNT+kai272Qe+CmbbD8eojeq1f/roVPR3bbKyGl+r5 Uz2YDR2BpUOxsUL5j/1R710/nbJTXveLcU+o1myutW2nCu4W2ZKNVLA4EhqbC9sY2g XoO0rmqN4Wnu25H8rikLBD4fb/GoK10Foxw3WB74= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340953852; i=@elandsys.com; bh=8UoDBZDMWqlRdETA/gq1+ZxK2mJyjMqBNe8cdX+CIl4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=puMILUbbFSAJDa2qT31+F+zEVlR5lqT8hr8JOzSu8+XFbc5PpoiAgdiWtbIclRTGB g5+ARNMwyJJIGEPxyaNCn10k0iEFeuovwf6rONHVZd0+5iBTD6vOirdLogCuXzx/Ra yIu3UHDvj900X5awnL/dc+KyhaXI7cv+kGRI3Mz8= Message-Id: <6.2.5.6.2.20120628232936.0635a458@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 29 Jun 2012 00:06:40 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <7180122.qjqJa4HyJa@scott-latitude-e6320> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <6747592.4CmXrOD8P9@scott-latitude-e6320> <6.2.5.6.2.20120628161803.063558c0@resistor.net> <7180122.qjqJa4HyJa@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 07:10:58 -0000 At 20:26 28-06-2012, Scott Kitterman wrote: >The issue was only posed in reference to 2.5.5. I have: > > The domain owner wants to discourage the use of this host and > thus desires limited feedback when a "softfail" result occurs. > For example, the recipient's Mail User Agent (MUA) could >- highlight the "SoftFail" status, or the receiving MTA could give >- the sender a message using a technique called "greylisting" >- whereby the MTA can issue an SMTP reply code of 451 (4.3.0 DSN >- code) with a note the first time the message is received, but >- accept it the second time. >+ highlight the "softfail" status, or the receiving MTA could give >+ the sender a message using greylisting, , >+ with a note the first time the message is received, but accept it >+ on a later attempt based on receiver policy. Thanks. >Are there other places you think it should be changed? As we are going over the SMTP reply codes and the extended status codes, here's are the occurrences in the draft: In Section 2.5.4: "If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see [RFC3463]), in addition to an appropriate reply text." For Section 2.5.5, see quoted text above. In Section 2.5.6: "If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 enhanced status code." In Section 2.5.7: "If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 550 and, if supported, the 5.5.2 enhanced status code." I suggest that the working group reviews and comments on all the occurrences. Regards, S. Moonesamy From vesely@tana.it Fri Jun 29 04:32: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 4281621F86C3 for ; Fri, 29 Jun 2012 04:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.534 X-Spam-Level: X-Spam-Status: No, score=-4.534 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7wlJKmlVolm for ; Fri, 29 Jun 2012 04:32:31 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 094A521F86B8 for ; Fri, 29 Jun 2012 04:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1340969541; bh=fwFr6fpcBL8DL/cyszYM4CLCM66oQ1WayDs9dg1Ghb0=; l=633; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=XCMV/tnugtszedPoiKYQlRJha9Bg57JKGBCJkspThRdvvDpYCsEB0fFgXRmDROkRt Xgi0yBL6BvaojBNjQ3w+eKRbFd/HnroYmA2admiX3T7iTF6ZeJcC5CrdjqSTJOi3wv pw1yGz/DL93mCb+IlJXk44jBJNC2Gx4q4EqdTvyQ= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 29 Jun 2012 13:32:21 +0200 id 00000000005DC045.000000004FED9245.00001DF2 Message-ID: <4FED9244.6000106@tana.it> Date: Fri, 29 Jun 2012 13:32:20 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <121909424.1Q2iX6uX2m@scott-latitude-e6320> <6.2.5.6.2.20120628094142.0a649fd8@resistor.net> <1572146.ZK696AIlyj@scott-latitude-e6320> <6.2.5.6.2.20120628122825.0a710fa8@resistor.net> In-Reply-To: <6.2.5.6.2.20120628122825.0a710fa8@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 11:32:32 -0000 On Thu 28/Jun/2012 22:13:06 +0200 S Moonesamy wrote: > At 11:11 28-06-2012, Scott Kitterman wrote: >> Perhaps it would be clearer if we changed the comment to: >> >> ; LDH rule plus additional TLD restrictions >> ; (see [RFC3696], Section 2 for background >> ; information) > > We would also be changing the ABNF. Given that the ABNF is normative > in this draft I consider such a change as substantive. I would like > to get more input on this from other WG participants. I'd avoid to change the ABNF unless we find errors in it. In that respect, moving a reference is less of a change than adding a comment. jm2c From spf2@kitterman.com Fri Jun 29 05:03:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A7521F86AF for ; Fri, 29 Jun 2012 05:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH5DisUh+LYX for ; Fri, 29 Jun 2012 05:03:08 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id DBCE321F865E for ; Fri, 29 Jun 2012 05:03:07 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 0C032D04086; Fri, 29 Jun 2012 07:03:07 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340971387; bh=cXLb5d3npBN6w3uF5bfsIPbI2+gio/+eQdF/opfBhOw=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=ZFRhDuEfsXbNeFsgMx7Gjgcx5ag5WTZLXaZ8QCJ+XVVJevuksl2ytBZfbTP2UfyQ8 FynRgjFhnaCC6jyhxLkqs8jt1tII1ve157T8Ea+BotDTboyAeJF4KFGvsRs+IVSLLI ijPr4hmUC87JSw3zGa9PJFfOEdnHsy8+gisi14oE= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0560CD04067; Fri, 29 Jun 2012 07:03:05 -0500 (CDT) References: <6.2.5.6.2.20120627230533.09253e18@elandnews.com> <121909424.1Q2iX6uX2m@scott-latitude-e6320> <6.2.5.6.2.20120628094142.0a649fd8@resistor.net> <1572146.ZK696AIlyj@scott-latitude-e6320> <6.2.5.6.2.20120628122825.0a710fa8@resistor.net> <4FED9244.6000106@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: <4FED9244.6000106@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 29 Jun 2012 08:02:54 -0400 To: spfbis@ietf.org Message-ID: <6771b5a6-08ba-4ff0-9bac-93d7ff2911a2@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] References in draft-ietf-spfbis-4408bis-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 12:03:09 -0000 Alessandro Vesely On Thu 28/Jun/2012 22:13:06 +0200 S Moonesamy wrote: >> At 11:11 28-06-2012, Scott Kitterman wrote: >>> Perhaps it would be clearer if we changed the comment to: >>> >>> ; LDH rule plus additional TLD restrictions >>> ; (see [RFC3696], Section 2 for background >>> ; information) >> >> We would also be changing the ABNF. Given that the ABNF is normative >> in this draft I consider such a change as substantive. I would like >> to get more input on this from other WG participants. > >I'd avoid to change the ABNF unless we find errors in it. In that >respect, moving a reference is less of a change than adding a comment. My suggestion was neither of those. There's already an informational comment. My preference is to leave it unchanged, but if people find the comment confusing we should clarify it (by which I mean make clear the original meaning). Scott K From vesely@tana.it Fri Jun 29 05:14:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8380A21F86F7 for ; Fri, 29 Jun 2012 05:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.547 X-Spam-Level: X-Spam-Status: No, score=-4.547 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILan6Z4zYWRY for ; Fri, 29 Jun 2012 05:14:41 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E158221F8661 for ; Fri, 29 Jun 2012 05:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1340972071; bh=9VVvjfvfv1RK323KLCPD15zhETiePajjfaRDAqgY9J0=; l=3187; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=XtWl+VWNnsGiBh4H+FTbO/pZV70YERxGsuADQ3XHatAH0haaaihrVjQQT5UxRbImH 3YGCxJjc8rJr/FqepK9uLuqXuyoWua+f1TlbilS0Di0gmGl4u5cOhDUZlMI6S/jVPA jxcK6vTCXO9G5/gslgdr8RiH9yVTTJU/3Xp5uHtk= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 29 Jun 2012 14:14:31 +0200 id 00000000005DC039.000000004FED9C27.00002830 Message-ID: <4FED9C27.9070704@tana.it> Date: Fri, 29 Jun 2012 14:14:31 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <6747592.4CmXrOD8P9@scott-latitude-e6320> <6.2.5.6.2.20120628161803.063558c0@resistor.net> <7180122.qjqJa4HyJa@scott-latitude-e6320> <6.2.5.6.2.20120628232936.0635a458@resistor.net> In-Reply-To: <6.2.5.6.2.20120628232936.0635a458@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 12:14:42 -0000 On Fri 29/Jun/2012 09:06:40 +0200 S Moonesamy wrote: > At 20:26 28-06-2012, Scott Kitterman wrote: >> The issue was only posed in reference to 2.5.5. I have: >> >> The domain owner wants to discourage the use of this host and >> thus desires limited feedback when a "softfail" result occurs. >> For example, the recipient's Mail User Agent (MUA) could >> - highlight the "SoftFail" status, or the receiving MTA could give >> - the sender a message using a technique called "greylisting" >> - whereby the MTA can issue an SMTP reply code of 451 (4.3.0 DSN >> - code) with a note the first time the message is received, but >> - accept it the second time. >> + highlight the "softfail" status, or the receiving MTA could give >> + the sender a message using greylisting, , >> + with a note the first time the message is received, but accept it >> + on a later attempt based on receiver policy. I like that change. >> Are there other places you think it should be changed? > > As we are going over the SMTP reply codes and the extended status > codes, here's are the occurrences in the draft: > > In Section 2.5.4: > > "If the checking software chooses to reject the mail during the SMTP > transaction, then it SHOULD use an SMTP reply code of 550 (see > [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see > [RFC3463]), in addition to an appropriate reply text." SMTP defines 550 for policy reasons, while 5.7.1 bears a slightly different meaning in RFC 5248. How about defining SPF entries in http://www.iana.org/assignments/smtp-enhanced-status-codes/ ? > In Section 2.5.6: > > "If the message is rejected during the SMTP transaction for this > reason, the software SHOULD use an SMTP reply code of 451 and, > if supported, the 4.4.3 enhanced status code." 451 implies a local malfunction, it is probably inappropriate for timeouts that originate from remote misconfiguration or similar issues. Previous question about enhanced codes applies here too. > In Section 2.5.7: > > "If the message is rejected during the SMTP transaction for this > reason, the software SHOULD use an SMTP reply code of 550 and, if > supported, the 5.5.2 enhanced status code." > > I suggest that the working group reviews and comments on all the > occurrences. Since SMTP is very clear about 550, we could just refer to it, as we did for greylisting. If we define SPF enhanced codes, they would have to go to the I-D's IANA Section. That way, we could avoid cluttering those definitions with operational considerations. Personally, I hate that wording "If the message is rejected", as it is an indirect way to insinuate that it could make sense to devise a conforming policy, without ever taking the responsibility of telling how to behave in order to get what results. Much of SPF folklore hinges on rejecting messages in order to refrain abuse of domain names. However, the domains that deploy such behavior seem to be <2%. Hence, if we are consistent with what we did with RRTYPEs, we could as well avoid to standardize unqualified suggestions. Why don't we talk about that in Vancouver? From spf2@kitterman.com Fri Jun 29 06:36:30 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A7F21F86EE for ; Fri, 29 Jun 2012 06:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoPLT+tb-XPH for ; Fri, 29 Jun 2012 06:36:27 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F38BA21F86E4 for ; Fri, 29 Jun 2012 06:36:24 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1CFF420E40FC; Fri, 29 Jun 2012 09:36:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340976984; bh=rZobQurIxfvBYHdEfmTd86U/z1MX1VvWBcqABZN9b/0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=mKaMYN1LNeRCNPI/CR7B+EcvZWcq1dg+iQqONSYedUu/lS/439SjyLN20kn05CyH4 1VnKFPariAKAKdExRrRoqwahxsIobf71SA9C1IqOjL6Z0a1C7um1vus3FMoOGpVQpf hc65bANhZMMUx6N4pca388eBq5sLZq3LlTLS5aPk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 02D2920E4081; Fri, 29 Jun 2012 09:36:23 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 09:36:23 -0400 Message-ID: <1717568.EdvZcqtpEi@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-25-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FED9C27.9070704@tana.it> References: <20120627051927.22022.60809.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120628232936.0635a458@resistor.net> <4FED9C27.9070704@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-01.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 13:36:31 -0000 On Friday, June 29, 2012 02:14:31 PM Alessandro Vesely wrote: > On Fri 29/Jun/2012 09:06:40 +0200 S Moonesamy wrote: ... > > As we are going over the SMTP reply codes and the extended status > > codes, here's are the occurrences in the draft: > > > > In Section 2.5.4: > > "If the checking software chooses to reject the mail during the SMTP > > > > transaction, then it SHOULD use an SMTP reply code of 550 (see > > [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see > > [RFC3463]), in addition to an appropriate reply text." > > SMTP defines 550 for policy reasons, while 5.7.1 bears a slightly > different meaning in RFC 5248. How about defining SPF entries in > http://www.iana.org/assignments/smtp-enhanced-status-codes/ ? It's true that 5.7.1 is different, but the enhanced status codes have more detail in them (that's why the are enhanced). Being different is to be expected. >From RFC 5321 Section 4.2.2: 550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) >From RFC 3463 section 3.8: X.7.1 Delivery not authorized, message refused The sender is not authorized to send to the destination. This can be the result of per-host or per-recipient filtering. This memo does not discuss the merits of any such filtering, but provides a mechanism to report such. This is useful only as a permanent error. I think these are sufficiently consistent and there is no evidence that I recall being discussed in the working group from these codes that they should be left unchanged. In general, receivers are reluctant to get into detail about why the accept or reject messages for fear that senders will use the information to game the system. I don't think defining additional status codes for SPF is necessary, within the scope of the charter, or likely to get much deployment. It is also completely unnecessary to define a new status code to let senders know that this is an SPF related rejection (or deferral). This is precisely what the exp= modifier is for. If you look at the last example in Section 6.2 or RFC 4408 (the one with why.html in it) you'll find that is actually supported by a web service of openspf.org: http://www.openspf.org/Why Exp= can convey far more information than a status code. > > In Section 2.5.6: > > "If the message is rejected during the SMTP transaction for this > > > > reason, the software SHOULD use an SMTP reply code of 451 and, > > if supported, the 4.4.3 enhanced status code." > > 451 implies a local malfunction, it is probably inappropriate for > timeouts that originate from remote misconfiguration or similar > issues. Previous question about enhanced codes applies here too. No. It doesn't. RFC 5321 Section 4.2.2 says: 451 Requested action aborted: error in processing It says there's an error. It says nothing about where or why. Reviewing that section, I certainly don't see a better one. For the enhanced status code, RFC 3463 Section 3.5: X.4.3 Directory server failure The network system was unable to forward the message, because a directory server was unavailable. This is useful only as a persistent transient error. The inability to connect to an Internet DNS server is one example of the directory server failure error. Given that temperrors are all DNS errors of some kind, I think this is reasonable. Rather than repeat myself, I'll point to the comment about that there's nothing broken here to fix. > > In Section 2.5.7: > > "If the message is rejected during the SMTP transaction for this > > > > reason, the software SHOULD use an SMTP reply code of 550 and, if > > supported, the 5.5.2 enhanced status code." > > > > I suggest that the working group reviews and comments on all the > > occurrences. > > Since SMTP is very clear about 550, we could just refer to it, as we > did for greylisting. If we define SPF enhanced codes, they would have > to go to the I-D's IANA Section. That way, we could avoid cluttering > those definitions with operational considerations. I'm not sure what you're suggesting about 550. Please provide text so I can better understand your point. I think defining new codes is out of scope as discussed above. > Personally, I hate that wording "If the message is rejected", as it is > an indirect way to insinuate that it could make sense to devise a > conforming policy, without ever taking the responsibility of telling > how to behave in order to get what results. We were very careful to avoid defining receiver policy in RFC 4408 (Section 2.5.2 is the only exception to that). Given that decision, "If the message is rejected ..." is a perfectly reasonable way to describe how to approach a given receiver policy if a receiver chooses to select that policy. I did not sense much traction from the group with the idea that we should define receiver policy in 4408bis. Even if the group did favor it, I think that it would be out of scope for the current charter. > Much of SPF folklore hinges on rejecting messages in order to refrain > abuse of domain names. However, the domains that deploy such behavior > seem to be <2%. Hence, if we are consistent with what we did with > RRTYPEs, we could as well avoid to standardize unqualified suggestions. I think the SPF RR Type is completely orthogonal to this discussion. Having consistency in how one does rejection has a value for interoperability so it's reasonable to specify it. It's not folklore. It is more suitable for some domains than others. A lot of small domains do it. I've distributed software for about half a decade configured to reject by default and never gotten a complaint about it (I did get complaints about defer on temperror by default, so I've got experience that says when my defaults cause people problems, I'll find out). In the scheme of Internet mail volumes they may not add up to a large percentage, but they do exist. For larger organizations getting SPF deployment right is hard, both for senders and receivers. There are ongoing developments that will make it easier to do this, but I'm not surprised large organizations don't reject. > Why don't we talk about that in Vancouver? I don't think there's anything to discuss. Scott K From sm@elandsys.com Fri Jun 29 09:24: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 2A57E21F876F for ; Fri, 29 Jun 2012 09:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIebuZErsU-B for ; Fri, 29 Jun 2012 09:24:28 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9466221F8513 for ; Fri, 29 Jun 2012 09:24:28 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.175]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5TGO6F7010897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jun 2012 09:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340987061; bh=Jt4XoMjL1/b49j1fx+jDXZSXFpyNXoeE449t52Nht/A=; h=Date:To:From:Subject:Cc; b=wPJnDuhce9GRSCI5YhumsWDn1B/Bd9LtdcFFAwe7XjHyJWTqduMXGRs3Sp7KlTsSq zBHqcTgPDzQJrgY1LfbXWV/ik57f3aq6a+yStuQX55RZAIeBU5xrbqUsWsUEFEEAKj A3c/AVRHhhUlG81L3wWD7QtVO6TgJZ42Z29TkWdk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340987061; i=@elandsys.com; bh=Jt4XoMjL1/b49j1fx+jDXZSXFpyNXoeE449t52Nht/A=; h=Date:To:From:Subject:Cc; b=uk+GaGHmP0l/IU3ZuW20dHAlv7DHX1gEBw0nl1TH67Ki754d33NSWlMKrD/Ca97O/ JV6jItW0aarJ6cSlRTGnTDr2fDi1oQkfpC61WBT8leDLFUMBMQlyXjWNVcbEHpZMoM S/PNPwxDHUMC5VhFbICPLJqVIerma8yC9WqFAgWQ= Message-Id: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 29 Jun 2012 09:12:43 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Summary of open issues X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 16:24:31 -0000 Hello, Here's a summary of the open issues. Issue #15 is about Section 2.2 of RFC 4408. Scott Kitterman made a text change ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01626.html ). Alessandro Vesely commented on it ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01629.html ). Issue #16 has been marked resolved ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01617.html ). Issue #20 has been marked as resolved ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01618.html ). Issue #8 has been marked as resolved ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01619.html ) Issue #19 has been marked as resolved ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01620.html ). Issue #18 is about Section 2.5.6. "DSN code" has been changed to "extended status code The reference was also changed. I'll leave this one open in the tracker as there has ony been two comments ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01692.html ). Issue #3 (erratum #99) is a typo in the IESG Note. I am marking this issue as resolved. Issue #23 is about typos in the draft. The fix is in -00. I am marking the issue as resolved. Issue #1 is about Section 2.5.6. Issue #18 is also about that subsection. There were only two comments and a text change was proposed ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01633.html ). I'll leave this open. Issue #7 is about downcasing result names. Murray Kucherawy commented on this ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01639.html ). Barry Leiba mentioned that mixed-case invited confusion ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01649.html ). I'll leave this issue open. Regards, S. Moonesamy From spf2@kitterman.com Fri Jun 29 09:30:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FD221F87C7 for ; Fri, 29 Jun 2012 09:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5JmS8PyzCP0 for ; Fri, 29 Jun 2012 09:30:17 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9047721F85DF for ; Fri, 29 Jun 2012 09:30:17 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A4C0920E40FC; Fri, 29 Jun 2012 12:30:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340987416; bh=jNC4hCDgzccokrjBYwIGEFdizY7exOj8XGeu7s9i+mU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=NvXbBnXAtcnLtq5QzF3NQ+nW/VyIm8l77LWJx4ElaZgbRhDx4zC9YZEwbsuMx3+0K UiXf8PzJeDSTZogGnLE4Tvt2Jpp87KAy7M1KtIDDNRsCTYTTGc2irKUuqCZAM/YjMF MXD0JLQVtRuAp/c7zKs5YLpSY6h3H2FEQtIwPLjs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8B53220E4081; Fri, 29 Jun 2012 12:30:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 12:30:12 -0400 Message-ID: <4413487.cs3tHlyCpu@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of open issues X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 16:30:18 -0000 On Friday, June 29, 2012 09:12:43 AM S Moonesamy wrote: > Issue #7 is about downcasing result names. Murray Kucherawy > commented on this ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01639.html > ). Barry Leiba mentioned that mixed-case invited confusion ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01649.html > ). I'll leave this issue open. Modulo one outlier I missed that's fixed locally, this is done in -01. I think it's safe to close. Scott K From spf2@kitterman.com Fri Jun 29 09:36: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 8A48521F87E8 for ; Fri, 29 Jun 2012 09:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zZXjDH+i+rs for ; Fri, 29 Jun 2012 09:36:47 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CF01A21F87E1 for ; Fri, 29 Jun 2012 09:36:47 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 606F420E40FC; Fri, 29 Jun 2012 12:36:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340987807; bh=vpsLjdA/ILCOoOwFXY4YEcNhQDuojXuwsFHXIcCYvho=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=E44MZ9foftDlNMcwUL4EqFSQI+XBCv1p6fgaMe3PAOmZ0TzEoVYhJU+lwSBX2eNpI EqYYwdsiJ56rQ5GexQGIByWBQS66rQtjgNmIGFzqBbnBFJjaBQun3zFGGU9/oky/3y 1urnG2n+9GlSfA7J+paPOISjhpFfiRP+SXQdXnVg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 41CEB20E4081; Fri, 29 Jun 2012 12:36:47 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 12:36:46 -0400 Message-ID: <2849452.xt3CYtE0O4@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of open issues - #15 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 16:36:48 -0000 On Friday, June 29, 2012 09:12:43 AM S Moonesamy wrote: > Issue #15 is about Section 2.2 of RFC 4408. Scott Kitterman > made a text change ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01626.html > ). Alessandro Vesely commented on it ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01629.html ). Which I think we adequately answered: http://www.ietf.org/mail-archive/web/spfbis/current/msg01632.html I think this one can be closed. Scott K From spf2@kitterman.com Fri Jun 29 09:42:24 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 70CFB21F87EA for ; Fri, 29 Jun 2012 09:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PFULRJc7KCN for ; Fri, 29 Jun 2012 09:42:23 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DB01A21F87F2 for ; Fri, 29 Jun 2012 09:42:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6744B20E40FC; Fri, 29 Jun 2012 12:42:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340988142; bh=9lQX0mdJU/nxlbGPHEnrUT2EKFGYrofB1KLQyRvB46Q=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=pdz4LTqFU3lAx0gUPlwxqFSWjhq1WM9UmCXNgAzM8JzT1MUNWu+LgJQIxwuj0hwol wMZ5ToJI6e8ZknucXrKgaddMIOey+eL/mhZlYwg8uhOJjQvmPahwBpxXAWxcHTCFz5 3hjNbBpcCI+WGPE8/SkqZXnsDBmWNTZtf2Q9Na40= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 49F5020E4081; Fri, 29 Jun 2012 12:42:22 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 12:42:21 -0400 Message-ID: <2172228.rnEX5dUacC@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of open issues - #5 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 16:42:25 -0000 On Friday, June 29, 2012 09:12:43 AM S Moonesamy wrote: > Hello, > > Here's a summary of the open issues. Ticket #5 is shown as open in the tracker. I believe it was resolved in the -01 draft. Here are the relevant entries from the change summary: Clarified text about IPv4 mapped addresses to resolve test suite ambiguity Clarified ambiguity about result when more than 10 "mx" or "ptr" records are returned for lookup to specify permerror. This resolves one of the test suite ambiguities My recommendation is to close this one too. Scott K From sm@elandsys.com Fri Jun 29 09:49:30 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95B721F87D6 for ; Fri, 29 Jun 2012 09:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Nz19j9zq73F for ; Fri, 29 Jun 2012 09:49:26 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD81D21F8780 for ; Fri, 29 Jun 2012 09:49:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.175]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5TGnBRL027191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 09:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340988565; bh=roFucUUjv90RUvlyYIHy9xqnzPYAy5CopOC2WFY6sU8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BsGw3fNFIegdqME9zcp5m/gbgrmDEEiiNU9Hm5gDYcI8pIjbVEmlhxeP+/scGXBU+ CL6NGWnJ+NOxjyIIZV+87sqwaiuRuO8tMKMue3X/C3SElPAShtZeJjuZe6M1R5QdyA 61ANBFJTel6+mt0q0dmXpANgF+EBJWhL4G0Mf1vQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340988565; i=@elandsys.com; bh=roFucUUjv90RUvlyYIHy9xqnzPYAy5CopOC2WFY6sU8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=29lpMTGP3uMDR+catNrHbHPVTfamGabD6Kth44SchwPaKxlZx/fyz7+9YXKftrx70 wAWQ+5jlhXPFN48yILKcgDcbaTeJjoIkfTu07qKlWuKYHRrpnKIjm1JhVTJJQZ7h6m 9nH5sXq6haImbCBqG1CqkBdF2844vhhNVED4vGug= Message-Id: <6.2.5.6.2.20120629094239.09ac9160@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 29 Jun 2012 09:49:06 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <4413487.cs3tHlyCpu@scott-latitude-e6320> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <4413487.cs3tHlyCpu@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Summary of open issues X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 16:49:31 -0000 Hi Scott, At 09:30 29-06-2012, Scott Kitterman wrote: >Modulo one outlier I missed that's fixed locally, this is done in >-01. I think >it's safe to close. At 09:36 29-06-2012, Scott Kitterman wrote: > > Issue #15 is about Section 2.2 of RFC 4408. Scott Kitterman > > made a text change ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg01626.html > > ). Alessandro Vesely commented on it ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg01629.html ). > >Which I think we adequately answered: > >http://www.ietf.org/mail-archive/web/spfbis/current/msg01632.html > >I think this one can be closed. I'll close Issues #7 and #15 by the end of the day if there aren't more comments. Regards, -sm From sm@elandsys.com Fri Jun 29 09:50:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CC521F87ED for ; Fri, 29 Jun 2012 09:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWIIouPgaE9V for ; Fri, 29 Jun 2012 09:50:22 -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 7F09F21F87FE for ; Fri, 29 Jun 2012 09:50:22 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.175]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5TGo0Ca026288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 09:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340988616; bh=hRsjcVzqSCtIoRzcSIgkQ7SiNQ34ow2YdfvacDf07UM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=16ktP7Suf5FgM8qywrFPr05hYijsYXsrft6sibKTjVDARH9w8RNGMtTTCoWvqYnqi obtbjahWGJiRE1b7uyuuvF5c1HuWqhlLHM/wxZxQhUo/e/+KyCFKQ6wbjNLqCLSoZk mlaHM4zNUvHWcwXbX3RspBvE2LNjxw7Xve5sEvhM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340988616; i=@elandsys.com; bh=hRsjcVzqSCtIoRzcSIgkQ7SiNQ34ow2YdfvacDf07UM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=i4nYfTWC6NiFLh1vOB1+5LViQO3dXG1WaxAIhXKp9rKdi2Fec+bHSYMma08xZ93a7 SwvsgO/rmxDMTTL3if2LPu30S0c9vODycdr9ODnsymJbt0Ya6AAhQYG/u8ZL2/ii87 cxiyFWCLgXXAErI1PjuoOGHQ5Sz/rUUEMyshT4Ec= Message-Id: <6.2.5.6.2.20120629092333.08feed68@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 29 Jun 2012 09:29:12 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4F4D31E9.2000601@dcrocker.net> References: <20120222193641.73783.qmail@joyce.lan> <2096925.c5NMhqV2Wo@scott-latitude-e6320> <20120222200826.GF36315@mail.yitter.info> <4F4555F5.1090301@dcrocker.net> <20120222211346.GI36315@mail.yitter.info> <4F4D31E9.2000601@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Scott Kitterman Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 16:50:28 -0000 Issue #9 is about the SPF RR Type and TXT RR. After discussion on the mailing list and at the last meeting, the conclusion was to use the TXT RR. The document editor can propose text to reflect that. Please discuss the text change on this thread. Regards, S. Moonesamy From sm@elandsys.com Fri Jun 29 09:50:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9584B21F87FE for ; Fri, 29 Jun 2012 09:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUyvXIIBkfv3 for ; Fri, 29 Jun 2012 09:50:22 -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 990EE21F87FF for ; Fri, 29 Jun 2012 09:50:22 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.175]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5TGo0Cc026288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 09:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340988620; bh=EkzTCwO0iY4jZPOtxy/e2+Tg0ddNLKW00rmZc/1jE1U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cdMk6qDF/b60/lckaoO6wqeb1PFzzpf6yGYBrCeX7gnCQkcfyTTcMnDjtlyYp+NSC 7inN2qjdA5O9/rRWkAH1Sf/cgR2HPTjK40ZlDQtaaDdr67dbbGkkDCLGGkTfxRyTBi ZylAyaGrD/XCc+zfoGAYdXPPHfpXO4ojj1Xtu5V4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340988620; i=@elandsys.com; bh=EkzTCwO0iY4jZPOtxy/e2+Tg0ddNLKW00rmZc/1jE1U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PKgOeNn4vDJ781T66I45IftWg8eQlUmW+E8mUi3t7t87WAPXeefNPz60sizD0mG2x oV15maFbfwi3Q3fX6RhF6pTaKWwIXF0HtwyRvOfEPH76iV4hRanRu19fkswRczpqBi 3Z5qtx+Qq8vRpLijIYfdRLcEnEudaCpHd5eO2c4M= Message-Id: <6.2.5.6.2.20120629093446.08feec20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 29 Jun 2012 09:39:55 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120312140847.09fa4e10@resistor.net> References: <20120308173320.19832.qmail@joyce.lan> <1635014.q2pgS3jpuG@scott-latitude-e6320> <9452079D1A51524AA5749AD23E003928080BB9@exch-mbx901.corp.cloudmark.com> <6.2.5.6.2.20120312140847.09fa4e10@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Scott Kitterman Subject: Re: [spfbis] #25: RFC 4408: Section 4.4 Parallel Query X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 16:50:28 -0000 Issue #25 is about Section 4.4. There is a summary of the discussion about parallel query at http://www.ietf.org/mail-archive/web/spfbis/current/msg00876.html As issue #9 is being resolved, the working group may be able to resolve this issue at the same time. I'll leave it to the document editor to suggest text. Please use this thread to discuss about the text change. Regards, S. Moonesamy From spf2@kitterman.com Fri Jun 29 09:52:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F0721F8807 for ; Fri, 29 Jun 2012 09:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hb92P1JKOQgs for ; Fri, 29 Jun 2012 09:52:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6D49121F87ED for ; Fri, 29 Jun 2012 09:52:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E737720E40FC; Fri, 29 Jun 2012 12:52:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340988734; bh=GCZJ0TI+hFJPpM1//t3umYOdzBDm3axz0GLAvfOkYao=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=bPhfQtdYiB3TY9WD01w7++v9Ii8y7bwH4j+lAKuDeNp+10BMeV9hY0SieaqcbntkZ vAmLzxio39CUZwT7memXy22Vl6QqkJGUkNzLHTvpjkPlTs2DrRP3aQr7bSo4pzebJF h+SBKDCROnZv7HIcP08pEVAkNG3lA6SiwefzFPOw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C8A6C20E4081; Fri, 29 Jun 2012 12:52:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 12:52:14 -0400 Message-ID: <30479361.ljzN8QzUYA@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of open issues - 22 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 16:52:18 -0000 On Friday, June 29, 2012 09:12:43 AM S Moonesamy wrote: > Hello, > > Here's a summary of the open issues. #22 RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion What turned out to be #22 had a bit of discussion on the list as a test suite related question, but it died out. I liked Andrew's suggestion in: http://www.ietf.org/mail-archive/web/spfbis/current/msg01602.html I would appreciate some ideas on how to do that in the ABNF as that's clearly the desired state. Scott K From sm@elandsys.com Fri Jun 29 11:00:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363E021F8806 for ; Fri, 29 Jun 2012 11:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep79ki0haZIL for ; Fri, 29 Jun 2012 11:00:08 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD6F21F87E9 for ; Fri, 29 Jun 2012 11:00:07 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.175]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5THxrgj017413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jun 2012 11:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340992806; bh=hpPOyEFUTd/cAm+auxi01HODLumbFVHC8CZUyLAWJmQ=; h=Date:To:From:Subject:Cc; b=BAyJha1cV4bvgB6fFKAqC/Ws7QYpCaoCdzJYL3QLKdDT6vHRJbpZY3hdm8mM4yxCB 0+E/FnTcXwecM7WovvigHEUTiJm4xw9hZboEJvj0Kt0inBdKlT1/JPwM4xgG01XArM K1389czIFuHZO5PMFzge2mJ3Y8QsONo7EhgoGboY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1340992806; i=@elandsys.com; bh=hpPOyEFUTd/cAm+auxi01HODLumbFVHC8CZUyLAWJmQ=; h=Date:To:From:Subject:Cc; b=CLw56ruIixsFDOni0+p8TbndVQzgeZXtkzCl5/rYaC3PLBmBiFWPWEjiKFR0knvKw Od6RKm0aS6fwXl9+ZIjCtWvpDdszxsEr1/5W98KHcwRg+cOSuWwAPTXCjlKV+m2QXg DINsU1yA73PhugxF4jjLWOXaZtuHvKKDF4a4hSak= Message-Id: <6.2.5.6.2.20120629101147.09d3cb10@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 29 Jun 2012 10:12:19 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #5: RFC 4408 ambiguities X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 18:00:12 -0000 Issue #5 is based on the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00284.html The document editor made a text change in -01 to resolve the issue ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01697.html ). If there aren't any comments about the text change, I'll close the ticket. Regards, S. Moonesamy From spf2@kitterman.com Fri Jun 29 11:11:21 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 D2DE921F884A for ; Fri, 29 Jun 2012 11:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oScX2AZ7mua for ; Fri, 29 Jun 2012 11:11:11 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7519221F8848 for ; Fri, 29 Jun 2012 11:11:11 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DC6CB20E40FC; Fri, 29 Jun 2012 14:11:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340993470; bh=3Yqao1pIIUI4ZEiTds8T6cFm1ZOsVizaM3UgYVI89ZU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NwXntmkbDlFfwQHN2ZXuOR8wdOjhZ7Ipqu9QkB1XR9mUyK0HDgchn6gdygG1qV3UM nJnSZXM3z/g8DCHjdPzCPTKeJhMCSckMCfsPb7Nvjv5TFlKT81TYIKQGyTiy6pX+tx kpILSOn+SS+yAQYOl4DPVmXXEtAU7Xav3El4wxX0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C1A6920E4081; Fri, 29 Jun 2012 14:11:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 14:11:10 -0400 Message-ID: <1390536.tGbELFoml6@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120629092333.08feed68@resistor.net> References: <20120222193641.73783.qmail@joyce.lan> <4F4D31E9.2000601@dcrocker.net> <6.2.5.6.2.20120629092333.08feed68@resistor.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart6042856.spHi4SLt5O" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 18:11:22 -0000 --nextPart6042856.spHi4SLt5O Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Friday, June 29, 2012 09:29:12 AM S Moonesamy wrote: > Issue #9 is about the SPF RR Type and TXT RR. After discussion on > the mailing list and at the last meeting, the conclusion was to use the TXT > RR. > > The document editor can propose text to reflect that. Please discuss > the text change on this thread. Yesterday I prepared a proposed change for this issue, and #25: RFC 4408: Section 4.4 Parallel Query, that'll be in the -02 I plan to post today (since msk promised to read the draft over the weekend). For parallel query, I think it's essentially OBE since we aren't going to recommend doing lookups for both types. My proposed diff for this is attached. It'll look prettier in the rfcdiff once I publish -02. Scott K --nextPart6042856.spHi4SLt5O Content-Disposition: attachment; filename="dep_type_spf.diff" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="dep_type_spf.diff" --- draft-ietf-spfbis-4408bis-01.txt 2012-06-27 01:13:36.595084337 -0400 +++ draft-ietf-spfbis-4408bis-02.txt 2012-06-29 13:48:48.496483502 -0400 @@ -654,36 +710,29 @@ 3.1.1. DNS Resource Record Types - This document defines a new DNS RR of type SPF, code 99. The format - of this type is identical to the TXT RR [RFC1035]. For either type, - the character content of the record is encoded as [US-ASCII]. + [RFC4408] defined a new DNS RR of type SPF, code 99. The format of + this type is identical to the TXT RR [RFC1035]. For either type, the + character content of the record is encoded as [US-ASCII]. - It is recognized that the current practice (using a TXT record) is - not optimal, but it is necessary because there are a number of DNS - server and resolver implementations in common use that cannot handle - the new RR type. The two-record-type scheme provides a forward path - to the better solution of using an RR type reserved for this purpose. + While it is recognized that the current practice (using a TXT record) + is not optimal, the transitional strategy to the new, dedicated RR + type failed to gain traction and has been abandoned for SPF Version + 1. Such use is deprecated for version 1, but should a need be + identified for an incompatible update to a later version, its use + might be appropriate. The background for this is described in + Appendix A of [draft-ietf-spfbis-experiment]. - An SPF-compliant domain name SHOULD have SPF records of both RR - -Kitterman Expires December 29, 2012 [Page 12] +Kitterman Expires December 31, 2012 [Page 13] Internet-Draft Sender Policy Framework (SPF) June 2012 - types. A compliant domain name MUST have a record of at least one - type. If a domain has records of both types, they MUST have - identical content. For example, instead of publishing just one - record as in Section 3.1 above, it is better to publish: - - example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" - example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all" - - Example RRs in this document are shown with the TXT record type; - however, they could be published with the SPF type or with both - types. + An SPF-compliant domain name MUST have SPF records of type TXT. An + SPF-compliant domain name MUST NOT publish only records of type SPF. + If a domain has records of both types, they MUST have identical + content. 3.1.2. Multiple DNS Records @@ -845,8 +901,9 @@ In accordance with how the records are published (see Section 3.1 above), a DNS query needs to be made for the name, querying - for either RR type TXT, SPF, or both. If both SPF and TXT RRs are - looked up, the queries MAY be done in parallel. + for type TXT. SPF Version 1 queries for records of type SPF SHOULD + NOT be done. If both SPF and TXT RRs are looked up, the queries MAY + be done in parallel. If all DNS lookups that are made return a server failure (RCODE 2), or other error (RCODE other than 0 or 3), or time out, then @@ -877,9 +934,6 @@ record with a version section of "v=spf10" does not match and must be discarded. - 2. If any records of type SPF are in the set, then all records of - type TXT are discarded. - After the above steps, there should be exactly one record remaining and evaluation can proceed. If there are two or more records remaining, then check_host() exits immediately with the result of --nextPart6042856.spHi4SLt5O-- From WebMaster@Commerco.Net Fri Jun 29 11:16:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E87C21F884C for ; Fri, 29 Jun 2012 11:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpUm3HPvy1H0 for ; Fri, 29 Jun 2012 11:16:16 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id BA5DF21F884F for ; Fri, 29 Jun 2012 11:16:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=VBDE+I2JnZl/FvTr8tygw/yIvQ9RsdVC1QwiSsDqLAZ1anu5s31TmnxzGiLjQ6QX+yZntKmfOfUpVGjGDrTNNahn5Z6ump0cI681QjePiICxyPaCIbhrOJdGX54mYnH0yFihGo/ARzQSmI37FvdPzKKv4Pw6Sm7oFwigzdIdtVI= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Fri, 29 Jun 2012 18:16:13 +0000 Message-ID: <4FEDF0E7.8040303@Commerco.Net> Date: Fri, 29 Jun 2012 12:16:07 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <4F4D31E9.2000601@dcrocker.net> <6.2.5.6.2.20120629092333.08feed68@resistor.net> <1390536.tGbELFoml6@scott-latitude-e6320> In-Reply-To: <1390536.tGbELFoml6@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 18:16:18 -0000 On 6/29/2012 12:11 PM, Scott Kitterman wrote: > On Friday, June 29, 2012 09:29:12 AM S Moonesamy wrote: >> Issue #9 is about the SPF RR Type and TXT RR. After discussion on >> the mailing list and at the last meeting, the conclusion was to use the TXT >> RR. >> >> The document editor can propose text to reflect that. Please discuss >> the text change on this thread. > > Yesterday I prepared a proposed change for this issue, and #25: RFC 4408: > Section 4.4 Parallel Query, that'll be in the -02 I plan to post today (since > msk promised to read the draft over the weekend). For parallel query, I think > it's essentially OBE since we aren't going to recommend doing lookups for both > types. > > My proposed diff for this is attached. It'll look prettier in the rfcdiff once > I publish -02. > > Scott K > +1 Alan M. From internet-drafts@ietf.org Fri Jun 29 12:05: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 A6A7321F88AA; Fri, 29 Jun 2012 12:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQNS6KrUwwbB; Fri, 29 Jun 2012 12:05:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2BE21F8855; Fri, 29 Jun 2012 12:04:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120629190443.9297.40140.idtracker@ietfa.amsl.com> Date: Fri, 29 Jun 2012 12:04:43 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-02.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 19:05:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Dom= ains in Email, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-02.txt Pages : 56 Date : 2012-06-29 Abstract: E-mail 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 reverse-path 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 a domain can explicitly authorize the hosts that are allowed to use its domain name, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Fri Jun 29 12:07:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D4121F8658 for ; Fri, 29 Jun 2012 12:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD2NWANTl06S for ; Fri, 29 Jun 2012 12:07:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F0E4C21F8657 for ; Fri, 29 Jun 2012 12:07:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5A93A20E40FC; Fri, 29 Jun 2012 15:07:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340996870; bh=SAiucNxRrUjftfxwOZ/hztd2XQezA0eTlrpZO8LRWoM=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=bDGXPBYksHDNp++ghuxW1qfs2GyzNFogsBn3L6FLj35oTjX1q6E1xeBXAd5OG9ggn S8Y7lYbDAMzEXm2c+msVMPHX3/LjB6BPZpEIQf/PZhOxiROke4D9eHq1FfhQF2lHtM FSnmLD2MrK+KN+BCuTKQJQPDd6yEThkDlCgJI5gs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3C1D220E4081; Fri, 29 Jun 2012 15:07:50 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 15:07:49 -0400 Message-ID: <1610254.tmmhToiaLs@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <20120629190443.9297.40140.idtracker@ietfa.amsl.com> References: <20120629190443.9297.40140.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-02.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 19:07:57 -0000 On Friday, June 29, 2012 12:04:43 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the SPF Update Working Group of > the IETF. > > Title : Sender Policy Framework (SPF) for Authorizing Use > of Domains in Email, Version 1 Author(s) : Scott Kitterman > Filename : draft-ietf-spfbis-4408bis-02.txt > Pages : 56 > Date : 2012-06-29 Here's the revision log additions for this version: Refer to RFC6647 to describe greylisting instead of trying to describe it directly. Updated informative references to the current versions. Added definition for deprecated since there are questions. Start to rework section 9 with some RFC5598 terms. Added mention of RFC 6552 feedback reports in section 9. Added draft-ietf-spfbis-experiment as an informational reference. Initial draft of wording to deprecate Type SPF. Try and clarify informational nature of RFC3696 In particular, the changes for Type 99/SPF deprecation and the changes to section 9 to modernize it a bit and use terminology from the email architecture document should be reviewed. Have a nice weekend. Scott K From spf2@kitterman.com Fri Jun 29 12:45:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BD021F88A3 for ; Fri, 29 Jun 2012 12:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZyeBoK5wNVW for ; Fri, 29 Jun 2012 12:45:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3D721F888C for ; Fri, 29 Jun 2012 12:45:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DBF3120E40E9; Fri, 29 Jun 2012 15:45:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340999121; bh=SYs5qeoPa9TDFyGFSJwhwHuvcNt2+kuU62S02FX/KqY=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=QO12glba84Zj8s4sEL4jgkZDWd5sN20f8KCqqy7ytMDv7ALB6h+4sD5b2mPuWBegB tKCVASyIz7pMwx5pNAXxL3bmNf9KzLYtF6bmWzoXKrIgNx0FDyAxIkpHJykugDcjxo VALhLIURYOMKNxpJffi8Xs5+koC05+OF1NoP7iks= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C190C20E408E; Fri, 29 Jun 2012 15:45:21 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 15:45:21 -0400 Message-ID: <16158960.J7X6fhadlP@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of open issues - #2 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 19:45:23 -0000 On Friday, June 29, 2012 09:12:43 AM S Moonesamy wrote: > Hello, > > Here's a summary of the open issues. #2 RFC 4408 Section B.3 - Errata #2250 This issue is still open in the tracker, but it was fixed in one of the pre-WG drafts. Scott K From spf2@kitterman.com Fri Jun 29 12:46:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA9221F889E for ; Fri, 29 Jun 2012 12:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHiIwfqFyJcj for ; Fri, 29 Jun 2012 12:46:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E799021F888C for ; Fri, 29 Jun 2012 12:46:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8101220E40E9; Fri, 29 Jun 2012 15:46:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340999181; bh=uww8SOhrphI447IwYZxvh3+IhHDeloWkzchZeFIBul4=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=jDVX26wSpuvCVenjiz3jzbsgEg8kSGtXL9eaStJFxzR+aLDt4d3tCsJRvWclrfDOT 0EdrKzJGC9a6pbKCdcwYJM4jhcWkE+BckG83cdVpU7v7yg6Z3ClvmXyNFEWeaBd46N f+i1xPfMiHs76UJmaK7tOG5a20l0zpJmKQssssPg= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7019020E408E; Fri, 29 Jun 2012 15:46:21 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 15:46:21 -0400 Message-ID: <3265116.sr2OGvJaSX@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of open issues - #17 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 19:46:22 -0000 On Friday, June 29, 2012 09:12:43 AM S Moonesamy wrote: > Hello, > > Here's a summary of the open issues. #17 RFC 4408: Section 8.1 Undefined "uric" set This is still open in the tracker, but was fixed in a pre-WG draft. Scott K From spf2@kitterman.com Fri Jun 29 12:48:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429EF21F87BD for ; Fri, 29 Jun 2012 12:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZzqhONQt1Uo for ; Fri, 29 Jun 2012 12:48:16 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 83D1D21F87B7 for ; Fri, 29 Jun 2012 12:48:16 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0FE5420E40E9; Fri, 29 Jun 2012 15:48:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340999296; bh=JAVryBfM48P/RabehPYTHD152AZerOJ656643ekVG74=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=Sc0nmQIW+8tS7jm+UfB2Hh7QuWsRqX9sgcCurF+uyxpaLzsPYkopyYk4KWBWplWUa oiQFPYKKuntfX0twyD0AjrgIrNggZ2UteoJVV5dzU9GNBYWoRJU3UYuSYsa5yVdH/b XQJXV1SFATeRSiarAA8puozTYU52kWoR0xhuxkcA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E2A3720E408E; Fri, 29 Jun 2012 15:48:15 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 15:48:15 -0400 Message-ID: <1484112.CjeGCNgGfE@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of open issues - #28 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 19:48:17 -0000 On Friday, June 29, 2012 09:12:43 AM S Moonesamy wrote: > Hello, > > Here's a summary of the open issues. #28 i18n for EAI compatibility This issue is still open in the tracker, but my recollection was that the group concluded it was not needed or out of scope. I think it should be closed. Scott K From spf2@kitterman.com Fri Jun 29 12:51:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4348D21F88AE for ; Fri, 29 Jun 2012 12:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcrjsYPMOSb2 for ; Fri, 29 Jun 2012 12:50:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 61B2321F88AC for ; Fri, 29 Jun 2012 12:50:59 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E998920E40E9; Fri, 29 Jun 2012 15:50:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340999458; bh=g0+urV6PzW9BDPfQI366p5MfiE28csfrMBRm6eK+M3I=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=YyjtQPAn1F7vZL82FDaOmToCmR286u50xu3aQiHBL7spQbRgqhZtxZnLyjxQuG+Py oVk9tXuQKRrAIkEzHYjv8rlMS7+/KgizMkMXOGL8oOW0DWkAqx635KeEzNX6O6Nu7G tfNkvqpcVA66k+UqUP95uxe2htwX1CVT0WudvcsQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CF93020E408E; Fri, 29 Jun 2012 15:50:58 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 15:50:58 -0400 Message-ID: <4626481.rtT03bmxUE@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of open issues - #27 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 19:51:00 -0000 On Friday, June 29, 2012 09:12:43 AM S Moonesamy wrote: > Hello, > > Here's a summary of the open issues. #27 RFC 4408: Should the ptr: mechanism and the %{p} macro be deprecated This one is still open in the tracker. It was addressed in the WG -01 revision and no one raised questions about it, IIRC. I think it can be closed. Scott K From spf2@kitterman.com Fri Jun 29 12:52:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F3821F88BF for ; Fri, 29 Jun 2012 12:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4Ccomy7NfIn for ; Fri, 29 Jun 2012 12:52:17 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 53ED821F88AE for ; Fri, 29 Jun 2012 12:52:13 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B4C1520E40E9; Fri, 29 Jun 2012 15:52:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1340999532; bh=T4hwTEKAOlDwnh3n7cnSFVJGiCNQZL25k0ERghD5k68=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=XPY4N/Rvtqap+j+J9388m2p9tvhj7FtBF/SsqUlRznRCaqPWMYa8yxVR7yU3Hrs6h PRlrnbUcrwgctizuGawIVqxty85q5wHA5Vr0+ebKMf7w8ZASCelNZgh2YZNjozd2pq 1VVKbrpxvztp0V6Os9V1Up0ZygcOJUQhEeenzZas= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A37C120E408E; Fri, 29 Jun 2012 15:52:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 15:52:12 -0400 Message-ID: <2561504.giPAs2JvIf@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of open issues - #26 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 19:52:18 -0000 On Friday, June 29, 2012 09:12:43 AM S Moonesamy wrote: > Hello, > > Here's a summary of the open issues. #26 RFC 4408: Should the syntax checking of SPF records be relaxed at all This issue is still open in the tracker. IIRC the group agreed not to make any changes due to this issue. I believe it should be closed without further action. Scott K From johnl@iecc.com Fri Jun 29 13:23:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0831821F88C5 for ; Fri, 29 Jun 2012 13:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.027 X-Spam-Level: X-Spam-Status: No, score=-111.027 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H82BUtm-N0rp for ; Fri, 29 Jun 2012 13:23:58 -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 C08AD21F88CC for ; Fri, 29 Jun 2012 13:23:57 -0700 (PDT) Received: (qmail 48436 invoked from network); 29 Jun 2012 20:23:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Jun 2012 20:23:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fee0edc.xn--btvx9d.k1206; i=johnl@user.iecc.com; bh=mft2aP6xHeWib1PFkelyt4/6WJBvM5eXO0AFqybXXco=; b=YCqZiLDFCNZWR8HJ4diNqd2k8srnHQsTKT1+WeudVRrREmFQE2EmTqLfFjaDGuLNoDilWu9pjuLJMLZMEW9AlP9dWIX2BWFklkIqsJr6hPsi1LDw5aDfZKE1AOZEzFYd3UgUCxAaohcMHYw1JxA4u9aMsX5jEXF8SNkkifX0OW8= 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=4fee0edc.xn--btvx9d.k1206; olt=johnl@user.iecc.com; bh=mft2aP6xHeWib1PFkelyt4/6WJBvM5eXO0AFqybXXco=; b=Mr9iPwpNtek+9JJWXWaw7gSuhGy3jQ7q5dhNx9bFIcTqF9p3P64LDR+5r9BeuMY+6v5CPFJ4W7VRAKzZvJET2YK8Z+3gg53F8GCSlcDgy03GCtxhrkxQ+0JKyUvV7fPgSZ42FXqIptdwCBDQ4UFhLKCjgKmQmPzu31KdpxXBqa8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 29 Jun 2012 20:23:34 -0000 Message-ID: <20120629202334.42090.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1484112.CjeGCNgGfE@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] Summary of open issues - #28 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 20:23:59 -0000 >#28 i18n for EAI compatibility > >This issue is still open in the tracker, but my recollection was that the >group concluded it was not needed or out of scope. I think it should be >closed. The EAI RFCs are now published on the standards track, so it might be worth a look. For domains, there's the question of whether to allow UTF-8 domains, or to require that all IDN domains be represented as A-lablels. For any of the macro stuff that looks at mailboxes, whether to allow UTF-8 mailboxes. I don't feel strongly whether or not to address it now, although if SPF continues to be useful, sooner or later it's going to have to work with EAI addresses. R's, John From sm@elandsys.com Fri Jun 29 14:03:24 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 9302911E8096 for ; Fri, 29 Jun 2012 14:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3SR2wiis3uJ for ; Fri, 29 Jun 2012 14:03:20 -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 552C711E8073 for ; Fri, 29 Jun 2012 14:03:14 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.108]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5TL1c3j006683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 14:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341003716; bh=qWRfjkF44UlJrMocSDCzjeQXfrT6HBzgz5qMtwZ9sFw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BnFYQmcsZM1dg0ODPl2k/KOpp0/E4uYS4XpAFCr9zF1gOmlqAVtqOqks7oMJbNQ9W y2e66QogW46mJqLW4/94xXGiaYL4glSJruWmqxIg1EjIbMb8XjtHnPYWiBg3cLwo6B ZVKBwOrYhRRISFB/Xae6jQAanCgGtk97tzDG6Mds= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1341003716; i=@elandsys.com; bh=qWRfjkF44UlJrMocSDCzjeQXfrT6HBzgz5qMtwZ9sFw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RDmo0kjR176hMHJvFw64u77LNHyq4lbxmmT8qQjbTg1QGmJnd9KQBY8p936Ahf7TV 511efs4u5uXUiDYWy3lWl9ld11MBHSBdUQKsZwOAgmEsz5AQiXDXT5llNQokG/UV0C 6zMNbw8TCSiWrOHlw7LnIN/xq6tSOk3sIuRTvDN0= Message-Id: <6.2.5.6.2.20120629133820.09112d30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 29 Jun 2012 13:55:33 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <2561504.giPAs2JvIf@scott-latitude-e6320> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <2561504.giPAs2JvIf@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] Summary of open issues - #26 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 21:03:24 -0000 Hi Scott, At 12:52 29-06-2012, Scott Kitterman wrote: >#26 RFC 4408: Should the syntax checking of SPF records be relaxed at all > >This issue is still open in the tracker. IIRC the group agreed not to make >any changes due to this issue. I believe it should be closed without further >action. I only close a ticket if there is a message which documents the decision. There were comments from John Levine about this issue ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00814.html ) and from you ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00809.html ). I don't see any thread about Issue #26 in the SPFBIS archives. I don't have any justification to show if I am asked where the group agreed not to make any changes. Regards, S. Moonesamy From superuser@gmail.com Fri Jun 29 14:03:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4873011E8096 for ; Fri, 29 Jun 2012 14:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQetHJ9LulEC for ; Fri, 29 Jun 2012 14:03:41 -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 4AE9811E8073 for ; Fri, 29 Jun 2012 14:03:41 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5562306lbb.31 for ; Fri, 29 Jun 2012 14:03:40 -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=sn71Z0PiUetko0ld2eOUlJVS32PDtl3GU3zNBNZZReQ=; b=ijJE/+ftsPcNuEA/ROcRcr9t8RwI7rjU4qtaepYnZsphieQyRbl0PUOSBZQ3d4a6sV Z0svirqHuIf+rjFze/W3hSoCavDMSg6Cv3ALIJlWCRr3XyiJmiSfJ9/vtbPv2gCYFJ26 Ni+jM4mSP4Nk0xKxeDBjTJ1e+tWkslz+jtYKUyFtEiWNKEAAYVof8Lv8EoAH/cNoxzeu 9wHM85/XzgLxWh/j68f/60hiCwqba2yl5RZq36kn6u0JGjBrUfPqcij/zpIIK7jjn6mn VrjZIZPnudMTh4+Ix4F35HHl/KZLf0jBXwpjet5mjR2Z2TQUJR7ERTJXtWk6TT82mRq6 F3qA== MIME-Version: 1.0 Received: by 10.112.36.225 with SMTP id t1mr1958239lbj.67.1341003820209; Fri, 29 Jun 2012 14:03:40 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Fri, 29 Jun 2012 14:03:40 -0700 (PDT) In-Reply-To: <20120629202334.42090.qmail@joyce.lan> References: <1484112.CjeGCNgGfE@scott-latitude-e6320> <20120629202334.42090.qmail@joyce.lan> Date: Fri, 29 Jun 2012 14:03:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=e0cb4efe2f4c58979d04c3a2c802 Cc: spfbis@ietf.org, spf2@kitterman.com Subject: Re: [spfbis] Summary of open issues - #28 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 21:03:42 -0000 --e0cb4efe2f4c58979d04c3a2c802 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 29, 2012 at 1:23 PM, John Levine wrote: > For domains, there's the question of whether to allow UTF-8 domains, or to > require that all IDN domains be represented as A-lablels. For any of the > macro stuff that looks at mailboxes, whether to allow UTF-8 mailboxes. > > I don't feel strongly whether or not to address it now, although if > SPF continues to be useful, sooner or later it's going to have to work > with EAI addresses. > > I'm inclined to go with A-labels, which we did with DKIM. We should also consider any operational experience people have with SPF and IDN domains. Is any known? -MSK --e0cb4efe2f4c58979d04c3a2c802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 29, 2012 at 1:23 PM, John Levine <johnl@taugh.com> wrote:
For domains, there's the question of whether to allow UTF-8 domains, or= to
require that all IDN domains be represented as A-lablels. =A0For any of the=
macro stuff that looks at mailboxes, whether to allow UTF-8 mailboxes.

I don't feel strongly whether or not to address it now, although if
SPF continues to be useful, sooner or later it's going to have to work<= br> with EAI addresses.


I'm inclined to go with A-labels, which we di= d with DKIM.

We should also consider any operational experience peop= le have with SPF and IDN domains.=A0 Is any known?

-MSK

--e0cb4efe2f4c58979d04c3a2c802-- From superuser@gmail.com Fri Jun 29 14:06:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112B111E80A6 for ; Fri, 29 Jun 2012 14:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMehHPNSgQRG for ; Fri, 29 Jun 2012 14:06:37 -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 1594E11E80AD for ; Fri, 29 Jun 2012 14:06:36 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5564981lbb.31 for ; Fri, 29 Jun 2012 14:06:36 -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=T+u9lO4Eek+a8s2h+zmxoOR0QVAtWjjMJ2oyDQu2G/Q=; b=cYXSxCUNmx9j0OBaXOYrfqzGpNtYKDy+YXGBCc8zN0bp/a/w2ZYgA5M+aYy0FHi4Od uLi5eef2lZU07jAOW4127wir1e4/KT4nYnAcYc8iU2MkOQQJtBPf5muDvZDu9m+Oh/Jm 7zF6buBsfy+pPr0hdhblUmHOiAkhxcwmKh7ITUHtfb5/mjJ5XCj0rzP0nVnf6i3YBIk5 rVQHlYoGbC0QAf7aJ0VXeIOV1S6VKQrpjTLfe9k6n9x15IEioRjYH/H4J3CtKbcq5p4F 4xdlqSd4BsxdQnmgnAV+oCR7H52hrMm9L1NvD2TzNo7bjYebOZYOdssesttrirx7LfIj j0QQ== MIME-Version: 1.0 Received: by 10.152.112.138 with SMTP id iq10mr3538478lab.13.1341003996013; Fri, 29 Jun 2012 14:06:36 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Fri, 29 Jun 2012 14:06:35 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120629133820.09112d30@resistor.net> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <2561504.giPAs2JvIf@scott-latitude-e6320> <6.2.5.6.2.20120629133820.09112d30@resistor.net> Date: Fri, 29 Jun 2012 14:06:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d0408da07d3246104c3a2d2a9 Cc: spfbis@ietf.org, Andrew Sullivan , Scott Kitterman Subject: Re: [spfbis] Summary of open issues - #26 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 21:06:38 -0000 --f46d0408da07d3246104c3a2d2a9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 29, 2012 at 1:55 PM, S Moonesamy wrote: > > #26 RFC 4408: Should the syntax checking of SPF records be relaxed at >> all >> >> This issue is still open in the tracker. IIRC the group agreed not to >> make >> any changes due to this issue. I believe it should be closed without >> further >> action. >> > > At 12:52 29-06-2012, Scott Kitterman wrote: > I only close a ticket if there is a message which documents the decision. > There were comments from John Levine about this issue ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg00814.html ) and > from you ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg00809.html ). I > don't see any thread about Issue #26 in the SPFBIS archives. I don't have > any justification to show if I am asked where the group agreed not to make > any changes. > > I'm inclined to make no change. In fact, if this isn't a known pain point, I would even say that making the proposed change exceeds our charter. -MSK --f46d0408da07d3246104c3a2d2a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 29, 2012 at 1:55 PM, S Moonesamy <sm+ietf@elandsys.com= > wrote:

#26 =A0 =A0 RFC 4408: Should the syntax checking of SPF records be relaxed = at all

This issue is still open in the tracker. =A0IIRC the group agreed not to ma= ke
any changes due to this issue. =A0I believe it should be closed without fur= ther
action.

At 12:52 29-06-2012, Scott Kitterman wrote:
I only close a ticket if there is a message which documents the decision. = =A0There were comments from John Levine about this issue ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00814.html = ) and from you ( http://www.ietf.org/mail-archive/web/= spfbis/current/msg00809.html ). =A0I don't see any thread about Iss= ue #26 in the SPFBIS archives. =A0I don't have any justification to sho= w if I am asked where the group agreed not to make any changes.


I'm inclined to make no change.=A0 In fact, i= f this isn't a known pain point, I would even say that making the propo= sed change exceeds our charter.

-MSK

--f46d0408da07d3246104c3a2d2a9-- From spf2@kitterman.com Fri Jun 29 14:11:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DAB11E80B3 for ; Fri, 29 Jun 2012 14:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OP9TZ3MN7+U for ; Fri, 29 Jun 2012 14:11:50 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 65DB511E80A6 for ; Fri, 29 Jun 2012 14:11:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DBFF120E40E9; Fri, 29 Jun 2012 17:11:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341004308; bh=gyP/uGWtul8+PVLEJfAVvCB0bKXjRVjEnguhlC6We3g=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=EijZgkidxoPgQHE0mLuFqk+wur5qszewdl0WRzMt+Sv9HMddiNyuLmwUxiC6cf5CA mZeWNrLu0GBmV8F5ncgMPVlOTFvVA3WyJb4nie8ht/umk+7OIrMI7P9DX+5L86KU0M 43nIJyeLGkyVPAIXdI2THjf4T0OcuWWtf1tTlKhw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BC7A320E408E; Fri, 29 Jun 2012 17:11:48 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 17:11:48 -0400 Message-ID: <1499001.S9Rc5jekbH@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120629133820.09112d30@resistor.net> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <2561504.giPAs2JvIf@scott-latitude-e6320> <6.2.5.6.2.20120629133820.09112d30@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] Summary of open issues - #26 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 21:11:51 -0000 On Friday, June 29, 2012 01:55:33 PM S Moonesamy wrote: > Hi Scott, > > At 12:52 29-06-2012, Scott Kitterman wrote: > >#26 RFC 4408: Should the syntax checking of SPF records be relaxed at > >all > > > >This issue is still open in the tracker. IIRC the group agreed not to make > >any changes due to this issue. I believe it should be closed without > >further action. > > I only close a ticket if there is a message which documents the > decision. There were comments from John Levine about this issue ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg00814.html ) > and from you ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg00809.html > ). I don't see any thread about Issue #26 in the SPFBIS archives. I > don't have any justification to show if I am asked where the group > agreed not to make any changes. I think that's enough. I think it works the other way around. The charter is very clear that we are not doing a redesign here. I think absent some agreement to change, it stays as is. Given the issue got little comment and no traction, how do we get from a wait state to closed? Scott K From spf2@kitterman.com Fri Jun 29 14:13: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 DF43521F87EE for ; Fri, 29 Jun 2012 14:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLMOzX3WEUuB for ; Fri, 29 Jun 2012 14:13:03 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4821221F87B7 for ; Fri, 29 Jun 2012 14:13:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CD2A520E40E9; Fri, 29 Jun 2012 17:13:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341004382; bh=bzhzGV/qs/iRBlaQnieZG8uZaQUw/k2bEGCS22+aiE0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=AOq1v1kB3zRB84+Z7Hli0Q499wmua296bYRRPOCCnwmQWz9PNkgi71oofJpIoixTh OwAmgfr9wryZrJduU0K1ZtJOE77igepL878R+6rbKWFcbS3XZkI8HkMM7rmfOApKCP 5chsbWFdv66NOr2PZoBwDkQnEADiPh1t37LDwyxU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C06B220E408E; Fri, 29 Jun 2012 17:13:02 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 17:13:02 -0400 Message-ID: <2689728.3jPcjCXF9g@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <1484112.CjeGCNgGfE@scott-latitude-e6320> <20120629202334.42090.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of open issues - #28 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 21:13:04 -0000 On Friday, June 29, 2012 02:03:40 PM Murray S. Kucherawy wrote: > On Fri, Jun 29, 2012 at 1:23 PM, John Levine wrote: > > For domains, there's the question of whether to allow UTF-8 domains, or to > > require that all IDN domains be represented as A-lablels. For any of the > > macro stuff that looks at mailboxes, whether to allow UTF-8 mailboxes. > > > > I don't feel strongly whether or not to address it now, although if > > SPF continues to be useful, sooner or later it's going to have to work > > with EAI addresses. > > I'm inclined to go with A-labels, which we did with DKIM. > > We should also consider any operational experience people have with SPF and > IDN domains. Is any known? Not by me. Being consistent with DKIM sounds like a good starting point. Scott K From superuser@gmail.com Fri Jun 29 14:24:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B2F21F86CF for ; Fri, 29 Jun 2012 14:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBgmE9bn7K6P for ; Fri, 29 Jun 2012 14:24:15 -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 CD0BA21F8619 for ; Fri, 29 Jun 2012 14:24:14 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5584640lbb.31 for ; Fri, 29 Jun 2012 14:24:13 -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=D5DxT+K5jUmmX3yaXOXQjQru9qr8XLFBpV6bYXmwTqc=; b=YT4bWlxfeRihnU8oqFdeYi4cZVPmZkykt4MR89PAaNLbXS8lO3kC7U3PXOQ4JYRXIt pauUv7btpEsyKonTR0x53MeOur7MihnrRc4/0m9VCEUyTdBzr3XbIot/k5/0nd5AAP3t mfNb0aRQjhguNpZSz0pl3ycLyzu+kdgzKXnN7JEz1I//j/TAlQc7PDt/sTepjZPGx/sG jlj+jOFQKDzYxT8reGTxcwUkQ/4idpIAKhWhvpXlOZig8FBf9cV3KuYAf+sJdHOFLRKp aZ66792P2HRrT8Sf2bnB5/jOPeSjYW3YwK5Cta3k7CP7vkyVZi7qHq7Ze2po/0NNRmM+ mkXA== MIME-Version: 1.0 Received: by 10.152.104.47 with SMTP id gb15mr3466993lab.45.1341005053764; Fri, 29 Jun 2012 14:24:13 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Fri, 29 Jun 2012 14:24:13 -0700 (PDT) In-Reply-To: <1499001.S9Rc5jekbH@scott-latitude-e6320> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <2561504.giPAs2JvIf@scott-latitude-e6320> <6.2.5.6.2.20120629133820.09112d30@resistor.net> <1499001.S9Rc5jekbH@scott-latitude-e6320> Date: Fri, 29 Jun 2012 14:24:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0421824ddf22e504c3a311da Cc: spfbis@ietf.org Subject: Re: [spfbis] Summary of open issues - #26 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 21:24:16 -0000 --f46d0421824ddf22e504c3a311da Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 29, 2012 at 2:11 PM, Scott Kitterman wrote: > > I think that's enough. I think it works the other way around. The > charter is > very clear that we are not doing a redesign here. I think absent some > agreement to change, it stays as is. Given the issue got little comment > and > no traction, how do we get from a wait state to closed? > > > I agree. As I read the charter, the only way we could make this change is if it has already been made and widely deployed. Is there any evidence of this? If not, I think this one is dead as contrary to the charter. -MSK --f46d0421824ddf22e504c3a311da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 29, 2012 at 2:11 PM, Scott Kitterman <spf2@kitterman.com&= gt; wrote:

I think that's enough. =A0I think it works the other way around. = =A0The charter is
very clear that we are not doing a redesign here. =A0I think absent some agreement to change, it stays as is. =A0Given the issue got little comment = and
no traction, how do we get from a wait state to closed?



I agree.=A0 As I read the charter, the only way w= e could make this change is if it has already been made and widely deployed= .=A0 Is there any evidence of this?

If not, I think this one is dead= as contrary to the charter.

-MSK
--f46d0421824ddf22e504c3a311da-- From johnl@taugh.com Fri Jun 29 14:32:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B60821F86BA for ; Fri, 29 Jun 2012 14:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yAzsr1oaJjc for ; Fri, 29 Jun 2012 14:32:27 -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 A087421F856D for ; Fri, 29 Jun 2012 14:32:27 -0700 (PDT) Received: (qmail 67201 invoked from network); 29 Jun 2012 21:32:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1067f.4fee1ee9.k1206; bh=0DIKFKjiVyeXhHRwMDrGr/FjN+S6zpqeBITtjRr7vlc=; b=OCfyL3X6e3MWeCPSm13WYpQfAjmFpRQ2X0SYvedjDjHH79CpGz1EOx7me9Ue0mOJMWVBrGrCy/GCcmq8vPsnEJFIg7lTG41bSzvkA0QkHl/U6pgNpYYM0Lf1swpjutdEeS6msoEIkF5K7X7kIW4fMiKBlw71aYzAMcwWhUquFUo= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1067f.4fee1ee9.k1206; bh=0DIKFKjiVyeXhHRwMDrGr/FjN+S6zpqeBITtjRr7vlc=; b=wdTDuVQPB/zAJcUmrqVWpMcw74TnOoy7XPNuCzZq9U8SNx9XKcCR+D5xAWeQ6MQlC/acidDXnD0jkx4q1ji5veitYKoYORnjwhWU04vPeh+ctQ2o7ty/aKa5DaXJH81ahCU9nD/epI01phtVubKyxfFObsg6YDFk1GTXW7KqDN4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 29 Jun 2012 21:32:03 -0000 Date: 29 Jun 2012 17:32:25 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <1484112.CjeGCNgGfE@scott-latitude-e6320> <20120629202334.42090.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Summary of open issues - #28 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 21:32:28 -0000 >> I don't feel strongly whether or not to address it now, although if >> SPF continues to be useful, sooner or later it's going to have to work >> with EAI addresses. >> > I'm inclined to go with A-labels, which we did with DKIM. That's perfectly reasonable, but doesn't deal with the mailboxes. Since there's no ambiguity between UTF-8 and ASCII, allowing UTF-8 in mailbox fields should be strictly upward compatible. > We should also consider any operational experience people have with SPF and > IDN domains. Is any known? No, but I'd be surprised if anything odd happened, since until people start deploying EAI, all of the domains in mail envelopes have to be A-labels which don't present any new challenges to SPF code. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From sm@elandsys.com Fri Jun 29 15:07:01 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 AA5CF21F864E for ; Fri, 29 Jun 2012 15:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPH1C8nCo5VS for ; Fri, 29 Jun 2012 15:06:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CA821F8633 for ; Fri, 29 Jun 2012 15:06:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.108]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5TM5Ndj022802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 15:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341007539; bh=55fiHfg2G9mtWnEdCU2QlA3HJMrNgBhMSwakvInV66E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=09dA6uAB5yx8pI8qPHVwmcS7luFhmewsVGYT15QF7BdjTFoj7Frv2f60xZ8O0Is96 /CIyH4O6oqjgUIDXlkqgabHN0PrwIMQaVZnXO4D46nRiP+xNkPZ2JDquMne+YD/+GQ RGzjgTXyqTmFo+RtT/LEQPKm2+QELr6B4FDBjBsE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1341007539; i=@elandsys.com; bh=55fiHfg2G9mtWnEdCU2QlA3HJMrNgBhMSwakvInV66E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jvs3Ql/jGoTooema2NlaFTeA4LbiHLE6S71vMR/laTlgTixtfHUeQDW0S0kJcb8Rh yh29iZ30enDfwyZ6r2J34G0JNQP/ROK6MqIaIGFeODTgstDY/GjH07VLLK+/XWbkmK 8R6P0DEeufoW+B804GAkHFKPQIYgyoLTlYXYSC38= Message-Id: <6.2.5.6.2.20120629141459.0a01ddb8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 29 Jun 2012 14:28:55 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1499001.S9Rc5jekbH@scott-latitude-e6320> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <2561504.giPAs2JvIf@scott-latitude-e6320> <6.2.5.6.2.20120629133820.09112d30@resistor.net> <1499001.S9Rc5jekbH@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Andrew Sullivan Subject: Re: [spfbis] Summary of open issues - #26 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 22:07:01 -0000 In a message dated March 7, Andrew Sullivan commented on the issue ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00812.html ) : "I don't know what the ADs will say about it, but the chairs have been clear that we will not rule out of scope issues that come up and that meet the charter. A technical issue is a technical issue, and we'll deal with them as long as they're on-charter. There may, of course, also be issues that would not be on charter, but that could be the basis for future work." Issue #26 was not opened for comments while the working group was discussing about the issues. Even if an issue got little comment or no traction, it will only be closed once the working group has been given the opportunity to comment. Once a conclusion has been reached, the ticket is closed. Regards, S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Fri Jun 29 15:10:50 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 56E7A21F86A5 for ; Fri, 29 Jun 2012 15:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.301 X-Spam-Level: X-Spam-Status: No, score=-102.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KucbJhsIpbW8 for ; Fri, 29 Jun 2012 15:10:44 -0700 (PDT) Received: from winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1FF21F86A4 for ; Fri, 29 Jun 2012 15:10:43 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2120; t=1341007842; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=LBXMjjbR/C5q51/DwL1eCKYiK8I=; b=PmB3T4gt9bHJaI0BmBil KEfRFkoF8P3qXe6s8gR+dP+dUjUmkXLkNIEe2GcVl8q557LvxJkW/tZzrGMR2yIT H/+3sS5kykEGv2PMb1CxVT4eQG/w1wHaVMhrJEWYlXUy4zuNsZTE3w8LPpk2UzYh HJsqw7XmIcCzpN8Efa11U5A= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 29 Jun 2012 18:10:42 -0400 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 hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1324659643.3609.3040; Fri, 29 Jun 2012 18:10:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2120; t=1341007742; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=LE4kYoS 0GvbbZT6jbU9v/EF8OVe0tyR4Twb1nPqRgnI=; b=aztmTMjDMV2JA9V7lPvUm+5 SJm+In05JdW4Lfk2w1RAjZaDL4OO9R1Q7Pg6aHEKvA4q5fezncI/LtystW6YCBiE WuKfqVzsrQgBAGNo/EmrItDFA+3ZIVHAGvlleuOuNArjU0WmBE7YsXUE2hDDpa7m qzFq+VdF1Rg4MM3pmJJ8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 29 Jun 2012 18:09:02 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1923507582.9.5400; Fri, 29 Jun 2012 18:09:01 -0400 Message-ID: <4FEE27FE.4030903@isdg.net> Date: Fri, 29 Jun 2012 18:11:10 -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: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> In-Reply-To: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Summary of open issues X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 22:10:50 -0000 Was security issue #29 also resolved? Closed without discussion? -- HLS S Moonesamy wrote: > Hello, > > Here's a summary of the open issues. > > Issue #15 is about Section 2.2 of RFC 4408. Scott Kitterman > made a text change ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01626.html ). > Alessandro Vesely commented on it ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01629.html ). > > Issue #16 has been marked resolved ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01617.html ). > > Issue #20 has been marked as resolved ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01618.html ). > > Issue #8 has been marked as resolved ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01619.html ) > > Issue #19 has been marked as resolved ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01620.html ). > > Issue #18 is about Section 2.5.6. "DSN code" has been changed to > "extended status code The reference was also changed. I'll leave this > one open in the tracker as there has ony been two comments ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01692.html ). > > Issue #3 (erratum #99) is a typo in the IESG Note. I am marking this > issue as resolved. > > Issue #23 is about typos in the draft. The fix is in -00. I am marking > the issue as resolved. > > Issue #1 is about Section 2.5.6. Issue #18 is also about that > subsection. There were only two comments and a text change was proposed > ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01633.html ). > I'll leave this open. > > Issue #7 is about downcasing result names. Murray Kucherawy commented > on this ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01639.html ). > Barry Leiba mentioned that mixed-case invited confusion ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg01649.html ). > I'll leave this issue open. > > Regards, > S. Moonesamy > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From spf2@kitterman.com Fri Jun 29 15:11: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 3299921F86A5 for ; Fri, 29 Jun 2012 15:11: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmOFg7GN7zFp for ; Fri, 29 Jun 2012 15:11:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1E621F86A7 for ; Fri, 29 Jun 2012 15:11:00 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AD05A20E40E9; Fri, 29 Jun 2012 18:10:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341007859; bh=tO9OFx4Cbi+HkJZwKDeueKsM5OFSZqVe6N3eP79FRkU=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=ipwtZdoe5xz2vB7RxQwiqqYTM6gzAdQBoUpMLJmNCBu0H3RFmJcxX8pzC+sr5A0Y7 AslEFwn+JeYOIJl21uAozK1FrUgAlB7fayWIvRE5LZ7A2xo3WJoPyZg/J9qmQWqUbc bN9ENx0Qv5xlC4XbuPAzuK+LvSu+Jntxr+3mToIY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A001C20E408E; Fri, 29 Jun 2012 18:10:59 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 18:10:59 -0400 Message-ID: <1753008.jfhW4KDlhY@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120629141459.0a01ddb8@resistor.net> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <1499001.S9Rc5jekbH@scott-latitude-e6320> <6.2.5.6.2.20120629141459.0a01ddb8@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] Summary of open issues - #26 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 22:11:06 -0000 On Friday, June 29, 2012 02:28:55 PM S Moonesamy wrote: > In a message dated March 7, Andrew Sullivan commented on the issue ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg00812.html ) : > > "I don't know what the ADs will say about it, but the chairs have been > clear that we will not rule out of scope issues that come up and that > meet the charter. A technical issue is a technical issue, and we'll > deal with them as long as they're on-charter. There may, of course, > also be issues that would not be on charter, but that could be the > basis for future work." > > Issue #26 was not opened for comments while the working group was > discussing about the issues. Even if an issue got little comment or > no traction, it will only be closed once the working group has been > given the opportunity to comment. Once a conclusion has been > reached, the ticket is closed. It's out of scope. Please close. Scott K From spf2@kitterman.com Fri Jun 29 15:12:33 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 DCA8421F86AA for ; Fri, 29 Jun 2012 15:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIkb3VL6MueG for ; Fri, 29 Jun 2012 15:12:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE4C21F86A5 for ; Fri, 29 Jun 2012 15:12:31 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B7AFE20E40E9; Fri, 29 Jun 2012 18:12:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341007950; bh=XY3U7nhAW2UWreep8X+G3rxheVyZ6QHZz/8UpS9htME=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=AAqpsJzRUSrIYnRjGP+fOMYYJ4STVM5E//W51an9m1UmgGd7ju3DqpiYCi1AjNhBn SW7LVqkKn3WfBFmGOf7r+8XUWfZhD4iWI9VkYPUbtw02LVQV06a/W2PRf594O0/GHk UiBPyK+FUGF5owhzZsCNPK9IcBSuzKdveRXxLPCY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id AAB0220E408E; Fri, 29 Jun 2012 18:12:30 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 29 Jun 2012 18:12:30 -0400 Message-ID: <4259513.k6fnLEn2TJ@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FEE27FE.4030903@isdg.net> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <4FEE27FE.4030903@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Summary of open issues X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 22:12:34 -0000 On Friday, June 29, 2012 06:11:10 PM Hector Santos wrote: > Was security issue #29 also resolved? Closed without discussion? > It's not a security issue, but it's still open in the tracker. The tracker is self service: http://trac.tools.ietf.org/wg/spfbis/trac/report/1 Scott K From superuser@gmail.com Fri Jun 29 15:35:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68EE11E8099 for ; Fri, 29 Jun 2012 15:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4eVmY2sYhVV for ; Fri, 29 Jun 2012 15:35:20 -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 E92AA11E8079 for ; Fri, 29 Jun 2012 15:35:19 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5656192lbb.31 for ; Fri, 29 Jun 2012 15:35:19 -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=yzVVvOWCF+34cynBZkNuTlt9OlF+RhYysyo+Bhl8L5g=; b=InHCoMoGkw6jZ9sTnlyN5Ji3ugQxLeIT5RaFdCUBDTIR1OMGD8zwHpSDjP2a1jbjUd DcD2cxowDLYgYEnHWABsPDn8z0sGUjFFtKpfQIOpLLOwQHMck/LHowAGJngjWeem+EM4 xFrJok/LkcFbkdvSdU4NRrZgmQG7MHTJaqUXhL95G/sO86wmRzqCep+2sdsbb6BW7hya /tFgPt+px2t/OWBWKVqVxv+rOy8Fy74qdC5T3fT3WIQtNXJTKIofRrPHv8WG2c81+OAd QKbcd5odRA/63qiaXTYuPBypPn15IYvp28ELYI88uwfCYC88htzPLrgaFYMrRnjg3doo Hetg== MIME-Version: 1.0 Received: by 10.152.124.180 with SMTP id mj20mr3172028lab.43.1341009318948; Fri, 29 Jun 2012 15:35:18 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Fri, 29 Jun 2012 15:35:18 -0700 (PDT) In-Reply-To: <4259513.k6fnLEn2TJ@scott-latitude-e6320> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <4FEE27FE.4030903@isdg.net> <4259513.k6fnLEn2TJ@scott-latitude-e6320> Date: Fri, 29 Jun 2012 15:35:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d0434bfde18aede04c3a41019 Cc: spfbis@ietf.org Subject: Re: [spfbis] Summary of open issues X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 29 Jun 2012 22:35:20 -0000 --f46d0434bfde18aede04c3a41019 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 29, 2012 at 3:12 PM, Scott Kitterman wrote: > On Friday, June 29, 2012 06:11:10 PM Hector Santos wrote: > > Was security issue #29 also resolved? Closed without discussion? > > > > It's not a security issue, but it's still open in the tracker. The > tracker is > self service: > > http://trac.tools.ietf.org/wg/spfbis/trac/report/1 > > Item #29 is tagged to be about the experiment document. This is possibly an error, because the experiment document doesn't touch on this topic. If it's not an error, the experiment document is now in the RFC Editor queue having not dealt with the matter, so I imagine it should be closed. On the other hand, if the chairs have ruled it as off-charter (inasmuch as there was no evidence presented supporting it as being on-charter since that posting in April), it should be closed for that reason. -MSK --f46d0434bfde18aede04c3a41019 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 29, 2012 at 3:12 PM, Scott Kitterman <spf2@kitterman.com&= gt; wrote:
On Friday, June 29, 2012 06:11:10 PM Hector Santos wrote:=
> Was security issue #29 also resolved? Closed without discussion?
>

It's not a security issue, but it's still open in the tracker= . =A0The tracker is
self service:

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


Item #29 is tagged to be about the experiment doc= ument.=A0 This is possibly an error, because the experiment document doesn&= #39;t touch on this topic.=A0 If it's not an error, the experiment docu= ment is now in the RFC Editor queue having not dealt with the matter, so I = imagine it should be closed.

On the other hand, if the chairs have ruled it as off-charter (inasmuch= as there was no evidence presented supporting it as being on-charter since= that posting in April), it should be closed for that reason.

-MSK
--f46d0434bfde18aede04c3a41019-- From hsantos@isdg.net Fri Jun 29 17:04: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 A9B7711E8072 for ; Fri, 29 Jun 2012 17:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnJtHADb8a8X for ; Fri, 29 Jun 2012 17:04:52 -0700 (PDT) Received: from news.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A088311E8085 for ; Fri, 29 Jun 2012 17:04:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=731; t=1341014677; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=eqKUsRlPFF3YuzYHjm1eBP/4H4U=; b=hzOgT4RUzPinVqe/PgId 1EiLS+CABpMPFQ0MwR6kNy1mt6RgUxBp7Z5SOFVpU1pEwtM/zgto7RjFcJJcplNJ 2/yeueUle0BZ49AEV71Z86tV/AdL3z3mksBmKQEqc+mYlPPukVm6NvyPsvHNX846 rvwtc2ZUzu4XiV2rL8HdDpE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 29 Jun 2012 20:04:37 -0400 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 1331494609.3609.2172; Fri, 29 Jun 2012 20:04:37 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=731; t=1341014580; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=NlOe9Ft MGKvyK2w8jquRupxnO/SBp2wCVAhrCo6H9mc=; b=jWJCWTUtcdcFg9CRdjE2MK0 38FlXJXJZ1PP+JZOkS1LI0P1n6jh+4GyE2zQfv5VQyEPcVg/OBvy+GTPg16mo8Fj tFkUM7owWc2Bqn7SapxdJIvgiq96zTsyQW8U3Xj9PlVYYHq/LbxbfK1AXc3R+OOb 4Zlt+qETrja+Bt8kSLco= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 29 Jun 2012 20:02:59 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1930344957.9.6676; Fri, 29 Jun 2012 20:02:58 -0400 Message-ID: <4FEE42B0.9080504@isdg.net> Date: Fri, 29 Jun 2012 20:05:04 -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: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <4FEE27FE.4030903@isdg.net> <4259513.k6fnLEn2TJ@scott-latitude-e6320> In-Reply-To: <4259513.k6fnLEn2TJ@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Summary of open issues X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Jun 2012 00:04:53 -0000 Its a security issue if the two possible outcomes are different and one is worst than the other, one that is directly related to security considerations. Think about it or read the postings I made in the past I have no desire to repeat. Scott Kitterman wrote: > On Friday, June 29, 2012 06:11:10 PM Hector Santos wrote: >> Was security issue #29 also resolved? Closed without discussion? >> > > It's not a security issue, but it's still open in the tracker. The tracker is > self service: > > http://trac.tools.ietf.org/wg/spfbis/trac/report/1 > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From vesely@tana.it Sat Jun 30 03:24: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 952B021F854A for ; Sat, 30 Jun 2012 03:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.558 X-Spam-Level: X-Spam-Status: No, score=-4.558 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7nAYPqljG0U for ; Sat, 30 Jun 2012 03:24:52 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDE621F852A for ; Sat, 30 Jun 2012 03:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1341051891; bh=zKMexxErV/Y/BX6R5v2RGqKHd2OZQo1XYZVDYbf4YkU=; l=1754; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=SLcnqOtbZauUhkqqTUE67r4bB+Nszt1qtDQMdkFvRiqsLEgBcy64egKNOCqcMwlWN PUJpHr/D0LprDBScU7KmDvmdpGOE56I3JOrxIgR+wStlQpskcI8TfemjP/eppvzrzz lyle4HHEw1eOXS77N6Agvewh1U231or7Qjs/Aq3w= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 30 Jun 2012 12:24:51 +0200 id 00000000005DC042.000000004FEED3F3.00005CFB Message-ID: <4FEED3F3.7020900@tana.it> Date: Sat, 30 Jun 2012 12:24:51 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <4F4D31E9.2000601@dcrocker.net> <6.2.5.6.2.20120629092333.08feed68@resistor.net> <1390536.tGbELFoml6@scott-latitude-e6320> In-Reply-To: <1390536.tGbELFoml6@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Jun 2012 10:24:53 -0000 On Fri 29/Jun/2012 20:11:10 +0200 Scott Kitterman wrote: > > Yesterday I prepared a proposed change for this issue, and #25: RFC 4408: > Section 4.4 Parallel Query, that'll be in the -02 I plan to post today (since > msk promised to read the draft over the weekend). For parallel query, I think > it's essentially OBE since we aren't going to recommend doing lookups for both > types. -02: An SPF-compliant domain name MUST have SPF records of type TXT. An SPF-compliant domain name MUST NOT publish only records of type SPF. If a domain has records of both types, they MUST have identical content. I'd strike the second sentence, which merely repeats the first. As this is a change, it might be worth to anticipate the lookup change from 4.4 instead, so as to convey the change more compactly: NEW An SPF-compliant domain name MUST have SPF records of type TXT, and MAY have SPF records of type SPF. If a domain has records of both types, they SHOULD have identical content. However, SPF-compliant verifiers SHOULD query SPF records of type TXT only. As for Section 4.4, I don't think it makes sense to specify non-recommended behavior. Let me try some minor tweaks as well: -02: In accordance with how the records are published (see Section 3.1 above), a DNS query needs to be made for the name, querying for type TXT. SPF Version 1 queries for records of type SPF SHOULD NOT be done. If both SPF and TXT RRs are looked up, the queries MAY be done in parallel. NEW In accordance with how the records are published (see Section 3.1 above), a DNS query needs to be made for the domain name, querying for type TXT. SPF queries for SPF records of type SPF SHOULD NOT be done any more. From vesely@tana.it Sat Jun 30 03:35:01 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 30A2421F8607 for ; Sat, 30 Jun 2012 03:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.568 X-Spam-Level: X-Spam-Status: No, score=-4.568 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXgu1BfsFPns for ; Sat, 30 Jun 2012 03:35:00 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 54A3721F84B6 for ; Sat, 30 Jun 2012 03:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1341052499; bh=xs970Wx/C0sr+u9TaV4zsO2+VRLGDV37r7eX3CziWQI=; l=947; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=dvd5d27lWlmERzJPTKPgnaCK7Xwg1IWw47rHF5AdsfsKjR1phgfXhOAdeG74s5Jry qbEWivB47cEMtDrZR1tQR7Obimj+c+81xNzPeTYeEhOomYj4BmjaoE/NQN3PyqXkiM IFth0CXgTFmBOaX974BtEgsnAEWc6OwC+KPdkNMg= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 30 Jun 2012 12:34:59 +0200 id 00000000005DC039.000000004FEED653.00005F2D Message-ID: <4FEED653.1050908@tana.it> Date: Sat, 30 Jun 2012 12:34:59 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120628200220.21961.43683.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120628132227.0ce4a398@elandnews.com> In-Reply-To: <6.2.5.6.2.20120628132227.0ce4a398@elandnews.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] spfbis - Requested session has been scheduled for IETF 84 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Jun 2012 10:35:01 -0000 On Thu 28/Jun/2012 22:28:37 +0200 S Moonesamy wrote: > > The WG session at IETF 84 is scheduled as follows: > > spfbis Session 1 (0:30:00) > Tuesday, Afternoon Session III 1700-1830 > Room Name: Georgia A An interesting way to entertain ourselves would be to define a list of pros and cons of adopting SPF, from a mail admin perspective. The results of that may support an evolutionary game-theoretical modeling of SPF. The latter, for example, might describe how a mail admin population moves across strategies that involve strict record (-all), strict behavior (reject-on-fail), and their loose counterparts. Acquiring a better insight on such dynamics may help getting rid of the need to protect outdated beliefs. > Please note that the WG Chairs would prefer not to have a session > unless there are substantive issues which require face-to-face > discussion. Does that reflect some sort of team-building technique? From ajs@anvilwalrusden.com Sat Jun 30 04:48:24 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 3D42521F8622 for ; Sat, 30 Jun 2012 04:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlEfXvJA-mil for ; Sat, 30 Jun 2012 04:48:23 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB9221F857F for ; Sat, 30 Jun 2012 04:48:22 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 77E828A032 for ; Sat, 30 Jun 2012 11:48:20 +0000 (UTC) Date: Sat, 30 Jun 2012 07:48:23 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120630114822.GC69385@mail.yitter.info> References: <20120628200220.21961.43683.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120628132227.0ce4a398@elandnews.com> <4FEED653.1050908@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FEED653.1050908@tana.it> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] spfbis - Requested session has been scheduled for IETF 84 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Jun 2012 11:48:24 -0000 On Sat, Jun 30, 2012 at 12:34:59PM +0200, Alessandro Vesely wrote: > > An interesting way to entertain ourselves would be to define a list of > pros and cons of adopting SPF, from a mail admin perspective. The > results of that may support an evolutionary game-theoretical modeling > of SPF. The latter, for example, might describe how a mail admin > population moves across strategies that involve strict record (-all), > strict behavior (reject-on-fail), and their loose counterparts. > > Acquiring a better insight on such dynamics may help getting rid of > the need to protect outdated beliefs. Are you planning to submit a draft along these lines? > > Please note that the WG Chairs would prefer not to have a session > > unless there are substantive issues which require face-to-face > > discussion. > > Does that reflect some sort of team-building technique? No. It reflects a view that the point of having a meeting is to solve controversies that can be more effectively nailed down in the sort of back and forth one can do in person. I don't like having meetings for the sake of them or just because we have a slot. As it is, we asked for 30 minutes but got more time. If we don't actually need that time, then it is better to cede it back to the IETF for other use. Remember, the IETF's work happens on the mailing lists anyway -- anything we do in a meeting is required to be confirmed here. But if there remain controversies that are most easily aired in a meeting, it will be useful to have a session. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Sat Jun 30 08:22: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 9E23E21F84AE for ; Sat, 30 Jun 2012 08:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.065 X-Spam-Level: X-Spam-Status: No, score=-111.065 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLBnhoBeTWJL for ; Sat, 30 Jun 2012 08:22:46 -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 C8F2E21F8484 for ; Sat, 30 Jun 2012 08:22:45 -0700 (PDT) Received: (qmail 60785 invoked from network); 30 Jun 2012 15:22:44 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Jun 2012 15:22:44 -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=4fef19c4.xn--30v786c.k1206; i=johnl@user.iecc.com; bh=1PPFtb75lsv0havmgp17bdGTdd0GmBRsapVdURrxEC8=; b=duMtP8+FSrmjoobbQfY98zCoUsNk1D4TpmRdMYyQNwp+zUje2+xEMtzg7LcHiQ5icZQGWmT5CoMKQulJjl45cl++fduFj8Mr70sFe7Gxf5RFZ4Xynmu4mqfdAYAyIjViRRSR22QeujT29jZ72MtUYcJ2wb02TafBjewU5rjTUTw= 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=4fef19c4.xn--30v786c.k1206; olt=johnl@user.iecc.com; bh=1PPFtb75lsv0havmgp17bdGTdd0GmBRsapVdURrxEC8=; b=pIp1dEzKesGBlMQLa9XWG6HKlqLcnFsWhYgdprMlMT5Z7DO+zP06yMetT8rDmis4y2aivZz5i1VTPngeY5IHgRmzla9timDxLpjWIkRS+YUlH1H5/2j43UFZQ1QMlRde+XFNsl+MLoFlVDwYN10PYxW/oyHzifTYs4tB+AQUIRo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 30 Jun 2012 15:22:22 -0000 Message-ID: <20120630152222.15891.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <4FEED653.1050908@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [spfbis] spfbis - Requested session has been scheduled for IETF 84 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Jun 2012 15:22:46 -0000 >An interesting way to entertain ourselves would be to define a list of >pros and cons of adopting SPF, from a mail admin perspective. If you're buying the beer, we'll be happy to meet in the bar in the evening. But not in a precious WG meeting slot. R's, John From sm@elandsys.com Sat Jun 30 13:21:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC30321F85F3 for ; Sat, 30 Jun 2012 13:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgzApEw1fB2l for ; Sat, 30 Jun 2012 13:21:15 -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 80DAB21F85D1 for ; Sat, 30 Jun 2012 13:21:15 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.108]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5UKL3PD027516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 30 Jun 2012 13:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341087674; bh=VfjCPijNn6SaDrI2YYWnWkuJPVO84e4EmwAeXnGZ9vg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=UOghsfjEaso6RFwIaC5/c/kr8TJ/Wkggs9bkZycRe3u1Oe9j0X1YzZaC4lKzOYQd1 BZqXuOsbadsrODzDuMg50Hv0GNOl0eJ0KG/LgVb67/LG5jLhaBsPfrj0Soc82te5nn nq/8qH2ZFMJOBqXEBxYG4HCr0uYaHXPQ5rqe3vhc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1341087674; i=@elandsys.com; bh=VfjCPijNn6SaDrI2YYWnWkuJPVO84e4EmwAeXnGZ9vg=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=kYMpyq6evD7HWrvauzLprNfFQsg5AI/VDbP4oD2iIsm1NCrXHkGJOgE6Af3/TowNi nEM6gRs4bwLdglsRhxNAK4pedf3nppLdWVv3qYWPNBnKVsbaTsej+zXOr+oqe7FNyu V49W6DQEDIptv9bg7emz8LvwDf3/6qm8f6XDVncw= Message-Id: <6.2.5.6.2.20120630130901.09009640@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 30 Jun 2012 13:11:22 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <3265116.sr2OGvJaSX@scott-latitude-e6320> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <3265116.sr2OGvJaSX@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Summary of open issues - #17 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Jun 2012 20:21:18 -0000 At 12:46 29-06-2012, Scott Kitterman wrote: >On Friday, June 29, 2012 09:12:43 AM S Moonesamy wrote: > > Hello, > > > > Here's a summary of the open issues. > >#17 RFC 4408: Section 8.1 Undefined "uric" set > >This is still open in the tracker, but was fixed in a pre-WG draft. I'll close this ticket (see http://www.ietf.org/mail-archive/web/spfbis/current/msg00476.html ). Regards, S. Moonesamy From sm@elandsys.com Sat Jun 30 13:21:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F68921F85D1 for ; Sat, 30 Jun 2012 13:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktzKUYgS7mp7 for ; Sat, 30 Jun 2012 13:21:17 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A398B21F85F0 for ; Sat, 30 Jun 2012 13:21:17 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.108]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5UKL3PF027516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 30 Jun 2012 13:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341087678; bh=1UDLq+52HXUexqDSm+1pG5kX0cpcl29UP5ejl0k2g5s=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=M9v2Ycxi1tXsN4lMr2WENWqf/PPexZ/Lcn6ZAAU42s0zJAfn7S5sfgbYzpN4OjSOQ KblmU09pOeSTL3NcoiHsiyGISuNsr+S4HykZvYvBCl0T9XsqmacRJtHJWoq8mGHXil E4q68jhs8ZGShJ0QWEHbS1fcNqNBPz8+eJTefQyo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1341087678; i=@elandsys.com; bh=1UDLq+52HXUexqDSm+1pG5kX0cpcl29UP5ejl0k2g5s=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=SESMN8T4Onk66gs3fAn4Lxhd1R9VXWAW3TtB7UXOC9vhD2DQftqU5Xv8byFlF382m RvoxUWMupj4m9+s+5yt8WtNDU1urkp1gD4W5Xu2me9iF7SE5XSV62Uyu4wpRrMauxQ ZpQCSZfTOnS9NbamCVwLY09jFbZGA7TiOyJlPdT8= Message-Id: <6.2.5.6.2.20120630131329.090098d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 30 Jun 2012 13:14:04 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <16158960.J7X6fhadlP@scott-latitude-e6320> References: <6.2.5.6.2.20120629082934.0a326568@elandnews.com> <16158960.J7X6fhadlP@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Summary of open issues - #2 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Jun 2012 20:21:22 -0000 At 12:45 29-06-2012, Scott Kitterman wrote: >On Friday, June 29, 2012 09:12:43 AM S Moonesamy wrote: > > Hello, > > > > Here's a summary of the open issues. > >#2 RFC 4408 Section B.3 - Errata #2250 > >This issue is still open in the tracker, but it was fixed in one of >the pre-WG >drafts. I closed the ticket. Regards, S. Moonesamy From spf2@kitterman.com Sat Jun 30 16:26:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3910C21F84D2 for ; Sat, 30 Jun 2012 16:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK6mJmKw-0fF for ; Sat, 30 Jun 2012 16:26:18 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 64E5D21F8534 for ; Sat, 30 Jun 2012 16:26:18 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 2D12ED04091; Sat, 30 Jun 2012 18:26:19 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341098779; bh=qGP0fPhQ4bxNKLAyqtLEe4UCOO3667GvRABXsL4q0SA=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=U56QkfgWGxoFneVCISzDda4z9iu31VBOzq7GpjfvrAH1zutJXrWq7zjQHb27AaWqk dY8CWPqgjXb2gZ7qO1UJqQpbQerFy9IpD+cpYO6ND3eGBFifuPZAj9clSPfPGR03IU 5TKbt/TM/iA4IncnbHHIgX5cgONJpVC7hpB0VSDA= Received: from scott-latitude-e6320.localnet (unknown [208.253.106.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id BB4D1D0405C; Sat, 30 Jun 2012 18:26:18 -0500 (CDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 30 Jun 2012 19:26:17 -0400 Message-ID: <2028173.23DeCXx7cE@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FEED3F3.7020900@tana.it> References: <20120222193641.73783.qmail@joyce.lan> <1390536.tGbELFoml6@scott-latitude-e6320> <4FEED3F3.7020900@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 30 Jun 2012 23:26:19 -0000 On Saturday, June 30, 2012 12:24:51 PM Alessandro Vesely wrote: > On Fri 29/Jun/2012 20:11:10 +0200 Scott Kitterman wrote: > > Yesterday I prepared a proposed change for this issue, and #25: RFC 4408: > > Section 4.4 Parallel Query, that'll be in the -02 I plan to post today > > (since msk promised to read the draft over the weekend). For parallel > > query, I think it's essentially OBE since we aren't going to recommend > > doing lookups for both types. > > -02: > An SPF-compliant domain name MUST have SPF records of type TXT. An > SPF-compliant domain name MUST NOT publish only records of type SPF. > If a domain has records of both types, they MUST have identical > content. > > I'd strike the second sentence, which merely repeats the first. As > this is a change, it might be worth to anticipate the lookup change > from 4.4 instead, so as to convey the change more compactly: > > NEW > An SPF-compliant domain name MUST have SPF records of type TXT, and > MAY have SPF records of type SPF. If a domain has records of both > types, they SHOULD have identical content. However, SPF-compliant > verifiers SHOULD query SPF records of type TXT only. I agree that "MUST NOT publish only records of type SPF" is technically redundant, but I left it in because, since this is a change, I wanted to be clear about it (my feeling is that 4408, in the name of getting approved, somewhat disingenuously encouraged type SPF publication). "If a domain has records of both types, they MUST have identical content." is verbatim from RFC 4408 so it should be kept unchanged if we mention the topic at all. Since we are ending the attempt to transition to Type SPF, I think MAY publish is far too encouraging. How about: An SPF-compliant domain name MUST have SPF records of type TXT. It SHOULD NOT have SPF records of type SPF, but if a domain has records of both types, they MUST have identical content. SPF-compliant verifiers SHOULD query SPF records of type TXT only. > As for Section 4.4, I don't think it makes sense to specify > non-recommended behavior. Let me try some minor tweaks as well: > > -02: > In accordance with how the records are published (see Section 3.1 > above), a DNS query needs to be made for the name, querying > for type TXT. SPF Version 1 queries for records of type SPF SHOULD > NOT be done. If both SPF and TXT RRs are looked up, the queries MAY > be done in parallel. > > NEW > In accordance with how the records are published (see Section 3.1 > above), a DNS query needs to be made for the domain name, querying > for type TXT. SPF queries for SPF records of type SPF SHOULD NOT be > done any more. I'm fine with that, but I'd stop at done (remove any more). Other opinions? Scott K From WebMaster@Commerco.Net Sat Jun 30 17:07:09 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 BF0EF21F84EA for ; Sat, 30 Jun 2012 17:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUx92d8tyNGz for ; Sat, 30 Jun 2012 17:07:08 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6157B21F8508 for ; Sat, 30 Jun 2012 17:07:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=ksf/l4ViWJfJd3ZsGXWNUy+uObtM8kJt0wpIBw6L4L40pGYOvtdzetoZAtrAfWSVEuHChYDBUXuh0/WuZYOO47g1c7KdxXCK/Qrd2XRD0XxwQJlF1FvwUup8JOnONJYvLarsQahD+ZpOULYWWKqXRp8xSu5sNw8m/3EbEWl2xWE= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Sun, 01 Jul 2012 00:07:04 +0000 Message-ID: <4FEF94A1.8030406@Commerco.Net> Date: Sat, 30 Jun 2012 18:06:57 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <1390536.tGbELFoml6@scott-latitude-e6320> <4FEED3F3.7020900@tana.it> <2028173.23DeCXx7cE@scott-latitude-e6320> In-Reply-To: <2028173.23DeCXx7cE@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Jul 2012 00:07:10 -0000 On 6/30/2012 5:26 PM, Scott Kitterman wrote: > On Saturday, June 30, 2012 12:24:51 PM Alessandro Vesely wrote: >> On Fri 29/Jun/2012 20:11:10 +0200 Scott Kitterman wrote: >>> Yesterday I prepared a proposed change for this issue, and #25: RFC 4408: >>> Section 4.4 Parallel Query, that'll be in the -02 I plan to post today >>> (since msk promised to read the draft over the weekend). For parallel >>> query, I think it's essentially OBE since we aren't going to recommend >>> doing lookups for both types. >> >> -02: >> An SPF-compliant domain name MUST have SPF records of type TXT. An >> SPF-compliant domain name MUST NOT publish only records of type SPF. >> If a domain has records of both types, they MUST have identical >> content. >> >> I'd strike the second sentence, which merely repeats the first. As >> this is a change, it might be worth to anticipate the lookup change >> from 4.4 instead, so as to convey the change more compactly: >> >> NEW >> An SPF-compliant domain name MUST have SPF records of type TXT, and >> MAY have SPF records of type SPF. If a domain has records of both >> types, they SHOULD have identical content. However, SPF-compliant >> verifiers SHOULD query SPF records of type TXT only. > > I agree that "MUST NOT publish only records of type SPF" is technically > redundant, but I left it in because, since this is a change, I wanted to be > clear about it (my feeling is that 4408, in the name of getting approved, > somewhat disingenuously encouraged type SPF publication). > > "If a domain has records of both types, they MUST have identical content." is > verbatim from RFC 4408 so it should be kept unchanged if we mention the topic > at all. Since we are ending the attempt to transition to Type SPF, I think > MAY publish is far too encouraging. How about: > > An SPF-compliant domain name MUST have SPF records of type TXT. > It SHOULD NOT have SPF records of type SPF, but if a domain has > records of both types, they MUST have identical content. > SPF-compliant verifiers SHOULD query SPF records of type TXT only. > >> As for Section 4.4, I don't think it makes sense to specify >> non-recommended behavior. Let me try some minor tweaks as well: >> >> -02: >> In accordance with how the records are published (see Section 3.1 >> above), a DNS query needs to be made for the name, querying >> for type TXT. SPF Version 1 queries for records of type SPF SHOULD >> NOT be done. If both SPF and TXT RRs are looked up, the queries MAY >> be done in parallel. >> >> NEW >> In accordance with how the records are published (see Section 3.1 >> above), a DNS query needs to be made for the domain name, querying >> for type TXT. SPF queries for SPF records of type SPF SHOULD NOT be >> done any more. > > I'm fine with that, but I'd stop at done (remove any more). > > Other opinions? > > Scott K How about this - -In accordance with how the records are published (see Section 3.1 -above), a DNS query needs to be made for the domain name, querying -for type TXT. SPF queries for SPF records of type SPF SHOULD NOT be -done any more. +In accordance with how the records are published (see Section 3.1 +above), SPF v1 DNS queries for domain names should only be performed +using DNS TXT RRs, while queries requesting DNS SPF RRs SHOULD NO LONGER be performed. Best, Alan M. From spf2@kitterman.com Sat Jun 30 17:26: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 2816E21F8526 for ; Sat, 30 Jun 2012 17:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2LYZVd7HYmu for ; Sat, 30 Jun 2012 17:26:33 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 39AF621F8512 for ; Sat, 30 Jun 2012 17:26:32 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 47735D04091; Sat, 30 Jun 2012 19:26:33 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1341102393; bh=mSA2XSnr8NtO0WuhEiwgAIYuM7f57TEJNHKiJzA43O8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=SzyMTWFjWL9iIYrTPH1s2RFLN7bA+5Mecz2X6f1Ki/Y40ZzOTYt6x/AjkC//TwxiU pENaJ1yV3wLWcf06Osf8nFi7UU9gI7wIeiem8VUOYCMucwotewdB7HI4/y6edbNU4e Z4LGxivlVVlSe47O5YEBakfQSrJGXg9SPkLqb5W0= Received: from scott-latitude-e6320.localnet (unknown [208.253.106.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2E06FD04067; Sat, 30 Jun 2012 19:26:33 -0500 (CDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 30 Jun 2012 20:25:42 -0400 Message-ID: <1442841.gZ27EDJaKB@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-26-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <4FEF94A1.8030406@Commerco.Net> References: <20120222193641.73783.qmail@joyce.lan> <2028173.23DeCXx7cE@scott-latitude-e6320> <4FEF94A1.8030406@Commerco.Net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Jul 2012 00:26:34 -0000 On Saturday, June 30, 2012 06:06:57 PM Commerco WebMaster wrote: > On 6/30/2012 5:26 PM, Scott Kitterman wrote: > > On Saturday, June 30, 2012 12:24:51 PM Alessandro Vesely wrote: > >> On Fri 29/Jun/2012 20:11:10 +0200 Scott Kitterman wrote: > >>> Yesterday I prepared a proposed change for this issue, and #25: RFC > >>> 4408: > >>> Section 4.4 Parallel Query, that'll be in the -02 I plan to post today > >>> (since msk promised to read the draft over the weekend). For parallel > >>> query, I think it's essentially OBE since we aren't going to recommend > >>> doing lookups for both types. > >> > >> -02: > >> An SPF-compliant domain name MUST have SPF records of type TXT. An > >> SPF-compliant domain name MUST NOT publish only records of type SPF. > >> If a domain has records of both types, they MUST have identical > >> content. > >> > >> I'd strike the second sentence, which merely repeats the first. As > >> this is a change, it might be worth to anticipate the lookup change > >> from 4.4 instead, so as to convey the change more compactly: > >> > >> NEW > >> > >> An SPF-compliant domain name MUST have SPF records of type TXT, and > >> MAY have SPF records of type SPF. If a domain has records of both > >> types, they SHOULD have identical content. However, SPF-compliant > >> verifiers SHOULD query SPF records of type TXT only. > > > > I agree that "MUST NOT publish only records of type SPF" is technically > > redundant, but I left it in because, since this is a change, I wanted to > > be > > clear about it (my feeling is that 4408, in the name of getting approved, > > somewhat disingenuously encouraged type SPF publication). > > > > "If a domain has records of both types, they MUST have identical content." > > is verbatim from RFC 4408 so it should be kept unchanged if we mention > > the topic at all. Since we are ending the attempt to transition to Type > > SPF, I think> > > MAY publish is far too encouraging. How about: > > An SPF-compliant domain name MUST have SPF records of type TXT. > > It SHOULD NOT have SPF records of type SPF, but if a domain has > > records of both types, they MUST have identical content. > > SPF-compliant verifiers SHOULD query SPF records of type TXT only. > >> > >> As for Section 4.4, I don't think it makes sense to specify > >> non-recommended behavior. Let me try some minor tweaks as well: > >> > >> -02: > >> In accordance with how the records are published (see Section 3.1 > >> above), a DNS query needs to be made for the name, querying > >> for type TXT. SPF Version 1 queries for records of type SPF SHOULD > >> NOT be done. If both SPF and TXT RRs are looked up, the queries MAY > >> be done in parallel. > >> > >> NEW > >> > >> In accordance with how the records are published (see Section 3.1 > >> above), a DNS query needs to be made for the domain name, querying > >> for type TXT. SPF queries for SPF records of type SPF SHOULD NOT be > >> done any more. > > > > I'm fine with that, but I'd stop at done (remove any more). > > > > Other opinions? > > > > Scott K > > How about this - > -In accordance with how the records are published (see Section 3.1 > -above), a DNS query needs to be made for the domain name, querying > -for type TXT. SPF queries for SPF records of type SPF SHOULD NOT be > -done any more. > > +In accordance with how the records are published (see Section 3.1 > +above), SPF v1 DNS queries for domain names should only be performed > +using DNS TXT RRs, while queries requesting DNS SPF RRs SHOULD NO > LONGER be performed. I agree that sounds better, but SHOULD NOT is RFC 2119, but SHOULD NO LONGER is not, so I'm not sure how to do it. How about: In accordance with how the records are published (see Section 3.1 above), a DNS query needs to be made for the domain name, querying for type TXT, but queries SHOULD NOT be done for Type SPF. Scott K From john@jlc.net Sat Jun 30 17:31:25 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 0453A21F8550 for ; Sat, 30 Jun 2012 17:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu74HR3EZz10 for ; Sat, 30 Jun 2012 17:31:24 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 783B221F84C9 for ; Sat, 30 Jun 2012 17:31:24 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5C5C533C21; Sat, 30 Jun 2012 20:31:26 -0400 (EDT) Date: Sat, 30 Jun 2012 20:31:26 -0400 From: John Leslie To: Scott Kitterman Message-ID: <20120701003126.GA86191@verdi> References: <20120222193641.73783.qmail@joyce.lan> <1390536.tGbELFoml6@scott-latitude-e6320> <4FEED3F3.7020900@tana.it> <2028173.23DeCXx7cE@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2028173.23DeCXx7cE@scott-latitude-e6320> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Jul 2012 00:31:25 -0000 Scott Kitterman wrote: > On Saturday, June 30, 2012 12:24:51 PM Alessandro Vesely wrote: >> >> NEW >> An SPF-compliant domain name MUST have SPF records of type TXT, and >> MAY have SPF records of type SPF. If a domain has records of both >> types, they SHOULD have identical content. However, SPF-compliant >> verifiers SHOULD query SPF records of type TXT only. This looks right to me... > "If a domain has records of both types, they MUST have identical content." > is verbatim from RFC 4408 so it should be kept unchanged if we mention > the topic at all. I don't see it that way. Checking type SPF is outside 4408bis; thus we have no reason to _require_ they be identical. (I would be willing to not mention anything about what type SPF should contain: merely state that they will not be checked by 4408bis-compliant systems.) > Since we are ending the attempt to transition to Type SPF, I think > MAY publish is far too encouraging. Nonetheless, there will be legacy type SPF records. "May have" seems fine to me. (We can't ask for a "flag day".) > How about: > > An SPF-compliant domain name MUST have SPF records of type TXT. > It SHOULD NOT have SPF records of type SPF, but if a domain has > records of both types, they MUST have identical content. For various reasons, removing type SPF records is likely to take a while. Tools for changing them are likely to become buggy or disappear entirely. While it would be "nice" if they disappeared, it's not reasonable to require that any changes in the type TXT RR be copied to the type SPF RR. > SPF-compliant verifiers SHOULD query SPF records of type TXT only. It might be good to add something like "If a type TXT record is found its value MUST be used (in preference to any type SPF record). -- John Leslie From WebMaster@Commerco.Net Sat Jun 30 17:58: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 0A23E21F8540 for ; Sat, 30 Jun 2012 17:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-C1cBs6gqjQ for ; Sat, 30 Jun 2012 17:58:12 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 29CB321F8514 for ; Sat, 30 Jun 2012 17:58:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=F+y8N3b43hz4QEsk6EWNF5kCCnlUDKxp2n1bqXv9DGXEKB+1ZAj0j8yTans6RXOdu2mZDT87JuzqfgwieEMgwryCZuj607W2Owxym6Cp2MnO9Jx67cU3ZpVyBQAbZd+3e7ZyXy6TKNi5ZGexluVB+3mrVLYgUxOfkxAb8OjQ2p0= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Sun, 01 Jul 2012 00:58:12 +0000 Message-ID: <4FEFA09D.9070105@Commerco.Net> Date: Sat, 30 Jun 2012 18:58:05 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120222193641.73783.qmail@joyce.lan> <2028173.23DeCXx7cE@scott-latitude-e6320> <4FEF94A1.8030406@Commerco.Net> <1442841.gZ27EDJaKB@scott-latitude-e6320> In-Reply-To: <1442841.gZ27EDJaKB@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Jul 2012 00:58:13 -0000 On 6/30/2012 6:25 PM, Scott Kitterman wrote: > On Saturday, June 30, 2012 06:06:57 PM Commerco WebMaster wrote: >> On 6/30/2012 5:26 PM, Scott Kitterman wrote: >>> On Saturday, June 30, 2012 12:24:51 PM Alessandro Vesely wrote: >>>> On Fri 29/Jun/2012 20:11:10 +0200 Scott Kitterman wrote: >>>>> Yesterday I prepared a proposed change for this issue, and #25: RFC >>>>> 4408: >>>>> Section 4.4 Parallel Query, that'll be in the -02 I plan to post today >>>>> (since msk promised to read the draft over the weekend). For parallel >>>>> query, I think it's essentially OBE since we aren't going to recommend >>>>> doing lookups for both types. >>>> >>>> -02: >>>> An SPF-compliant domain name MUST have SPF records of type TXT. An >>>> SPF-compliant domain name MUST NOT publish only records of type SPF. >>>> If a domain has records of both types, they MUST have identical >>>> content. >>>> >>>> I'd strike the second sentence, which merely repeats the first. As >>>> this is a change, it might be worth to anticipate the lookup change >>>> from 4.4 instead, so as to convey the change more compactly: >>>> >>>> NEW >>>> >>>> An SPF-compliant domain name MUST have SPF records of type TXT, and >>>> MAY have SPF records of type SPF. If a domain has records of both >>>> types, they SHOULD have identical content. However, SPF-compliant >>>> verifiers SHOULD query SPF records of type TXT only. >>> >>> I agree that "MUST NOT publish only records of type SPF" is technically >>> redundant, but I left it in because, since this is a change, I wanted to >>> be >>> clear about it (my feeling is that 4408, in the name of getting approved, >>> somewhat disingenuously encouraged type SPF publication). >>> >>> "If a domain has records of both types, they MUST have identical content." >>> is verbatim from RFC 4408 so it should be kept unchanged if we mention >>> the topic at all. Since we are ending the attempt to transition to Type >>> SPF, I think> >>> MAY publish is far too encouraging. How about: >>> An SPF-compliant domain name MUST have SPF records of type TXT. >>> It SHOULD NOT have SPF records of type SPF, but if a domain has >>> records of both types, they MUST have identical content. >>> SPF-compliant verifiers SHOULD query SPF records of type TXT only. >>>> >>>> As for Section 4.4, I don't think it makes sense to specify >>>> non-recommended behavior. Let me try some minor tweaks as well: >>>> >>>> -02: >>>> In accordance with how the records are published (see Section 3.1 >>>> above), a DNS query needs to be made for the name, querying >>>> for type TXT. SPF Version 1 queries for records of type SPF SHOULD >>>> NOT be done. If both SPF and TXT RRs are looked up, the queries MAY >>>> be done in parallel. >>>> >>>> NEW >>>> >>>> In accordance with how the records are published (see Section 3.1 >>>> above), a DNS query needs to be made for the domain name, querying >>>> for type TXT. SPF queries for SPF records of type SPF SHOULD NOT be >>>> done any more. >>> >>> I'm fine with that, but I'd stop at done (remove any more). >>> >>> Other opinions? >>> >>> Scott K >> >> How about this - >> -In accordance with how the records are published (see Section 3.1 >> -above), a DNS query needs to be made for the domain name, querying >> -for type TXT. SPF queries for SPF records of type SPF SHOULD NOT be >> -done any more. >> >> +In accordance with how the records are published (see Section 3.1 >> +above), SPF v1 DNS queries for domain names should only be performed >> +using DNS TXT RRs, while queries requesting DNS SPF RRs SHOULD NO >> LONGER be performed. > > I agree that sounds better, but SHOULD NOT is RFC 2119, but SHOULD NO LONGER > is not, so I'm not sure how to do it. How about: > > In accordance with how the records are published (see Section 3.1 > above), a DNS query needs to be made for the domain name, querying > for type TXT, but queries SHOULD NOT be done for Type SPF. > > Scott K I understand the issue, though one wonders, did RFC 2119 ever account for situations like this BIS exercise where one must go back and change what was to what is no longer? Doh! How about this... In accordance with how the records are published (see Section 3.1 above), a DNS query MUST be made for the domain name using type TXT and SHOULD NOT be made for type SPF. Alan M. From superuser@gmail.com Sat Jun 30 21:58:52 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 0FC1621F853B for ; Sat, 30 Jun 2012 21:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFdMk61XQ9ox for ; Sat, 30 Jun 2012 21:58:50 -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 8F05D21F8496 for ; Sat, 30 Jun 2012 21:58:50 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so6777968lbb.31 for ; Sat, 30 Jun 2012 21:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aJ4ehsTxdT+aSE3eVZkex0O4+DyYVx1R1i3sUaQJHsg=; b=i4/76DArgrK6bgoO6srIbR64dsw0kryc4HIvsur/1KrfM7ZHwjBKOF+CRiaWoxci6Z BC1KXe86b5tcrWv83n6G9tKOUpJW1I6kwN/J/xkEgvzjlU9krdEsVza9DrQ4upMwmzap MUGGZ7x32tAhLyVvNWWQ7YVxzovimyHkTgZ8zx9FuY9xq/f16q9pVsUkRmORDAWzHbyc dkm2XwTomjzSl/5Qgx4knhugZaDAd6gDeCBCnnMPYMcS4SBeB17USgfuhrem/rXMiDfq hPnuJUv1U0djKycvA7HXR3S9UKHmV7AFICEiJMtSvdiHn9CIo9AQjYSuIQXg5ahI9dyM vnVw== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr7859016lab.40.1341118731207; Sat, 30 Jun 2012 21:58:51 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sat, 30 Jun 2012 21:58:51 -0700 (PDT) In-Reply-To: <4FEED3F3.7020900@tana.it> References: <20120222193641.73783.qmail@joyce.lan> <4F4D31E9.2000601@dcrocker.net> <6.2.5.6.2.20120629092333.08feed68@resistor.net> <1390536.tGbELFoml6@scott-latitude-e6320> <4FEED3F3.7020900@tana.it> Date: Sat, 30 Jun 2012 21:58:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d040838d39342bc04c3bd89f4 Cc: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Jul 2012 04:58:52 -0000 --f46d040838d39342bc04c3bd89f4 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 30, 2012 at 3:24 AM, Alessandro Vesely wrote: > -02: > An SPF-compliant domain name MUST have SPF records of type TXT. An > SPF-compliant domain name MUST NOT publish only records of type SPF. > If a domain has records of both types, they MUST have identical > content. > > I'd strike the second sentence, which merely repeats the first. As > this is a change, it might be worth to anticipate the lookup change > from 4.4 instead, so as to convey the change more compactly: > +1. NEW > An SPF-compliant domain name MUST have SPF records of type TXT, and > MAY have SPF records of type SPF. If a domain has records of both > types, they SHOULD have identical content. However, SPF-compliant > verifiers SHOULD query SPF records of type TXT only. > Given the conclusions of the experiment draft, why are we continuing to even talk about the SPF RRTYPE? I think 4408bis should drop it altogether. -MSK --f46d040838d39342bc04c3bd89f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jun 30, 2012 at 3:24 AM, Alessandro Vesely <vesely@tana.it> wrote:
-02:
=A0An SPF-compliant domain name MUST have SPF records of type TXT. =A0An =A0SPF-compliant domain name MUST NOT publish only records of type SPF.
=A0If a domain has records of both types, they MUST have identical
=A0content.

I'd strike the second sentence, which merely repeats the first. =A0As this is a change, it might be worth to anticipate the lookup change
from 4.4 instead, so as to convey the change more compactly:

+1.

NEW
=A0An SPF-compliant domain name MUST have SPF records of type TXT, and
=A0MAY have SPF records of type SPF. =A0If a domain has records of both
=A0types, they SHOULD have identical content. =A0However, SPF-compliant
=A0verifiers SHOULD query SPF records of type TXT only.

Given the conclusions of the experiment draft, why are we continuing = to even talk about the SPF RRTYPE?=A0 I think 4408bis should drop it altoge= ther.
=A0
-MSK
--f46d040838d39342bc04c3bd89f4-- From superuser@gmail.com Sat Jun 30 22:02: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 5752821F8557 for ; Sat, 30 Jun 2012 22:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDV5pvC+yIDL for ; Sat, 30 Jun 2012 22:02:35 -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 7303C21F854D for ; Sat, 30 Jun 2012 22:02:35 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so6779816lbb.31 for ; Sat, 30 Jun 2012 22:02:36 -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=8oEgea/tcLXo9uBWRrmP8QQzkFhV3cVOXpaWzjzgTYQ=; b=VX5cqhC/KnVw+SjzTofHxM3X2HoMklIat7TCZ8HUucqYIWZDZUFDcLbk5uA0YUW37Y 01F0ZNcJnTduOilLHI3Nc28gXXlzZxt368sJus1cM+8d0Lq/vZQzzEVBFly7zNeNr4al Xoqe1+ab6qmZGA3kREsuljK2122KMAIjI7ng5HYFKbPCnJyXIkIujACMG8s9QlKGHzNp P9hbJL3Q6Lw3aP/WEScDx/7I9Cb9i1M7rV/AooGqvzjz48vQv+e9h05SioYnjOjsZU/T gaJi4dswoDIJvD/U8pkr1UxgMGuJ9nJvdXI+b5eqlf0YFR4VLpXYVuM9PZMHnUiaqqwy gtRg== MIME-Version: 1.0 Received: by 10.112.39.135 with SMTP id p7mr3962330lbk.78.1341118956048; Sat, 30 Jun 2012 22:02:36 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Sat, 30 Jun 2012 22:02:36 -0700 (PDT) In-Reply-To: <1442841.gZ27EDJaKB@scott-latitude-e6320> References: <20120222193641.73783.qmail@joyce.lan> <2028173.23DeCXx7cE@scott-latitude-e6320> <4FEF94A1.8030406@Commerco.Net> <1442841.gZ27EDJaKB@scott-latitude-e6320> Date: Sat, 30 Jun 2012 22:02:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=485b390f7a76fa125a04c3bd965a Cc: spfbis@ietf.org Subject: Re: [spfbis] #9: RFC 4408 SPF RR type X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 01 Jul 2012 05:02:36 -0000 --485b390f7a76fa125a04c3bd965a Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 30, 2012 at 5:25 PM, Scott Kitterman wrote: > > How about this - > > -In accordance with how the records are published (see Section 3.1 > > -above), a DNS query needs to be made for the domain name, querying > > -for type TXT. SPF queries for SPF records of type SPF SHOULD NOT be > > -done any more. > > > > +In accordance with how the records are published (see Section 3.1 > > +above), SPF v1 DNS queries for domain names should only be performed > > +using DNS TXT RRs, while queries requesting DNS SPF RRs SHOULD NO > > LONGER be performed. > > I agree that sounds better, but SHOULD NOT is RFC 2119, but SHOULD NO > LONGER > is not, so I'm not sure how to do it. How about: > > In accordance with how the records are published (see Section 3.1 > above), a DNS query needs to be made for the domain name, querying > for type TXT, but queries SHOULD NOT be done for Type SPF. > I suggest: In accordance with how the records are published (see Section 3.1 above), a DNS query needs to be made for the domain name, querying for type TXT. -MSK --485b390f7a76fa125a04c3bd965a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jun 30, 2012 at 5:25 PM, Scott Kitterman <spf2@kitterman.com&= gt; wrote:
> How about this -
> -In accordance with how the records are published (see Section 3.1
> -above), a DNS query needs to be made for the domain name, querying > -for type TXT. =A0SPF queries for SPF records of type SPF SHOULD NOT b= e
> -done any more.
>
> +In accordance with how the records are published (see Section 3.1
> +above), SPF v1 DNS queries for domain names should only be performed<= br> > +using DNS TXT RRs, while queries requesting DNS SPF RRs SHOULD NO
> LONGER be performed.

I agree that sounds better, but SHOULD NOT is RFC 2119, but SHO= ULD NO LONGER
is not, so I'm not sure how to do it. =A0How about:

=A0 =A0In accordance with how the records are published (see Section 3.1 =A0 =A0above), a DNS query needs to be made for the domain name, querying
=A0 =A0for type TXT, but queries SHOULD NOT be done for Type SPF.
=

I suggest:

In accordance with how the records = are published (see Section 3.1 above), a DNS query needs to be made for the= domain name, querying for type TXT.

-MSK
--485b390f7a76fa125a04c3bd965a--